The Artima Developer Community
Sponsored Link

Articles Forum
A Brief Look at C++0x

150 replies on 11 pages. Most recent reply: Nov 23, 2006 8:19 AM by lemon head

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 150 replies on 11 pages [ « | 1 ... 2 3 4 5 6 7 8 9 10 ... 11  | » ]
Christopher L. Marshall

Posts: 6
Nickname: chrism22
Registered: Sep, 2005

Re: template typedef work-around Posted: Jan 6, 2006 9:40 AM
Reply to this message Reply
Advertisement
>
> Note that, unlike real template aliases (and except for
> the syntax difference), the above won't allow template
> parameter deduction:
>
> template<class T>
> void f(aliases<T>::vec v);
>
> f(aliases<double>::vec()); // Error: T can't be deduced
>
> However, with the alias:
>
> template<class T>
> using vec = vector<T,My_alloc<T>>;
>
> template<class T>
> void f(vec<T> v);
>
> f(vec<double>()); // Ok
>


Thanks for bringing up this interesting example.

I tried this out and sure enough, the compiler complained when I called the function that no such function was defined, indicating that it couldn't deduce the type needed to instantiate the function template into a function.

What is preventing the compiler from deducing T in the function template? I must not have a clear understand of how type deduction works.

Chris Marshall

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Learning C++ Posted: Jan 6, 2006 11:56 AM
Reply to this message Reply
I'm really not trying to hijack the thread. Even so:

/* While I think "The C++ Programming Language" is a great book in many ways, Mr. Stoustrup's use of code fragments to illustrate his points, and his lack of complete executable example code, made it hard for me to use it for learning the language.

Once I was comfortable with the language, however, I found his book delightful.
*/

I've reread "The C++ Programming Language" several times. I agree that it isn't a good first book for learning the language, but (IIRC), it's not advertised as one.

The book I used (and I would highly recommend) was "Computting Concepts With C++ Essentials," by Cay Horstmann.

Of course, it is now possible to learn from Stroustrup himself (http://courses.cs.tamu.edu/petep/ click on notes).

That said, I agree that "The C++ Programming Language" is actually an enjoyable book. And I'm currently working on a documentation project that will use italics instead of monospaced font for the code examples because I do find it easier to read.

Thinking about it, my paperback is about gone. I guess it's time to get a hardcover copy.

Misha Bergal

Posts: 2
Nickname: mbergal2
Registered: Jan, 2006

Re: Just curious Posted: Jan 6, 2006 10:49 PM
Reply to this message Reply
> This situation can be both an advantage and disadvantage:
> No one party/company controls the development of C++ - it's
> nonproprietary, but it also means there's no specific
> funding source.

I don't think having the control of one corporation is the only way to get funding sources. I do believe that it is possible to get others. Case in point: FSF, Eclipse SF, Apache SF. This is not automatically applicable to C++ development, but their experiences might be something to look at.


> However, C++ shares this with many other languages
> (such as Perl, Python, PHP, etc.).

http://wiki.python.org/moin/PythonThreeDotOh looks interesting. Why something like this could not be done for C++ ? Also as I've heard Guido is working for Google where his main responsibility is working on Python development. How come that
"people working on it [C++] get absolutely _no pay_ for their volunteer work, and in fact, have to pay to be allowed to work for free (!) by paying their own expenses (unless their employer contributes) for attending standards meetings, fees to ISO, etc."

http://slashdot.org/comments.pl?sid=172797&cid=14391454

Alexander Libman

Posts: 4
Nickname: alexlibman
Registered: Nov, 2005

Re: A Brief Look at C++0x Posted: Jan 6, 2006 11:25 PM
Reply to this message Reply
although the commitee has stopped looking for new proposals, I can not stop myself about asking about small syntactic sugar for template declarations :
"template <arg_list> { "

Here is the template with separation class declaration and methods implementations :

template <class X, class C = std::list<X> >
class stack
{
public:
stack() : c () {}
void push(const X & x);
void pop();
X & top ();
private:
C c;
};

template<class X, class C>
void stack<X,C>::push(const X & x) { c.push_back(x); }

template<class X, class C>
void stack<X,C>::pop() { c.pop_back(); }
.......

Being lazy to write "template<class X, class C>"
before each method body, I'd like to write

template <class X, class C = std::list<X> >
{
class stack
{
public:
stack() : c () {}
X & top ();
void push(const X & x);
void pop();
private:
C c;
};

void stack<X,C>::pop() { c.pop_back(); }
void stack<X,C>::push(const X & x) { c.push_back(x); }
X & stack<X,C>::top() { return c.back(); }
}

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: A Brief Look at C++0x Posted: Jan 7, 2006 6:09 AM
Reply to this message Reply
Having worked with Java (not much) and C# (way too much), I can only say that my experience is quite the opposite. Developing with C++ was both faster and less frustrating.

Your opinion is accounted for, but generally most people tend to leave C++ in favor of Java. It can not be just a coincidence. It also depends highly on the types of projects you are involved. Generally it is difficult to come to the correct conclusion, so I can only speak about the general trend as I perceive it in day-to-day communication with co-workers and the internet.

Not necessarily so. For what I call Internal Properties, the member field being represented by the property is contained within it, so there is no overhead.

How is that possible? even internal properties need a pointer to an object in order to call the object's proper method. I agree that the memory overhead is not great, even with extra fields, but C++ is about "don't pay for what you don't use", and if we had proper properties we wouldn't have such an issue.

Unless you used the hack of calculating in compile time the address of the owner object based on the address of the property field.

And the big deal with that is? Or, rather, this is a particular problem because? There're plenty of examples where template handling costs compile time.

The big deal is that lot's of time is spent in compiling instead of doing actual work, especially if there are lots of classes involved with properties. Waiting for the compiler to finish its work interrupts the programmer's thought process. Templates are heavily used through out C++, so there is already a compiler overhead, which becomes much greater with template instantiations in every field.

It's clear you've not read Ch 35 of Imperfect C++. Maybe now's the time to get hold of a copy. ;-)

I admit I have not read it. But since it is impossible to do what you describe without the hack mentioned above, I must tell you that I have done such a hack, and even published it here: http://www.codeproject.com/samples/cppprops.asp.

I've just downloaded the recls library...I see what you've done now. Well, your implementation is efficient, but it is a hack containing macros, just like mine. I consider it unnacceptable for general use. I prefer clean solutions.

Well, RAII uses the destructor to release resources. And if I create an object via new that allocates resources (opens a communication, opens a file, or any other thing) I want to destroy it when I want because I want to close the file. Otherwise I have to close it by hand, and that's very error prone.

Indeed, but having GC does not mean you can not delete an object wherever you want. D takes that approach: an object may be deleted manually, or by the collector.

but since I'm used to manage memory by hand, I don't find memory allocation is a productive burden.

I am also used to manage memory by hand. To give you an example, I am the solo programmer in a C++ project of 120,000 lines of code that has a requirement of running uninterrupted for days; After lots of sweat, my program runs without any memory problems. But that does not mean I would not be more productive with GC. I would have completed the project much sooner, if I had GC.

And let's not forget people that are not so much interested in mastering their C++ skills.

In my experience with languages with garbage collectors usually the perfomance is worse and the memory use, higher.

I agree again, but that is because these languages have ALL objects in the heap; C++ avoids that by allowing stack based objects. In most cases, a few objects need to live in the heap, but GC allows many complex data structure models to be implemented over those objects (in particular models with cycle references), which is not particularly easy with shared pointers.

I really think that you can do efficient programs in Java. But that isn't the norm.

My company has done soft real time projects with Java: it was a radar console with a real-time video image. It performed quite well, but it had minimal object allocations (most objects where pre-allocated). Java is not slow; Swing is slow, because it implements its own window management system on top of the native one, making Java apps seem slow.

I'm not talking about benchmarks. Just take a text processor, a P2P client, a browser. Every Java program I use gets me sick because of the huge amount of resources it needs.

Exactly that's why we need GC in C++! it does not have to be so bad as in Java. And it will be optional.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: template typedef work-around Posted: Jan 7, 2006 6:20 AM
Reply to this message Reply
> > Note that, unlike real template aliases (and except for
> > the syntax difference), the above won't allow template
> > parameter deduction:
> >
> > template<class T>
> > void f(aliases<T>::vec v);
> >
> > f(aliases<double>::vec()); // Error: T can't be deduced
> >
> > However, with the alias:
> >
> > template<class T>
> > using vec = vector<T,My_alloc<T>>;
> >
> > template<class T>
> > void f(vec<T> v);
> >
> > f(vec<double>()); // Ok
> >

>
> I tried this out and sure enough, the compiler complained
> when I called the function that no such function was
> defined, indicating that it couldn't deduce the type
> needed to instantiate the function template into a
> function.

Right. You have to explicitly tell it the type T:

f<double>(aliases<double>::vec()); // Ok

> What is preventing the compiler from deducing T in the
> function template?

The short answer is that "it's not on the list of approved deductions" :) (The standard has a list of cases where deduction can happen - 14.8.2.4/3). In the definition:

template<class T>
void f(aliases<T>::vec v);

T is used in a so-called nondeduced context - it can't be deduced in that context, and has to either be explicitly specified in the instantiation (as done in f<double>..., above), or be deduced elsewhere, e.g. if T was also used in a context where it can be deduced).

To quote from 14.8.2.4/3-4:

"[...] If a template parameter is used only in nondeduced
contexts and is not explicitly specified, template argument deduction fails.
4 The nondeduced contexts are:
— The nested-name-specifier of a type that was specified using a qualified-id. [...]"

The "type" here refers to the type of the function template parameter, in this case "aliases<T>::vec".

The question then becomes "Why?" As I understand, the reason is that due to possible specialisations, the compiler can't necessarily know at the point of instantiation, what the nested member is. Consider:

f(aliases<double>::vec()); // Let's say we allow this, and T deduces to "double".

then later in the code:

template<>
struct aliases<double> {}; // Oops, no "vec" member available, anymore...

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: A Brief Look at C++0x Posted: Jan 7, 2006 7:16 AM
Reply to this message Reply
> Having worked with Java (not much) and C# (way too
> much), I can only say that my experience is quite the
> opposite. Developing with C++ was both faster and less
> frustrating.

>
> Your opinion is accounted for, but generally most people
> tend to leave C++ in favor of Java. It can not be just a
> coincidence.

There are also scores of people who move to PHP. Also, if we were to count the most used language in the world, VB would get very high up on the list. Most used doesn't need to be "best", in a technical sense. C++ is a complex language that takes many years to master, and many are probably not ready to invest that much in learning a language, so they go for easier/simpler languages, even though it may turn out farther down the road to be _harder_ to work with, than the "simpler" languages.

Recognised .NET-expert Jural Lowy has a good DevNet.NET Cast about this (http://devnet.developerpipeline.com/podcasts/dotnetcast/): "VB 6 Glass Ceiling" (http://devnet.developerpipeline.com/documents/s=9904/ddj051018dnc), about that easy things may be easy in VB, but hard things may be more or less impossible, and way harder than in a language designed for "enterprise applications" (which VB was not). You can get the same experience in languages like PHP, where simple scripts may be quite easy to make, but with larger applications, the lack of type checking, etc. really makes it hard to make robust software.

> I am also used to manage memory by hand. To give you an
> example, I am the solo programmer in a C++ project of
> 120,000 lines of code that has a requirement of running
> uninterrupted for days; After lots of sweat, my program
> runs without any memory problems. But that does not mean I
> would not be more productive with GC. I would have
> completed the project much sooner, if I had GC.

I'm not so sure about that. A GC gives different kinds of potential problems. Rather than having to make sure you free memory (or avoid cycles, if you use reference counting), you run into similar things in Java: You have to make sure to set long-lived references to null, or they will hold on to objects for perhaps way too long (like forever), so you get a host of different references in Java to deal with these kinds of things, such as "weak references", "phantom references", etc. GC doesn't remove the problem of resource management, it just changes it, with different things to watch out for, and in particular it doesn't handle other resources than memory, at all, so you have to use clumsy try-finally blocks for things like file handles, database connections, etc. C++ lets you handle all resources in a uniform manner, using RAII (including its use in smart pointers), or optionally using some GC library.

However, I understand the sentiment that if you are to use a GC library, then the inability to determine what is a pointer and what is not, makes such a GC appear rather "hackish", so features to support optional GC in C++ might be useful.

You mentioned your experience with a project without GC (C++), let me mention one I've been on, _with_ GC (Java) (being the only developer on that one). Sure, I got the program up and running, but I ran into a rather nasty performance problem, that turned out (from profiling) to be the result of "GC trashing" - the GC could start using something like 80% of the time, continuously garbage-collecting. This was an image-manipulation application, and what happened was that it created several Image-objects per frame, and it ran with many frames per second, so the GC was overworked on trashing all these objects after they were used. The reason they had to be dumped, rather than reused, was that the Java Image-API uses immutable objects, so there was really no choice...

I ended up having to rewrite some of the code in more low-level form, "pooling" objects, etc., but the code became much less elegant with it. However, it had to be done, to get acceptable performance. The application had to run in a browser, so C++ wasn't really an option (this was before .NET).

This is my experience with Java: You typically have to choose between efficiency and elegance. In C++, with stack-allocated objects, and a uniform treatment of built-in types and objects (including how they are passed: you can choose by-value or by-reference regardless of their type, as well as things like operator overloading), means you can get both.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: A Brief Look at C++0x Posted: Jan 7, 2006 9:32 AM
Reply to this message Reply
>Achilleas Margaritis:

By the way: I realise after having posted a reply to your posting at Slashdot, that I was a little harsh, and have posted a follow-up to it, where I retract some of it (yet to appear at Slashdot).

You see, I am on the C++ standards committee, and I get a little tired of hearing complaints about too little being done with C++.

Unfortunately, I haven't had much chance to contribute, myself, due to other commitments, but I at least participated at the Lillehammer meeting last spring (where among other things, proposals for "concepts", modules, and memory model (for concurrency) were being discussed and refined), and I'd like to participate at the Berlin meeting next year, as well, if I get a chance to. However, at least I don't complain about the other people who actually do contribute to the standards work, and do some excellent work. The "concepts" proposals (there are two of them, but they might be merged), for example, are really big things, and the authors of one of them have made a prototype implementation in GCC, in three full-time months (which I found to be a surprisingly short time, but it's a prototype, and apparently quite slow). How many of us would be able to take that much time for standards work, unless you're doing it as part of study (which I think was the case here)?

One shouldn't underestimate the amount of work going into even "smaller" features (making sure it works in all cases, provide "standardese text" for the standard, participating in discussions, perhaps making prototype implementation, to show implementability, etc.). For one thing, some issues are often considered "small", due to ignorance of the actual complexities involved. Take things like overload resolution, which is very complex, once you study that part of the standard. If you really think it's "simple" and "easy", come to a standards meeting...

Regarding your reply to Mr. Stroustrup:

"That done, try putting yourself in the shoes of the committee and decide how to proceed.

It's easy: implement all the proposals. They are not that many or that difficult to implement anyway."

I think you're grossly underestimate the issues involved in standards work, and the complexities involved in the various features. Have you actually read the proposal papers at the standards site?

However, if you do think it's so easy to do this, then by all means, any help would be most welcome, and you might get a different understanding of the amount of work that goes into this...

> if people like yourself (who want these things)
> participate in the language development, we could probably
> have had done more, by now.

>
> Where do I sign up???

I'm no expert on standards work, but one of the things that have been suggested, is to read through the proposals that interest you, to get an understanding of the issues involved, and possibly the status of the proposal. Then, you might mail the author, asking if there's something you can contribute with.

I know, for example, that Thorsten Ottosen is working on a DbC-proposal, that he has presented a couple of times to the committee (with a revised version, of course), but he's concerned that although quite a few people on the committee expresses interest in it (I think it could be great for C++, too, and possibly complement "concepts", where concepts check compile-time properties, and contracts check run-time properties, of classes and functions), there may not be enough people to care _enough_, for it to happen (to become a feature of C++0x). From what I've heard, he's working on a prototype implementation of it in GCC, but like many people, is also very busy (doing both work and study, as well as this). People like him, and others working on other proposals, I'm sure would welcome any and all support and contribution.

One can also write a proposal, oneself (although it might not have much chance to get much consideration, at this point, perhaps unless it's an "important" feature, and you're willing to do much of the work with it, yourself, as many on the committee are busy with the existing proposals).

To run through some of the proposals in your list:

"-No true message passing."

Boost.Signals does this quite well, not requiring you to specify the interface up-front.

"-No retrospection."

You talk about the "run-time structure" of a class, but also say this will have no run-time overhead, so I'm guessing you mean compile-time introspection information (or what to call it). Bjarne Stroustrup has an XTI (Extended Type Information) project, that provides this information at run-time, and then there's Daveed Vandevoorde's "Metacode" extension proposal, for making the type information available at compile-time, and for making metaprogramming easier, being able to use normal C++ syntax for it.

"- the lack of import declarations."

You might want to look at Daveed Vandevoorde's "module" proposal, as it deals with some of this (getting a module system in C++ is under active consideration).

"- no variable argument lists in templates."

I'd really like to have that one, too (and there exists a proposal for it), as it would, for one thing, enable "perfect forwarding" (together with the "move"-proposal, which seems to have a good chance of making it in the next version of the standard), without cumbersome/limited, and combinatorally explosive number of manually declared overloads/specialisations, but again, someone has to do the work of bringing it to the end.

And so on. "Lambda-functions/closures"? Yes, please. When can we get it? :)

One of the things I brought up at the Lillehammer meeting, when a list of "active proposals" (proposals to work with in the time to come up to the next version of the standard), was that partial specialisation of function templates was missing from the list, and I pointed out that there existed a formal proposal for it (from many years ago), so it was added to the list of active proposals. This would nicely fill out a "hole" in the type system, as you can fully or partially specialise class templates, but only fully (not partially) specialise function templates. This means you can't, for example, specialise std::swap for a class template (and overloading functions in the standard library is not allowed, and is position-dependent, i.e. the overload being selected depends on whether or not it has been seen before the function call, unlike specialisations, which are selected after overload resolution). However, if noone works on it, completes it, it may not get done...

> I think that breaks C++ constructor/destructor model
> (when are the destructors called?)

>
> Why does it matter when destructors are called? when using
> garbage collection, destructors become almost irrelevant
> for heap allocated objects. After all, C++ has RAII, which
> is a much better way to release resources than any
> destructor.

This one puzzled me, too. Destructors is an essential ingredient to RAII in C++... RAII is a technique where you allocate in the constructor, and release in the destructor.

Bjarne Stroustrup

Posts: 60
Nickname: bjarne
Registered: Oct, 2003

Re: A Brief Look at C++0x Posted: Jan 7, 2006 9:39 AM
Reply to this message Reply
> > I think that the greatest strength of "other languages"
> is
> > not that they are better languages, but that they come
> > with larger collections of "free" libraries.
>
> I agree, the large collections of free libraries are a
> major attraction of other languages, but this does beg the
> question: why are there fewer freely available C++
> libraries? After all, C++ has been around longer than many
> of these languages.

I was primarily thinking of Java and C# where corporations are buying marketshare through "free" libraries.

> Are C++ programmers less generous (I don't think so, but
> maybe participating in the standardisation effort exhausts
> their generosity), do they find it easier to make money
> from any libraries they write (certainly C++ is in
> demand), or is it simply harder to write good general
> purpose portable libraries in C++? Certainly it's harder
> to distribute prebuilt C++ libraries.

There has always been a tradition to make money using C++.

There are no really good distribuition channels - this was much more the case when C++ first emerged and when tradiditions were established. This problem is made worse still because C++ (as opposed to the laguages communities that has been successful generatating large bodies of libraries perceives as standard) runs directly on hardware so that installation is less trivial.

There isn't - and there never was - a central focus for the community (e.g. a users group or a web site). Instead different suppliers serve their own users and typically prefer to shield them from the rest of the C++ community.


> Of course, C++ works well with C and can make use of C
> libs. This enables programmers to get the job done, but it
> won't help them improve their C++ skills. Contrast this
> with e.g. Python, where the standard libraries are not
> only useful but also fine examples of how to use the
> language.

Yes. Python is a splendid example of how things can be done well. Perl, Ruby, etc. are other examples. Scripting languages have a good record/tradition in this area.

> Boost is the leading supplier of free C++ libraries, but
> these libraries are often relentlessly modern C++ --
> meaning they may not be suitable for use on some platforms
> (due to poor compiler support), and on other platforms a
> simple user mistake yields frightening compiler output.

I wouldn't critize Boost for being "modern". I think the real problem is that many "boosters" are interested in "neat/advanced" libraries rather than in providing yet-another, but more standard and usable directly useful component. For example, why weren't boost threads, boost sockets, boost XML, boost unicode, and boost files among tthe very first boost components? Such foundation for applications are hard and non-glamorous - it takes a major effort to get people to create and maintain such components.

Note that there were literally thousands of C++ libraries before boost. For example see the C++ libraries FAQ (link on my C++ page). What boost did differently was to create a visible site and a process for quality control and documentation.

> The C++ standard library itself has lagged behind the core
> language and still suffers from the lack of a definitive
> online reference. Yes, there are some excellent sites
> (e.g. msdn) but all too often I need to refer to the ISO
> standard, which was not written with user-friendliness in
> mind.

Yes, but again. Creating a user friendly site takes time, efford, and money. Vendors tend to support their own efforts, rather than community efforts. This is not a one-person, one-year effort (though it could start that way).

It is always worth remembering that not all C++ libraries are - or can be - part of the standard. There are thousands (tens of thousands) of libraries "out there". Many are useful. The snag is that theyr are not always easy to find and once you find them it is not always easy to guess how useful, solid, and well-supported they are.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

Bjarne Stroustrup

Posts: 60
Nickname: bjarne
Registered: Oct, 2003

Re: Learning C++ Posted: Jan 7, 2006 10:51 AM
Reply to this message Reply
> I'm really not trying to hijack the thread. Even so:
>
> /* While I think "The C++ Programming Language" is a great
> book in many ways, Mr. Stoustrup's use of code fragments
> to illustrate his points, and his lack of complete
> executable example code, made it hard for me to use it for
> learning the language.
>
> Once I was comfortable with the language, however, I found
> his book delightful.
> */

Thanks.


> I've reread "The C++ Programming Language" several times.
> I agree that it isn't a good first book for learning the
> e language, but (IIRC), it's not advertised as one.

Correct.


> The book I used (and I would highly recommend) was
> "Computting Concepts With C++ Essentials," by Cay
> Horstmann.

I haven't looked at Cay's books for a long time so I don't have an opinion. That allows me to ask an open-ended question: What makes a good C++ textbook? For which target audience? Why?

IMO one of the biggest problems with C++ is that it is so often mistaught (as either "C with a few new and largey useless advanced bits" or "an OOP language where they forgot to remove the complicated and dangerous C bits").

See also my "Learning standard C++ as a new language": http://public.research.att.com/~bs/new_learning.pdf


> Of course, it is now possible to learn from Stroustrup
> himself (http://courses.cs.tamu.edu/petep/ click on
> notes).

Eventually, that'll become a book, but (as everything else worthwhile) writing a good book takes time.


> ...
>
> Thinking about it, my paperback is about gone. I guess
> it's time to get a hardcover copy.

A sign of good use. The newer printings also have many corrections and clarifications - it's amazing what a few hundred thousand readers ca find :-)

-- Bjarne Stroustrup; http://www.research.att.com/~bs

Thomas Guest

Posts: 236
Nickname: tag
Registered: Nov, 2004

Re: A Brief Look at C++0x Posted: Jan 7, 2006 12:18 PM
Reply to this message Reply
re:- C++ libraries

> I was primarily thinking of Java and C# where corporations
> are buying marketshare through "free" libraries.

Right. I was also thinking of the dynamic languages -- Python, Ruby, Perl etc.

I know little about C#, but as a newcomer to Java I'm impressed by the quality of the libraries, not just from Sun but also from organisations such as Apache which can build on the standard libraries. I think the general acceptance of Javadoc and the Sun Java programming conventions makes these libraries more accessible.

[snipped lots of good points I agree with]

> > Boost is the leading supplier of free C++ libraries,
> but
> > these libraries are often relentlessly modern C++ --
> > meaning they may not be suitable for use on some
> platforms
> > (due to poor compiler support), and on other platforms
> a
> > simple user mistake yields frightening compiler output.
>
> I wouldn't critize Boost for being "modern". I think the
> real problem is that many "boosters" are interested in
> "neat/advanced" libraries rather than in providing
> yet-another, but more standard and usable directly useful
> component. For example, why weren't boost threads, boost
> sockets, boost XML, boost unicode, and boost files among
> tthe very first boost components? Such foundation for
> applications are hard and non-glamorous - it takes a major
> effort to get people to create and maintain such
> components.

No, I don't criticize Boost for being modern, and I am a happy Boost user. I only wanted to point out that there are pragmatic reasons why C++ coding shops might choose not to adopt Boost.

> Note that there were literally thousands of C++ libraries
> before boost. For example see the C++ libraries FAQ (link
> on my C++ page). What boost did differently was to create
> a visible site and a process for quality control and
> documentation.

Yes, the Boost standards are high.

[snip more good stuff]

Ion Gaztañaga

Posts: 8
Nickname: igaztanaga
Registered: Jan, 2006

Re: A Brief Look at C++0x Posted: Jan 7, 2006 12:28 PM
Reply to this message Reply
> > > I think that the greatest strength of "other
> languages"
> > is
> > > not that they are better languages, but that they
> come
> > > with larger collections of "free" libraries.
> >
> > I agree, the large collections of free libraries are a
> > major attraction of other languages, but this does beg
> the
> > question: why are there fewer freely available C++
> > libraries? After all, C++ has been around longer than
> many
> > of these languages.
>
> I was primarily thinking of Java and C# where corporations
> are buying marketshare through "free" libraries.

Maybe I'm just too foolish, but being C++ a very important language for major entreprises in SW world, can't the standard committee or members of the committee request help to companies to have resources? I mean, Herb Sutter is at Microsoft, Howard Hinnant at Apple..., couldn't they convince their enterprises with the blessing of the committee to have ONE person to form a library implementing group for C++ proposals?

I mean, take one person from Google, Microsoft, IBM, Novell, Red Hat, Siemens, Borland, Sony, Intel... and form a group that develops proposals (with implementation) for missing BASIC C++ libraries (thread, ipc, xml, threads, etc...) with the help of Boost developers. Many good programmers from Free Software world would also like to contribute, for sure. Make a Boost development/review of that library (which would get public debate and major testing) and after that present it to the committee.

One company would never add many resources to build missing C++ library parts but I think that the committee members have important roles in many companies and relationship with many other companies and that forming a vendor-neutral, open group just having ONE person from each major company and volunteers. If that is blessed or pushed (officially or not) by the committee itself I think that we have chances to have quite a big group of developers, because C++ is very important for many companies.

Maybe it's just I'm having a hippy "make love, not war" day, but shouldn't we try to do something like that? 2010 without ipc, xml, DB is just sad.

Bjarne Stroustrup

Posts: 60
Nickname: bjarne
Registered: Oct, 2003

Re: A Brief Look at C++0x Posted: Jan 7, 2006 1:43 PM
Reply to this message Reply
> Maybe it's just I'm having a hippy "make love, not war"
> day, but shouldn't we try to do something like that? 2010
> without ipc, xml, DB is just sad.

Oh, there are of course libraries for that. However, they are not standard, some are proprietary, some are not supported, some are not well documents, some are hard to find.

Typically, the problem is not that there is no solution. Most often the problem is that there are many. For exmaple, people complain that there is no C++ GUI. In fact there are 25+ C++ GUIs, and some are good. However, that adds to the confusion and to the standardization problem. How would the committee start? By choosing one and gain the instant opposition of the other 24+ sub-communities?
How would a user start to choose among the 25+?

These problems are *hard*. Over the years, I have made suggestions about a small (3 to 5 person) "secretariat" to coordianate C++ standards development and champion some proposals. My strong impression is that the people with a budget prefer to keep one person in-house rather than to pay for half a person on a 5-person team that they don't control.

-- Bjarne Stroustrup; http://www.research.att.com/~bs


PS Let me reiterate: There is *a lot* of great C++ "stuff" out there. My impression is that most users could do much better in their daily work than they do now if they spend a couple of days selecting a library or two and built on those. It is just annoying that we can't have even more and do what we do even better.

Ion Gaztañaga

Posts: 8
Nickname: igaztanaga
Registered: Jan, 2006

Re: A Brief Look at C++0x Posted: Jan 7, 2006 3:20 PM
Reply to this message Reply
> Oh, there are of course libraries for that. However, they
> are not standard, some are proprietary, some are not
> supported, some are not well documents, some are hard to
> find.

I know. For example, ACE is a tested framework for networking. Can't we present it as candidate for standarization? Yes, I know this can be a war, why this and not other (for example, boost candidate asio)? Some will prefer one, others another, but I prefer having a not perfect (meaning the library I wouldn't choose) networking standard library than not having any.

> Typically, the problem is not that there is no solution.
> Most often the problem is that there are many. For
> example, people complain that there is no C++ GUI. In fact
> there are 25+ C++ GUIs, and some are good.

GUI is perhaps a hard issue. But interprocess communications are pretty standard. For example: can't we present a wrapper (or better said, C++ style interface) over POSIX ipc? Maybe it wouldn't be the perfect candidate for many. But it works, it's portable and it's tested.

> PS Let me reiterate: There is *a lot* of great C++ "stuff"
> out there. My impression is that most users could do much
> better in their daily work than they do now if they spend
> a couple of days selecting a library or two and built on
> those.

Yes, I agree. But there is a big difference between "known" and standard. Before STL everyone had its container implementations. There were many "known" containers. But everyone wanted to develop them. Why? Maybe because you don't have control over that library. You don't know if it has many bugs or not. You don't know if that library will work in other compilers. If it is going to be developed for the next OS version. Every vendor would tell you that their library was great. But you are locked with one vendor.

STL was an experimental project and ended being one of the best examples of great architecture. Many other languages have copied STL. Now programmers don't use their own containers. For many uses STL containers are similar to previous "known" containers. But since they are standard and you know that every C++ compiler will have them, you use them (and because their performance is great). I don't know if people complained saying "hey, we have also these great containers! Why choose Stepanov's ones?", but C++ adopted them and that was the end of the history. A bad library choice is better than not having one. When the choice is a great library like STL, then it's perfect. The same with iostreams. Many don't like them. But everyone use them and that was the end of that war.

Not that I am critizising the committee. I know that they are volonteers, and obviously, revising wording, seeing if this new feature breaks another C++ feature is certainly a big task. I'm just now doing a library for boost inclusion (Shmem), which includes shared memory, memory mapped files, STL containers in shared memory, and so on. I don't know if it is going to be accepted. But what I know is that if C++ had chosen a simple wrapper over posix shared memory, I would have never developed this. Maybe my approach is better, but if there is something that works already accepted (and that would mean that it was a good library, because the committee surely knows much more about C++ and programming than me) the war is over.

An example: I think we can try to pick one matrix library (for example MPL) as standard (with modifications, reviews, of course) or choose three matrix libraries, write authors, and offer them if they would like to build the standard C++ matrix library. I know it's better said than done. But if we don't have resources to make a new library, we have to choose from existing efforts. We'll hurt someone (why that and why not this?) but once that library is standard (and of course, that's because the library offers good enough interface and perfomance, after revising the candidate) we can move to another issue.

Just my 2 cents. Sometimes I feel that in this world of overpromoted, marketing-guided, programming languages, if C++ continues to be to me the most important and versatile programming language is because it's a very good and very effective language. It's because you can push the machine to the limit. That's why the Java virtual machines are programmed in C/C++.

Enough posting for me about this topic for some months: this is as hard as a KDE/GNOME debate. Good luck and thanks for the article.

Alexander Davydkin

Posts: 2
Nickname: aadav
Registered: Jan, 2006

Re: A Brief Look at C++0x Posted: Jan 7, 2006 8:34 PM
Reply to this message Reply
First of all I want to give respects to Bjarne Stroustrup for the most powerful programming language I ever seen.

I am not so good in english, so I didn't carefully read all posts here nor other articles about new generation of C/C++. Probably I will repeat some of ideas, if so - just ignore me.

Practice of programming big OOP projects shows me two weak things in C++ which I think MUST be solved in the next generation of language.

First of all: dynamic object creation by some class id.
It is very often operation in programs which maintains polymorphic object's collections. So I very often suffer from declaring ugly macroses like DECLARE_DYNAMIC and own implementations of minimalistic RTTI tables for that behaviour.
As I see, Bjarne, you do not want to put any overheads into language and do not want to impose full dynamic RTTI to programs. However such things as DECLARE_DYNAMIC makes me crazy too often and I think there should be the compromise. For example keyword "dynamic" which marks class able to dinamically create its instances through single standard function void *create_object( char *class_name ) or something like that.
Really I think EVERY OOP project with collections of polymorphic objects needs that ability, so overheads are insignificant, especially with "marked" classes.
Of course also there are such needs in "properties" and "reflection" mechanisms, but not so often. I'll discuss this later.

The second problem is: after each time I add new data member to the class I forget to add a few important lines of obvious code to program. Typical examples are: serialization methods, log/dump activities.
I see perfect solution in conjuction of generic programming with embedded MPL concept.
Let's see next pseudo-code:

class some_class
{

[persistent] int data1, data2; // serialization code can be generated automatically
...
void save_to_stream( stream &s )
{
mpl_for_each_data_member([persistent] x){ s << x; };
};
};

This is some kind of treating marked data-members as compile-time collection (tuple) which can be manipulated in generic manner. This doesnot involves any overhead and as I see similar ideas was mentioned.

Thanks.

Flat View: This topic has 150 replies on 11 pages [ « | 2  3  4  5  6  7  8  9  10 | » ]
Topic: JSF and JSP: What's New in Java EE 5 Previous Topic   Next Topic Topic: My Most Important C++ Aha! Moments...Ever

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use