|
Posts: 32 / Nickname: cda / Registered: February 11, 2003 0:06 PM
A Brief Look at C++0x
January 2, 2006 2:00 PM
|
|
Bjarne offers a sneak peek at the next version of standard C++ ("C++0x") which should be complete by 2009.
http://www.artima.com/cppsource/cpp0x.html |
|
Posts: 4 / Nickname: qrczak / Registered: October 22, 2004 11:19 PM
Dynamic recognition of exceptions
January 3, 2006 5:35 PM
|
|
Here is one thing which I wish C++ had, which would improve the possibility of linking it with other languages, and which I believe seems realistic to add.
It's currently impossible to write a generic wrapper around a piece of code which catches arbitrary exceptions it might throw, and materializes them in a form which allows to check their type dynamically and rethrow them from elsewhere. This means that when we are wrapping a C++ library in another language which implements exceptions differently than C++ does, for each piece of wrapped C++ code we must statically know all types of exceptions it might throw. For others we can at most add a generic catch (...) clause, and there the exception object will be lost, even if the control flow tunnels through the other language to another piece of C++. We can't save the exception object for later if we don't statically know the possibilities for its type!
|
|
Posts: 8 / Nickname: igaztanaga / Registered: January 3, 2006 9:57 PM
Re: A Brief Look at C++0x
January 4, 2006 11:22 AM
|
|
First of all, thanks to Bjarne for creating this wonderful language.
Regarding the article, I don't like much the syntax: template<class T> using Vec = vector<T,My_alloc<T>>; I would prefer using "typedef" and the possibility of strong typedefs, so that we can predeclare Vec. I think these new features are ok but we need libraries for network, serialization, inter-process communication, xml, data-base, threads... Boost is a great effort that I think will push C++ a lot in many areas. Apart from features of the article, and following recent C++ discussions, I'm very impressed with the "move" semantics and their performance boost. We can avoid a lot of memory allocations with them (we can build a container of noncopyable elements, for example). I don't think garbage collector is needed at all. I think that breaks C++ constructor/destructor model (when are the destructors called?) and that new smart pointers can avoid nearly all manual memory management. And memory is not the only resource you have to manage, so I don't know if garbage collector overhead is justified. I would also like to see utilities for low-level programming: -> Controlling alignment. -> Guarantees of binary layout for structs with constructor/destructor and no virtual functions and inheritance (enhanced POD-s). I think that it can be a good way to make class and struct different (struct would offer guarantees, but class is allowed to reorder members). I think that almost every C++ compiler uses C struct rules when the struct has constructors/destructors, so this wouldn't be breaking. This will be a HUGE help when programming these type of low-level structures. Anyway, thanks for the article and I will continue reading all WG21 papers. I think C++ has a bright future. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 4, 2006 11:43 AM
|
|
> First of all, thanks to Bjarne for creating this wonderful
> language. Thanks > Regarding the article, I don't like much the syntax: > > template<class T> using Vec = vector<T,My_alloc<T>>; > > I would prefer using "typedef" So did I initially, but I'm convinced that getting the name being declared up front is very important. My guess is that you'll get used to it or even get to appreciate it when you get to deal with more complex examples. > and the possibility of > strong typedefs, so that we can predeclare Vec. There are several meanings of "strong typedef". Some are being explored and none are directly related to template aliases. > I think these new features are ok but we need libraries > for network, serialization, inter-process communication, > xml, data-base, threads... Boost is a great effort that I > think will push C++ a lot in many areas. Yes. That was the idea behind boost. > Apart from features of the article, and following recent > C++ discussions, I'm very impressed with the "move" > semantics and their performance boost. We can avoid a lot > of memory allocations with them (we can build a container > of noncopyable elements, for example). yes. > I don't think garbage collector is needed at all. I think > that breaks C++ constructor/destructor model (when are the > destructors called?) and that new smart pointers can avoid > nearly all manual memory management. And memory is not the > only resource you have to manage, so I don't know if > garbage collector overhead is justified. but other people vigurously disagree. My guess is that we will find a solution that will be helpful to many and disasterous to none. > I would also like to see utilities for low-level > programming: > > -> Controlling alignment. being worked on. > -> Guarantees of binary layout for structs with > constructor/destructor and no virtual functions and > inheritance (enhanced POD-s). I think that it can be a > good way to make class and struct different (struct would > offer guarantees, but class is allowed to reorder > members). I think that almost every C++ compiler uses C > struct rules when the struct has constructors/destructors, > so this wouldn't be breaking. This will be a HUGE help > when programming these type of low-level structures. The snag is that C doesn't have such layout guarantees either. however, we do encourage layout compatibility of PODs with their C equivalents and I don't know of any C++ compiler that doesn't provide that. No fundamental distinction between classes and structs will be introduced. > Anyway, thanks for the article and I will continue reading > all WG21 papers. I think C++ has a bright future. So do I. -- Bjarne Stroustrup; http://www.research.att.com/~bs |
|
Posts: 2 / Nickname: nidoizo / Registered: December 29, 2004 8:37 PM
Re: A Brief Look at C++0x
January 3, 2006 6:39 PM
|
|
First of all, I would like to give you two thumbs up Mr.Stroustrup for a language I've been using with passion for so many years.
There's two things I find missing in the article, and I hope it doesn't mean they won't appear in C++0x. The first one is a module concept. I find #includes and everything they imply, like include guards, separated .hpp and .cpp, compiler-dependent precompiled headers, etc. to be the worst part of C++. I would hope the standard would define common grounds, something like an #import statement or proposed namespace<< syntax, that would simplify our day-to-day lives while still leaving compilers flexibility in the implementation. The second thing is better meta-programming tools. I don't know if a solution as ambituous as metacode keyword is possible, but there's a lot of things that could be simplified and possible with a complete compile-time language. Among these things, introspection, could also be possible with a more complete RTTI (but something like CTTI sounds better to me). Having the capability of iterating through members of a class would be wonderful for both implementers and users of libraries like Boost.Python. (I'm aware on some Daveed Vandevoorde papers on these subjects, so I guess it is still possible to see them in next standard.) Regards, Nicolas Fleury |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 3, 2006 7:32 PM
|
|
> First of all, I would like to give you two thumbs up
> Mr.Stroustrup for a language I've been using with passion > for so many years. Thanks > There's two things I find missing in the article, and I > hope it doesn't mean they won't appear in C++0x. > > The first one is a module concept. As you obviously know, there is work in progress on modules, but as ever "no guarantees". > > The second thing is better meta-programming tools. ... Among these things, introspection, could also > be possible with a more complete RTTI (but something like > CTTI sounds better to me). ... Most forms of meta-programming with a run-time representation of types are very expensive. For example, I'm told that common C++ applications under windows are 80% code and 20% data; when compiled under .Net (with .Net metadata) they become 20% code and 80% data. Calculate the bloat for yourself. Many applications cannot afford that. Also it is a huge amount of work to formalize a representation and finally, I worry about the correctness of code depending on "ad hoc" climbing of metadata graphs. I woudn't give high odds on this. -- Bjarne Stroustrup; http://www.research.att.com/~bs |
|
Posts: 2 / Nickname: nidoizo / Registered: December 29, 2004 8:37 PM
Re: A Brief Look at C++0x
January 3, 2006 10:13 PM
|
|
> As you obviously know, there is work in progress on
> modules, but as ever "no guarantees". Fair enough:) > > The second thing is better meta-programming tools. ... > Among these things, introspection, could also > > be possible with a more complete RTTI (but something > like > > CTTI sounds better to me). ... > > Most forms of meta-programming with a run-time > representation of types are very expensive. For example, > I'm told that common C++ applications under windows are > 80% code and 20% data; when compiled under .Net (with .Net > metadata) they become 20% code and 80% data. Calculate the > bloat for yourself. I agree that meta-programming in C++ should remain compile-time (sorry, I realize I wasn't clear). I'm more thinking of CTTI (compile-time type information) than RTTI. I remember having a quick exchange with David Abrahams where he ended suggested it would be nice to have the capability to get a mpl::vector of types of members. A compile-time list of member types for a type. > Many applications cannot afford that. Also it is a huge > amount of work to formalize a representation and finally, > I worry about the correctness of code depending on "ad > hoc" climbing of metadata graphs. The way I see it, the representation is already formalized, since members already have types. What is needed is a standard compile-time type list (so far, just extending STL) and a way to get 2 type lists, one of members of a type and another of its base classes. STL could contain the compile-time functions/typedefs to get these. It doesn't sound too bad to me. The only run-time overhead is the memory used to have also access to member names (but since it's compile-time, it's only for used member names). I believe compile-time introspection would be a very powerful tool (and that includes some compile-time checks that will be available in C++0x). I've actually developed a system adding introspection to C++ for our needs where I work and compile-time introspection would simplify both users life and mine (I would like to go on details on that system, contact/tell me if interested). > I woudn't give high odds on this. Even compile-time based? Regards and thx for reading me, Nicolas Fleury |
|
Posts: 21 / Nickname: cdiggins / Registered: February 4, 2004 1:54 PM
Re: A Brief Look at C++0x
January 4, 2006 10:44 AM
|
|
Thank you Dr. Stroustrup not only for designing an excellent language and providing so many of us opportunity for employment, but also for writing the article and participating in this forum.
I can't say enough good things about the design of C++, but they can't all fit here. Of course I have some suggestions, but this isn't an appropriate forum for them. To be honest, I feel like any suggestions I made here, would fall on deaf ears. Your article is not asking for our feedback, but simply telling us what the committee has decided. The committee seems to have a pretty clear vision of what it is going to do, and how it is going to do it, irregardless of the viewpoints of the community. The only point I do want to bring up is that it is very hard for people with little or no formal academic background and little funds or resources (e.g. myself) to make contributions or suggestions for the direction to the language. Other languages welcome or encourage community feedback and participation, whereas C++ seems to have an ivory tower approach to the language design. You may not agree with this characterization, but from my point of view and that of many other enthusiastic C++ users that is the case. The only publicly accessible place for contributions is the comp.std.c++ newsgroup where the attitude is consistently patronizing and dismissive. As a result the language is moving in direction which is guided more by compiler implementers, experts who've forgotten their humble beginnings, and academics, leaving the rest of us out in the cold hoping you will throw us a bone. Part of the problem excluding the majority of users from the evolutionary process, is that some very poor decisions get made, and some very good opportunities are overlooked because the knowledge pool you are drawing upon is simply too narrow. I understand language design isn't easy, but I think more transparency, and community involvment is warranted, especially early on with proposal and such, and is crucial for C++ to continue to be a relevant programming language over the long term. There are a lot of advanced users who may have a thing or two to say about the language proposals. |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: A Brief Look at C++0x
January 4, 2006 1:48 PM
|
|
> Your article is not asking for
> our feedback, but simply telling us what the committee has > decided. The committee has been soliciting feedback for several years, now, for the next version of standard, and have got lots of feedback and contributions. However, at the Lillehammer meeting last spring, it was decided that in order to be able to publish the standard in 2009 (ISO standards are updated/confirmed in about 10 year intervals, and the current standard is from 1998, with a 2003 revision/correction), a cutoff-date for new proposals was set half a year into the future, to last year's fall meeting, and I think this has been mentioned in articles, etc. about the development of C++. This is because the committee already have more on its plate than can reasonably be implemented (given there's only two meetings per year), but it was also said that new proposals could still be submitted after that time - there just weren't any guarantee that the committee would get a chance to consider it. > The only point I do want to bring up is that it is very > hard for people with little or no formal academic > background and little funds or resources (e.g. myself) to > make contributions or suggestions for the direction to the > language. Other languages welcome or encourage community > feedback and participation, whereas C++ seems to have an > ivory tower approach to the language design. C++ is an ISO standard, and as such, there are procedures regarding how, and how often, it may be changed. Independent language developers (like yourself) are not that "constrained" by issues like this (or the concerns of millions of existing users, and ditto lines of existing code). However, if you or anyone else have any suggestion for ways to improve community interaction, or other ways to improve the development of the language, I'm sure it would be most welcome. Just remember that it typically takes someone to do it, as well... > I understand language design isn't easy, but I think more > transparency, and community involvment is warranted, > especially early on with proposal and such, and is crucial > for C++ to continue to be a relevant programming language > over the long term. Yes, this is all good and fine, but how? The proposals are all publicly available at the standards site. If someone would like to get directly involved in the standards work, they can contact their ISO "national body" (the organization in their country affiliated with ISO), and request membership. Unfortunately, in many countries, this costs a yearly fee, that goes to paying ISO. You then get access to the mailing lists of the committee, and so on. Then there's the newsgroups that have been mentioned. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 4, 2006 11:33 AM
|
|
> I can't say enough good things about the design of C++,
> but they can't all fit here. Thanks > Of course I have some > suggestions, but this isn't an appropriate forum for them. > To be honest, I feel like any suggestions I made here, > would fall on deaf ears. Your article is not asking for > our feedback, but simply telling us what the committee has > decided. Actually, I often ask for input. For example, http://public.research.att.com/~bs/rules.pdf . This latest paper (being extremely short) just happens not to say so explicitly. > The committee seems to have a pretty clear vision > of what it is going to do, and how it is going to do it, > irregardless of the viewpoints of the community. I wish the committee had a clearer vision, but then diverse groups rarely have. What the committee does have - which is not well understood in the community - is a rather strong understanding of its own limitations and constraints. There are just so many things we'd like to do, but so littel time and so few resources. > The only point I do want to bring up is that it is very > hard for people with little or no formal academic > background and little funds or resources (e.g. myself) to > make contributions or suggestions for the direction to the > language. Other languages welcome or encourage community > feedback and participation, whereas C++ seems to have an > ivory tower approach to the language design. I don't think so, if you want ivory tower approaches, have a look at the hundreds of academic language projects - however, do take an advanced course in type theory before you start. The C++ approach is very pragmatic and seriously constrained by real-world concerned. Making changes to a language used by millions is challenging, so you can't just walk in and say "I like that so we should do it and expect people to listen". However, all the written material (more than you ever wanted to see) is available on the WG21 site. The standards process is open and - believe it or not - cheap compared to other processes defining our world. Try affecting the way a DVD is encoded or what it takes for a pilot is certified to see what I mean. I believe that the simple fact that a fair part of our civilization depend on C++ code implies some requirements and constraints. However, the investment for an individual is mostly time (weeks a year) and - if you want to vote - $800 a year. > You may not agree with this characterization, but from my > point of view and that of many other enthusiastic C++ > users that is the case. The only publicly accessible place > for contributions is the comp.std.c++ newsgroup where the > attitude is consistently patronizing and dismissive. comp.lang.c++.moderated is less rude. The members of the committee makes all the committee documents available (on the WG21 site) and many of us give talks and write papers to raise interest and get feedback. I have now personally been talking about the design of C++0x and listend to responses for 5 years. > As a result the language is moving in direction which is > guided more by compiler implementers, experts who've > forgotten their humble beginnings, and academics, leaving > the rest of us out in the cold hoping you will throw us a > bone. Not a kind characterization and the "throw a bone" is simply unfair. > Part of the problem excluding the majority of users from > the evolutionary process, is that some very poor decisions > get made, and some very good opportunities are overlooked > because the knowledge pool you are drawing upon is simply > too narrow. How do you draw on 3 million people? Many of us in the committee are acutely aware of our limitations. However, we are not excluding anyone, we just don't know how to further lower the barriers to entry and also make progress. > I understand language design isn't easy, but I think more > transparency, and community involvment is warranted, > especially early on with proposal and such, and is crucial > for C++ to continue to be a relevant programming language > over the long term. There are a lot of advanced users who > may have a thing or two to say about the language > proposals. It will be hard to increase "transparency" since already every paper is available and every meeting is public. One problem is actually that *every* programmer (advanced or not) is more than willing to give an opinion after almost a minute of thought. That tends to drown out the thoughtful contributions. Just have a look at yesterday's "discussion" on /. -- Bjarne Stroustrup; http://www.research.att.com/~bs |
|
Posts: 21 / Nickname: cdiggins / Registered: February 4, 2004 1:54 PM
Re: A Brief Look at C++0x
January 4, 2006 3:06 PM
|
|
> Actually, I often ask for input. For example,
> http://public.research.att.com/~bs/rules.pdf . This latest > paper (being extremely short) just happens not to say so > explicitly. My apologies then, you are clearly more interested in feedback than I gave you credit for. > Not a kind characterization and the "throw a bone" is > simply unfair. My apologies again, that was indeed far more rude than I intended. > How do you draw on 3 million people? Many of us in the > committee are acutely aware of our limitations. However, > we are not excluding anyone, we just don't know how to > further lower the barriers to entry and also make > progress. It seems to me it would not be so hard to create a process where the public can submit small semi-formal requests for language changes and language features. These could be sorted and grouped and summarily evaluated by a panel of experts, in order to look more closely at those with the most promise and request more details from the submitters. This process would be useful for the committee to identify trends and general public opinion. Funding such a project could be done by community members who paid a nominal fee (e.g. $25) to join in order to be allowed to submit topics and discuss them. > It will be hard to increase "transparency" since already > every paper is available and every meeting is public. Yes, transparency is the wrong word sorry. > One problem is actually that *every* programmer (advanced > or not) is more than willing to give an opinion after > almost a minute of thought. That tends to drown out the > thoughtful contributions. Just have a look at yesterday's > "discussion" on /. I sympathize with that. In fact I refuse to read Slashdot anymore, the level of discussion there is an embarassment to the technical community. I am actually surprised you bothered to read it. Well I really appreciate very much you taking the time to write back, and to read what I had to say. I look forward to using the C++ 0x. Keep up the excellent work. I greatly appreciate the attention to detail and the fine craftmasnship that has gone into the creation of C++. |
|
Posts: 6 / Nickname: vorlath / Registered: December 16, 2005 1:35 AM
Re: A Brief Look at C++0x
January 4, 2006 6:04 PM
|
|
I think properties should be part of the language. This is just too useful in practice not to have directly in the language. I know of Strousup's reluctance to this, yet I don't get it. This is the single best feature of the language, yet it's not official nor found in most implementations.
I realise that this cannot be changed now that the language has been used for so many years, but the "private" keyword should really have signaled a class as being final and un-subclassable/non-virtual. private should not be allowable if there are virtual functions. This has caused no end of aggravation in code reuse, especially in compiled libraries. An object should always have the right to look at ALL of its own private parts no matter its lineage. Otherwise, virtual functions lose their virtual-ness by possibly using private data. You could blame this on the implementor, but in practice, it's not that easy. You can't foresee how people will use your code. I also agree with another post that alignment should not be made in pragmas or __attribute__(())'s. They should be in the language itself and should be readable from object code. Otherwise, it's impossible to use two different libraries that use different alignments without purposely padding structures. These are real-world situations that have caused the most amount of aggravation IMHO. |
|
Posts: 6 / Nickname: vorlath / Registered: December 16, 2005 1:35 AM
Re: A Brief Look at C++0x
January 4, 2006 6:06 PM
|
|
Gotta watch ctrl-z. I meant to type Mr. Stroustrup. Sorry for the "typo" and I can't find the edit button.
|
|
Posts: 2 / Nickname: aadav / Registered: January 7, 2006 2:17 PM
Re: A Brief Look at C++0x
January 7, 2006 8:34 PM
|
|
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. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 8, 2006 8:16 AM
|
|
> First of all I want to give respects to Bjarne Stroustrup
> for the most powerful programming language I ever seen. Thanks > 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. but what does "MUST be solved" mean in the context of a formal standard written by volunteers? > 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. Please explain. What is it you do that can't be handled by a simple factory? (i.e. a use of the factory pattern) > 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 > an 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. But as far as I can judge, doing this in general rather than for a particular problem would involve a complete interface to a compiler's information. That's distinctly non-trivial. I am working in this area - using tools external to the compiler - and dealing with desclaration in general (incl. templates, specializations, access controls, etc.) is not easy to make accessible. -- Bjarne Stroustrup; http://www.research.att.com/~bs |
|
Posts: 2 / Nickname: aadav / Registered: January 7, 2006 2:17 PM
Re: A Brief Look at C++0x
January 8, 2006 9:36 AM
|
|
First of all let me explain my point of view to the evolution of programming techniques.
This evolution makes one important things: simplifies process of programming. How does it? I think there is two means by thich it is done: 1. decreasing size of code which must be written to accomplish a task 2. decreasing inner relations between parts of program code which depends each on other Examples of evolution by first point are: functions, templates, inheritance of classes, damned automatic garbage collectors, C++ algorithms. All this techniques decreases size of code I must write to accomplish my programming task. Examples of evolution by the second point are: variables/functions symbolic names (instead of direct memory addresses), incapsulation, smart pointers or auto GC again, OOP at all. I think the main goal of this techniques is: if I (re)write some part of code I need no to review another parts of it. So... I call "error-prone code" such code which: 1. is longer and more complex than it can be 2. forces me to seek and (re)write another code then I want to (re)write this code So this is my criterion to the "ideal" programming language/technique: 1. I need to write only minimal text of code 2. I need to rewrite only minimal text of code Quite simple, isn't it? :) Some other languages solves these problems by reducing its complexity and flexibility (for example - GC). That is no way for C++. So now I can express why I want to have mentioned modifications to the C++ language: I do not want more to write my own implementations of class factories which usual based on boring macroses DECLARE/IMPLEMENT_DYNAMIC. Also I do not want more to seek in the *.cpp and rewrite serialization or zero-fill-initialization code every time I add new data member in the *.h to the class. Some other languages have built-in facilities to simplify this tasks. Such as full dynamic run-time-TI with reflection API. C++ have great potention to solve this tasks easily in the compile-time. And I wish it. :) This is my point of view and I hope you will agree with it. However it is just a wish. :) Probably you can solve this "evolution questions" in another manner. Also I think that new generation of C++ will be the super-language when boost can be rewritten in it without using macroses. :) Thank you. |
|
Posts: 5 / Nickname: chrism22 / Registered: September 28, 2005 3:59 AM
template typedef work-around
January 5, 2006 9:43 AM
|
|
Until template typedefs are available, there is a work-around which can confer some of the benefits:
This can also be a useful way to isolate the dependency of a program on the particulars of the library it uses. For example, the g++ standard library provides a hash map in the __gnu_cxx namespace that you access through the header file <ext/hash_map> . If you care about program portability, you don't want to type "__gnu_cxx::hash_map" or "#include <ext/hash_map>" more than once. Suppose you are writing a C++ program and need hash tables that always take strings as key values. We gather the necessary typedefs in the struct shmap (short for "string hash map"). Putting this in the header file string_hash.h:
You could then use it like this:
|
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: template typedef work-around
January 5, 2006 11:03 AM
|
|
> Until template typedefs are available, there is a
> work-around which can confer some of the benefits: > > template <class T> struct aliases {The use would be: aliases<double>::vec v;but otherwise, it'll work. Note that, unlike real template aliases (and except for the syntax difference), the above won't allow template parameter deduction: > This can also be a useful way to isolate the dependency of > a program on the particulars of the library it uses. > > For example, the g++ standard library provides a hash map > in the __gnu_cxx namespace that you access through the > header file <ext/hash_map> . If you care about program > portability, you don't want to type "__gnu_cxx::hash_map" > or "#include <ext/hash_map>" more than once. > > Suppose you are writing a C++ program and need hash tables > that always take strings as key values. We gather the > necessary typedefs in the struct shmap (short for "string > hash map"). > > Putting this in the header file string_hash.h: > > #include <ext/hash_map>I wouldn't put a using-declaration in a header-file... (at least in the global namespace) That would make it have effect on any subsequent includes, too. > struct string_hasher_op {> > You could then use it like this: > > #include <iostream>I'd think that it's things like this that namespaces were meant for, and it would be a shame if we couldn't use them for it. How about (simplified example using just one template parameter): Of course, this requires that the name and parameters of the map is the same (which it may not be, and in that case, you may need some kind of adapter/wrapper, anyway). |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: template typedef work-around
January 5, 2006 11:28 AM
|
|
Oops, since you bind some template parameters (not just want to be able to select between versions in different namespaces), my example wasn't really a full replacement to your example, and therefore wasn't very relevant in this case.
|
|
Posts: 5 / Nickname: chrism22 / Registered: September 28, 2005 3:59 AM
Re: template typedef work-around
January 6, 2006 9:40 AM
|
|
>
> Note that, unlike real template aliases (and except for > the syntax difference), the above won't allow template > parameter deduction: > 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 |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: template typedef work-around
January 7, 2006 6:20 AM
|
|
> > Note that, unlike real template aliases (and except for
> > the syntax difference), the above won't allow template > > parameter deduction: > > > > 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... |
|
Posts: 5 / Nickname: chrism22 / Registered: September 28, 2005 3:59 AM
Re: template typedef work-around
January 8, 2006 11:39 AM
|
|
> 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: I see. Thanks for pointing that out and telling me where to look the deductions list up. You're being very helpful. > 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... I'm not sure I see the problem with the code you wrote. If f() were called at a point in the translation unit after the specialization were introduced like this:
then I imagine that the deduction algorithm would stop the compilation with an error message to the effect that there was no acceptable value for T that could successfully instantiate f as used in f(x). I don't see how we would be any worse off in that case than without the additional deduction rule. Without it, deduction fails more often than with it. Chris Marshall |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: template typedef work-around
January 8, 2006 3:32 PM
|
|
> > 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... > > I'm not sure I see the problem with the code you wrote. > If f() were called at a point in the translation unit > t after the specialization were introduced like this: > > struct aliases<double> x; > f(x) > > then I imagine that the deduction algorithm would stop the > compilation with an error message to the effect that there > was no acceptable value for T that could successfully > instantiate f as used in f(x). > > I don't see how we would be any worse off in that case > than without the additional deduction rule. Without it, > deduction fails more often than with it. The problem is that if it did the deduction _before_ the specialisation was encountered, then when the specialisation was encountered, the deduction it did earlier would be wrong. One way around it might be that it keeps track of what deductions it has done, and then reconsiders them, if there are any specialisations. However, there might be other problems with this. Consider what is to be deduced: template<class T> void f(typename aliases<T>::vec) { ... } (*) Now you call f with a value of type X: X x; f(x); Here, the compiler will have to search a theoretically unbounded number of specialisations, to find an instantiation of aliases<T> that has a "vec" member with the type X. Note that, in the general case, "vec" can be the result of an arbitrarily complex type-computation, that the compiler could have a very hard time of "running backwards" to find the right value for the template parameters (and any other compile-time values being used in the computation). (*) "typename" is actually required, even though many compilers will let you get away with it, because - before instantiation time - the compiler doesn't know that "vec" is a type, or something else. I see I didn't use this in the earlier posting. |
|
Posts: 5 / Nickname: chrism22 / Registered: September 28, 2005 3:59 AM
Re: template typedef work-around
January 6, 2006 7:00 AM
|
|
> The use would be:
> > aliases<double>::vec v;> > but otherwise, it'll work. Oops! > I wouldn't put a using-declaration in a header-file... (at > least in the global namespace) That would make it have > effect on any subsequent includes, too. Yes, I agree the natural thing to do is wrap the shmap delcaration inside a namespace, which is exactly what I did when I first wrote it. For posing here, however, I was trying to make the example as short as possible, and I decided the presence of the namespace would complicate the point I was trying to illustrate (the operation of the template typedef workaround). I've only been actively using C++ for about 2 years and I remember only too well how confusing some of its syntax can be. What I really needed when I was trying to crack it was complete, executable, and short examples showing how each language feature operated. 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. |
|
Posts: 18 / Nickname: mlybbert / Registered: April 27, 2005 11:51 AM
Learning C++
January 6, 2006 11:56 AM
|
|
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. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: Learning C++
January 7, 2006 10:51 AM
|
|
> 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 |
|
Posts: 5 / Nickname: chrism22 / Registered: September 28, 2005 3:59 AM
Re: Learning C++
January 8, 2006 11:28 AM
|
|
> 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? I can tell you why I had a hard time learning C++ from the books I looked at. I obviously can't speak for people whose minds work differently, or who get tripped up over different issues in programming ;-) Now, in my case, I had been programming in C, Java, and R for many years. I looked at TC++PL, "Thinking in C++" (Eckel), and "C++ Primer" (Lippman) and couldn't find what I was looking for in any of them. I didn't realize this until recently, but what I wanted to know about C++ (or, about any new language I try to learn) was how to translate it into C; if I can see how to translate a statement in language X into a set of statements in C to do the same thing, then I feel comfortable that I understand what the statement is doing in language X and am willing to learn more about the language. If I can't, then I feel like I am stumbling around in the dark, which drives me nuts. It has always amazed how much it is possible to do in C (and its preprocessor) given what a small language it is. I think this is another way of saying that C's way of thinking about what programs are doing is extremely well conceived. It is the algebraic notation of procedural programming, greatly simplifying the notational zoo that preceeded it (or that proceeded it's earliest ancestor with the same conceptual framework). BTW, I never had any problem learning how to reduce Java programs into C as I learned the language, which may be why some people have such an easier time learning it than C++. Here's a concrete example of what I mean. Take the following the C++ statements:
These are the corresponding C statements I wanted to see:
If I were to write a book on C++, my target audience would be people who know C and OOP (from another language) well and I would open chapter 2 with this example. I think most people who know Java well would fit in this audience. Chris Marshall |
|
Posts: 18 / Nickname: mlybbert / Registered: April 27, 2005 11:51 AM
Re: Learning C++
January 9, 2006 10:37 AM
|
|
I took the weekend off, so this is an answer to a question several pages ago (well, a couple of pages ago).
/* 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? */ I really got lucky with Cay's book, in that I went to the closest community college and bought whatever they were using. When I had a little knowledge under my belt, and saw what else was out there, I realized that I had dodged a serious bullet. I like Cay because he doesn't teach C first. IIRC (as I sold my book, and every so often I regret it), there was discussion about arrays, but the examples start using std::vector in Chapter 2 or 3. You learn how to use libraries, and you learn OOP principles several chapters before learning how to write classes. Then there were small asides about Therac, a misplaced break in AT&T's code, and why using a Social Security Number as a unique ID is a bad idea. I fit in the target audience of somebody who used BASIC and LOGO in elementary school, picked up a Perl CGI book and said "I wonder what C's like." To be honest, I was a little upset that the community college didn't have a C textbook. Of course today I can read C code, but I don't feel all that comfortable willingly keeping to structs and functions. /* IMO one of the biggest problems with C++ is that it is so often mistaught ... */ I have to agree. However, I have to say that overloading in the syntax is another large problem. I understand why '&' means "address-of," "reference" and "bitwise-and," or why "const" can appear in several different spots on a line to mean "make the pointer const," "make the target of the pointer const," "this method doesn't change the object's state," etc. There are several compiler vendors, and getting them to go along with changes must be murder. That, and picking good keywords that aren't already used as variables has got to be hard. And going to the other extreme (of adding a couple of new keywords for every new cocpets -- as Perl has done) certainly isn't attractive either. However, I would like a textbook to bring this point up. It took me a few times through "The C++ Programming Language" before I really had a solid grasp of why some of the syntax looked almost familiar, and why I kept falling into the same syntactic traps. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
A proposition for GC at library level.
January 8, 2006 2:44 PM
|
|
Now that we are here and big and famous people are reading this forum thread, I would like to propose a garbage collection solution that can be done in a library...it's actually very small and very easy to do, and I hope it offers good performance.
Let's see what we need for a minimal garbage collector: a) we need to know which objects are collectable. b) we need to know the root set. For knowing which objects are collectable, the solution is quite easy: an custom operator new places the allocated block in a linked list. Correspondingly, an custom operator delete removes the block from that list by erasing the block's iterator (stored before the block) from the linked list (i.e. removal takes constant time). The linked list is allocated as thread local storage, so as that there is no synchronization involved.For knowing the root set, the solution is, again, quite easy: a 'smart pointer' class pushes itself, during construction, in a pointer stack that exists as thread local storage; upon destruction, the pointer pops itself from the pointer stack. The pointer class does not need to have extra fields; it will be the same size as a normal pointer, and using TLS makes the operation quite fast. Garbage collection will be perfomed when the allocation size exceeds the GC user-defined limit, inside the allocation routine. The collector will be a simple stop-the-world, then mark-and-sweep algorithm: 1) all garbage-collected threads, except the current one, are suspended. 2) all pointer stacks of garbage-collected threads are traversed and reachable objects are marked. 3) all unreachable objects are deleted. 4) all previously suspended threads are resumed. This solution assumes very little: the only requirement is the existence of a thread library that allows thread local storage. What does everybody think? |
|
Posts: 18 / Nickname: mlybbert / Registered: April 27, 2005 11:51 AM
Re: A proposition for GC at library level.
January 9, 2006 11:25 AM
|
|
/* For knowing which objects are collectable, the solution is quite easy: an custom
operator new places the allocated block in a linked list. Correspondingly, an custom operator delete removes the block from that list by erasing the block's iterator (stored before the block) from the linked list (i.e. removal takes constant time). The linked list is allocated as thread local storage, so as that there is no synchronization involved.*/ I was thinking about something like this over the weekend. But then I started wondering if it qualified as an STL allocator, specifically that requirement that the allocator not keep certain per-object information so that swap can be optimized. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A proposition for GC at library level.
January 9, 2006 6:18 PM
|
|
> /* For knowing which objects are collectable, the solution
> is quite easy: an custom operator new places> the allocated block in a linked list. Correspondingly, an > custom operator delete removes the block from> that list by erasing the block's iterator (stored before > the block) from the linked list (i.e. removal takes > constant time). The linked list is allocated as thread > local storage, so as that there is no synchronization > involved. > */ > > I was thinking about something like this over the weekend. > But then I started wondering if it qualified as an STL > L allocator, specifically that requirement that the > allocator not keep certain per-object information so that > swap can be optimized. This appears to be a case where the one-object limitation would not be a burden: You don't often want several garbage collectors. The problem would be that you might not want all of your collected objects in a container and (worse) if you ever created a real pointer to such an object the scheme would fail. I think ideas in this direction are probably better considered under the heading of smart pointers or special allocation pools. For me at least, such a scheme would not serve where I actually want GC, because that's typically in situations where I feel that undiciplined use of resources is inevitable so that I need an all-emcompassing scheme to cope with the resulting mess. -- Bjarne Stroustrup; http://www.research.att.com/~bs |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A proposition for GC at library level.
January 10, 2006 4:13 AM
|
|
> The problem would be that you might
> not want all of your collected objects in a container and But all garbage collectors maintain a collection of allocated blocks, as just as all memory allocators maintain such a collection. Without such a collection, how would you know where your objects are? > (worse) if you ever created a real pointer to such an > object the scheme would fail. I don't think so (if I have understood correctly). First of all, the per-thread container of objects is not destroyed until a) the thread that owns it finishes and b) until the container is empty. Secondly, having a real pointer to such an object is not a problem, as long as there is another pointer to the object known to the collector. And my proposal was about having a special pointer class that pushes itself in a pointer stack that is thread-specific. You can't do better for GC than that unless you go in a lower level. > > For me at least, such a scheme would not serve where I > actually want GC, because that's typically in situations > where I feel that undiciplined use of resources is > inevitable so that I need an all-emcompassing scheme to > cope with the resulting mess. I agree, and that situation arises sooner or later in a C++ program, for the average programmer, especially if there are lots of changes and no clear design. What I know from talking to people is that they want to avoid thinking; some people that studied CS got out of it due to the complexity of programming...some others prefer other programming languages than C++, due to C++ being too complex for their tastes. |
|
Posts: 2 / Nickname: winnie / Registered: January 10, 2006 10:17 PM
auto/template typedef are really cool. What else?
January 11, 2006 3:59 AM
|
|
All
overloading by result - struct var
{
private:
float a;
float b;
public:
var(float _a, float _b) : a(_a), b(_b) {}
operator int() { std::cout << "get int !"; return (int(a) & (int)b); }
operator float() { std::cout << "get float !"; return int(a * b); }
};
int main_()
{
float x = var(1, 2);
int y = var(1, 2);
}
GC - simple reference counted smart_pointers are enough in most cases. But it's possible to write overcomplicated smart pointer, which can resolve "circular dependency" problem and there are industrial GCs for C++ (Boehm GC, f.e.) lambda - if '__typeof__' keyword will be introduced, then we can just use boost::lamda/phoenix - like libraries, which deduce all types. auto - IT'S GREAT! I'm missing it and vomited on BOOST_FOREACH-like hacks. will typeof/decltype feature be implemented? It's even more important, because 'auto' can be emulated - #define AUTO(var_name, initializer) (__typeof__(initializer)) var_name = initializer; but auto can't solve problem for _type_ deduction, nor declaration variables - ---------------------------------------------------------------- template <class T> __typeof__(false ?: a : b)
Max(const T &a, const T &b) { return a < b ? b : a }
----------------------------------------------------------------
template<class A_Function, class B_Function>
struct bind_sum_t
{
A_Function a_foo;
B_Function b_foo;
bind_sum_t(A_Function _a_foo, B_Function _b_foo) : a_foo(_a_foo), b_foo(_b_foo) { }
template <class X, class Y>
//__typeof__(a_foo(x) + b_foo(y))
int
operator()(X const &x, Y const &y)
{
return a_foo(x) + b_foo(y);
}
};
//mimics boost::lambda (_1 + _2)
template<class A_Function, class B_Function>
bind_sum_t<A_Function, B_Function> bind_sum(A_Function a_foo, B_Function b_foo)
{
return bind_sum_t<A_Function, B_Function>(a_foo, b_foo);
}
---------------------------------------------------------------- Will there be the __typeof__/decltype keyword ? Properities - You are bored on SetValue/GetValue? Use overloaded function Value instead.
if name of method is noun - than it's not action, it's property.
class Bar
{
private:
int m_iWidth;
public:
int Width() const { return m_iWidth; }
void Width(int w) { m_iWidth = w; }
};
usage: m_pBar->Width(10); int w = m_pBar->Width(); There is no syntax overhead! Neither at property declaration, nor at usage. Operator '=' is just Delphi/C# syntax sugar. And, of course, there are lots of C++ wrappers that can do this via overloaded operator= (for example, http://www.livejournal.com/users/_winnie/17358.html ^_^ - without memory/speed overhead, without handmade tedious initialization in constructor) C++ Demiurge How about attributes / reflection ? Managed C++ / C++/C++ prove that it can be integrated to C++. I'm bother with thousands "C++ reflection" and "C++ serialization" and "C++ advanced C++ RTTI" projects, and "CObjectBase" in each frameworks and custom fast implementation of "IsKindOf" in each framework(because dynamic_cast is slow/insufficient). What about 3D math? Every company/university lab has it's own math library. Sometimes two or three :) (Look at any free game engine / quake / etcÂ…). Of course, this is math libray use SSE. And they are all not compatible. And they all compatible via (SGI_Matrix*)(float *)&IBM_Matrix44. Why we should complicate С++ with initializes array? I see initialization of dynamic containers only in test/'learning exercise'/sample code, not in industrial code. And even in test there it can be solved with boost::assign for perverts or good old-fashioned int a[] = { 1, 2, 3, 4, 5, 6 };
std::vector<int> vec(a, a + ARRAY_SIZE(a));
It's not a problem at all! Why we should complicate С++ with '>>' template parameter list ending? There a lot more complicated problems for beginners - what is string literal? "hello world"? What is proper copy-constructor? How should I manage resources, so they won't leak when exception is thrown? What is pointer and why array are not pointers? Where I should use char * and where - std::string? A lot, lot, lot old-C questions about memory and pointers, but without whitch nobody can write robust C++ programs. And >> in templates is compile-time ill formed program, so it's safe. And good compiler can warn - And, of course the main beginner question - what is difference between . and -> and why in C# and other flooffy languages there is only . ? or less informative - And why do you not eliminate "no end of line at the end of file", which is UNDEFINED BEHAVIOR, and a lot of such no meaning details, if proceed the >> in templates? Which _really_GREAT features will be in C++0X ? Which ones can allow programmer programmer to use libraries, which will extend human ability to express his intentions to computer in C++ language. Sorry, I can't follow open-std/wg21 / n####.pdf's, there are heaps of them :( Thank you for the greatest and fastest null-overhead all-purpose language. Which is so powerful, that he can eat and mimics any other programming language. Thank you. PS. sorry for my funny poor Enlish, it's more difficult than C++ ^_^ |
|
Posts: 2 / Nickname: winnie / Registered: January 10, 2006 10:17 PM
Re: auto/template typedef are really cool. What else?
January 11, 2006 4:27 AM
|
|
misprints:
С++ -> C++ C++/C++ -> C++/CLI |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: A Brief Look at C++0x
January 11, 2006 8:49 AM
|
|
Regarding the discussion about GC and developer productivity. I'm a little wary of the request for, or promotion of, GC, as it may contribute to an ignorant attitude to, or bad habit of, resource ownership management. Given that GC doesn't automate this fully, in particular not lifetime management, at all, this may lead you into more troubled water, later in the life of the project.
To use an analogy: Would it be better use of your resources, if you, in a house: a) Fetch things from where they are stored, and put them back again when you're done with them. b) Fetch things from where they are stored, and just drop them on the floor when you're done with them, and hire a maid to regularly clean up after you... I remember learning Java, coming, as I did, from C++, where you're used to "clean up after yourself", and starting to just "drop things on the floor"... It just felt unnatural: "But I know I'll not need this object, anymore, can't you just delete it right away?". This may lead into an "illusion" that you don't need to care about memory ownership issues, until you meet the wall, one day, where you run out of memory, or the GC trashes, and you learn that you may have to set long-lived references to null, or the objects they refer to won't be collected, and that if you create lots of objects, in particular big ones, that are needed for a short time (like the Image objects in my project), you may run into such problems. So... You may come to, at least for some applications, that the memory management issues could be _easier_ with RAII and smart pointers, because you only heap-allocate what you need to heap-allocate, and you get very specific, deterministic lifetime of it (and you might use memory pools, etc.), than with an unpredictable GC. For example, if you need to explicitly null references, for them to be collected, what have you gained? You may run into _harder_ problems, trying to figure out what references are kept where (there may be large structures "kept alive" with a reference that in reality is no more used, but can't be collected because of it). Someone (I think it may have been Robert C. Martin in "Agile Software Development") made the analogy of keeping your code in shape, to working in a tidy kitchen: Everyone knows it goes fastest to prepare food in a tidy and clean kitchen. You may save a little time, by not cleaning up after you, but the accumulating cruft will mean that it takes longer and longer to make food (finding things, and clean them, as you need them), and ultimately you'll use much more time in this way, in total, than if you kept the kitchen tidy and clean, throughout. It feels a little similar with GC: Sure, you can just "drop things on the floor", but it may make you slower in the long run. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 11, 2006 9:18 AM
|
|
> Regarding the discussion about GC and developer
> ... > This may lead into an "illusion" that you don't need to > care about memory ownership issues, until you meet the > wall, one day, where you run out of memory, or the GC > trashes, and you learn that you may have to set long-lived > references to null, or the objects they refer to won't be > collected, and that if you create lots of objects, in > particular big ones, that are needed for a short time > (like the Image objects in my project), you may run into > such problems. I do not think that having GC will contribute towards bad resource management habits. The "you don't pay for what you don't use" comes with "you must know what you are doing". Because it's impossible to know how to do the first without knowing the second. > > So... You may come to, at least for some applications, > that the memory management issues could be _easier_ with > RAII and smart pointers, because you only heap-allocate > what you need to heap-allocate, and you get very specific, > deterministic lifetime of it (and you might use memory > pools, etc.), than with an unpredictable GC. As I said before, GC should be optional. If the programmer wants to use RAII and smart pointers, then so be it. If he/she wants to use GC though, why not allow it? > > For example, if you need to explicitly null references, > for them to be collected, what have you gained? No, nullifying a pointer is different from deleting an object. Because when you nullify a pointer, you only mess with one reference to the object, but if you delete an object, you mess with all references to that object. > You may run into _harder_ problems, trying to figure out what > references are kept where (there may be large structures > "kept alive" with a reference that in reality is no more > used, but can't be collected because of it). It's easier to comprehend when a reference should be nullified instead of comprehending when an object should be deleted. And the more complex the algorithm becomes, the more difficult it is to comprehend the right spot for object deletion. And if the algorithm at hand has cyclic references, then using smart pointers requires placing weak pointers at specific places in order to avoid cyclic referencing, something which is increasingly difficult as the number of involved objects increases, and sometimes is outright impossible, since a pointer must be both a weak and a smart pointer. |
|
Posts: 1 / Nickname: arabesc / Registered: January 11, 2006 9:11 PM
Re: A Brief Look at C++0x
January 12, 2006 2:50 AM
|
|
How about the addition of anonymous stack objects?
Something like this: struct Foo
{};
int main()
{
...
auto Foo(); // NOTE: the name of a variable is omited
...
}
The stack object Foo would be destroyed not immediately after creation, but at the end of the function main scope. |
|
Posts: 2 / Nickname: andydent / Registered: November 24, 2005 6:04 PM
Re: A Brief Look at C++0x
January 3, 2006 5:58 AM
|
|
I'd like to moderate the proposed aliasing syntax by using as instead of "="
template<class T> using Vec = vector<T,My_alloc<T>>; becomes template<class T> using Vec as vector<T,My_alloc<T>>; REASONS (not in any order of merit) 1) as is already used for aliasing in SQL, a familiar use to many developers 2) as is more evocative of aliasing, both in English meaning and as a visible contraction 3) = is already used frequently for assignment and initialisation. I have encountered confusion amongst c++ programmers of widely varying experience as to the implications of using = in initialisation and how different compilers choose to use copy ctors or not. This will add to the confusion. 4) Semantically, this is a very different form of identifier binding to any other form of assignment. The closest equivalent in current C++ is #define of a macro which does not use = but relies on whitespace separation. I don't think whitespace alone is appropriate here. CAVEAT Whilst this means as becomes a reserved word, hopefully it can be implemented as such only in conjunction with a using statement. At worst, it is a two-letter word and so less likely to clash with existing code. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 3, 2006 6:39 AM
|
|
We (the evolution working group of the ISO standards committee) looked at several syntactic variants for expressing template aliases before settling on the version I presented in this article. I think we found is pretty good and it did help us think more clearly about the problems than we had managed to before using more convoluted suggestions (on the WG21 site, you can find a series of papers discussing the problem under the heading "template typedefs"; the latest is posted on my home pages: http://public.research.att.com/~bs/WG21.html).
The closest equivalent to template aliases is typedef rather than #define: We are talking about a mechanism that preserves syntax, type, and scope rules. "as" would be a keyword and (like any short and nice word) will appear as an identifier in *many* existing programs. |
|
Posts: 4 / Nickname: alexlibman / Registered: November 30, 2005 2:04 PM
Re: A Brief Look at C++0x
January 6, 2006 11:25 PM
|
|
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 :
Being lazy to write "template<class X, class C>" before each method body, I'd like to write
|
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 7, 2006 6:09 AM
|
|
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. |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: A Brief Look at C++0x
January 7, 2006 7:16 AM
|
|
> 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. |
|
Posts: 1 / Nickname: dguerrero / Registered: January 3, 2006 2:06 AM
Re: A Brief Look at C++0x
January 3, 2006 7:19 AM
|
|
Another syntax that is (IMHO) a little "easier" on the eyes would be:
template<class T> template Vec = vector<T, My_alloc<T>>; It replaces "using" (which is too generic) with "template". It is better in that is emphasizes that the result (Vec) is also a template. |
|
Posts: 2 / Nickname: mnicolella / Registered: January 3, 2006 1:58 AM
Re: A Brief Look at C++0x
January 3, 2006 7:28 AM
|
|
It seems that the 'template typedef' with 'using' re-orders the new name to be first, instead of the traditional typedef syntax which puts the new name last... I'm not fond of the use of = here, either.
I think I would rather see something like: template<typename T> typedef vector<T, My_alloc<T>> Vec; Although I'm no expert on compiler development and there might be other technical challenges or conflicts that make this impossible. |
|
Posts: 2 / Nickname: ethouris / Registered: January 3, 2006 6:08 AM
Re: A Brief Look at C++0x
January 3, 2006 11:19 AM
|
|
> It seems that the 'template typedef' with 'using'
> re-orders the new name to be first, instead of the > traditional typedef syntax which puts the new name last... > I'm not fond of the use of = here, either. > > I think I would rather see something like: > > template<typename T> typedef vector<T, My_alloc<T>> Vec; No, I think the "using" keyword is much better, and could be treated as a general way to import symbols and also create new symbols: using vec = vector<string>; And yes, this would also elliminate 'typedef': typedef int array10i[10]; <==> using array10i = int[10]; I would be also glad to see it used for importing global variable names, while global variables usage (inside a function) should be disallowed without prefix. That is g_global_variable = 0; // ERROR ::g_global_variable = 0; // ok But: using g_global_variable; g_global_variable = 0; // ok This is somewhat similar to importing global variables in Tcl. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 3, 2006 7:54 AM
|
|
We tried with "typedef". We found that to be a source of subtle problems. It is much easier to think clearly when the name being declared is first or last. (I am no fan of the convoluted C declarator style syntax - for example see "The Design and Evolution of C++")
-- Bjarne Stroustrup: http://www.research.att.com/~bs |
|
Posts: 18 / Nickname: mlybbert / Registered: April 27, 2005 11:51 AM
Garbage Collection
January 3, 2006 10:34 AM
|
|
I'm always slightly amused that people *still* believe GC is not available in C++. I've read your "Proposal to Acknowledge that Garbage Collection for C++ is Possible" from '96 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0932.asc ), and I know that the committee has tried to sanction the idea of garbage collection over the years.
Why is the new proposal needed? Or is it a requirement that a standards-conforming compiler have a garbage collecting implementation available on demand? |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: Garbage Collection
January 3, 2006 11:13 AM
|
|
> I'm always slightly amused that people *still* believe GC
> is not available in C++. I've read your "Proposal to > Acknowledge that Garbage Collection for C++ is Possible" > from '96 > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0 > 932.asc ), and I know that the committee has tried to > sanction the idea of garbage collection over the years. and there are good garbage collectors "out there". C++ is my favorite garbage collected language because it produces so little garbage. > Why is the new proposal needed? Or is it a requirement > that a standards-conforming compiler have a garbage > collecting implementation available on demand? To clarify "optional" To exactly define what it means for an object to be alive To give the programmer a way of knowing whether GC is happening To define what "delete p;" means whan a garbage collector is running ... That said, please note that GC isn't a panacea and isn't for every program. --- Bjarne Stroustrup; http://www.research.att.com/~bs |
|
Posts: 4 / Nickname: qrczak / Registered: October 22, 2004 11:19 PM
Re: Garbage Collection
January 3, 2006 5:13 PM
|
|
Garbage collection is necessary if C++ wants to support closures which outlive the scope of their creation (upward closures), where free variables are determined implicitly from the set of names used in their bodies, instead of being explicitly named and copied (as in function objects created by binders or manually).
Optional GC is not enough. Upward closures are just incompatible with the C++ semantics of storing observably copied objects inside local variables. The function has no way to refer to the object through a local variable if the variable is already destroyed when the function is applied. Implicit observable copying of free variables would be insane, incompatible with the treatment of global variables. I don't believe that C++ will support real GC, and thus it will not support upward closures either. |
|
Posts: 2 / Nickname: ethouris / Registered: January 3, 2006 6:08 AM
Re: Garbage Collection
January 3, 2006 11:54 AM
|
|
> and there are good garbage collectors "out there".
Hmm... maybe, but I think GC is such a kind of feature that it better have language support. Like exceptions. > > Why is the new proposal needed? Or is it a requirement > > that a standards-conforming compiler have a garbage > > collecting implementation available on demand? > > To clarify "optional" First of all, it needs to be decided whether the type definitions should be strictly bound to their memory management issues, or they can be separate, while the storage is used directly by using appropriate, say, syntax. So far the garbage collectors use the second method because they simply don't have another choice. And I disagree that you can just "use garbage-collection for any type". The ability of an object to be garbage-collected or not should be a treat of its type. This is moreover important that the manual memory-managed objects are simultaneously guaranteed to be freed in strictly specified places. Removing an object by GC does not occur in specified moment. This, for example, implies that the GC'd objects must be trivially-destructible because many "typical" destructors try to do something in other objects. If it is strictly stated that garbage-collected and non-garbage-collected are separate types, then the garbage collector can be optional and will not make additional costs for those, who are not interrested with it. Others, on the other hand, point that the environment should be either fully garbage-collected or not. With such statements, the GC is simpler to be implemented. However I can't imagine, how SUCH C++ would compose with its existing libraries. > To exactly define what it means for an object to be alive When accessible from other alive objects ;). Of course, this is a complicated thing, but I think GCs today are mature enough and some reasonable method can be developed for C++. > To give the programmer a way of knowing whether GC is > happening Is there a way to inform a user that exception throwing is happening in any other way than by caching the exception? > To define what "delete p;" means whan a garbage collector > is running Nothing. Unless 'p' points for an object, which is of a garbage-collected type. This would be prevented at compile time, if GC had a language support. > That said, please note that GC isn't a panacea and isn't > for every program. I saw only few situations, when GC would be suitable. A lot of examples from Java's uses for GC (for example, to return a large object by reference) can be done in C++ without GC (this one, for example, with auto_ptr). |
|
Posts: 18 / Nickname: mlybbert / Registered: April 27, 2005 11:51 AM
Re: Garbage Collection
January 3, 2006 0:17 PM
|
|
/* [Stroustrup] To exactly define what it means for an object to be alive
[Malecki] When accessible from other alive objects ;). Of course, this is a complicated thing, but I think GCs today are mature enough and some reasonable method can be developed for C++. */ The current "best practice" (aside from linking to a GC) is to use smart pointers to determine whether a reference from another object should be considered strong, and which should be considered weak. In truth, this isn't usually necessary, as using STL containers can handle many of the memory management pitfalls. And using stack objects can lead to determinism (which is sadly lacking in Java). But that's what Stroustrup has been preaching for over a decade. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: Garbage Collection
January 11, 2006 7:04 AM
|
|
> > and there are good garbage collectors "out there".
> > Hmm... maybe, but I think GC is such a kind of feature > that it better have language support. Like exceptions. Maybe, but conservative GC is far better than its reputation (in some places). For example, see Hans Boehm's website (linke here: http://public.research.att.com/~bs/bs_faq.html). He has real data, and lots of it. One example: modern copying GC requires availability of about twice the memory that you ever use (so that you can copy). And that doesn't count data (such as indirections and per-object data) used to manage the free store objects. A conservative memory manager has much more memory to play with. -- Bjarne Stroustrup; http://public.research.att.com/~bs |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: Garbage Collection
January 11, 2006 7:41 AM
|
|
> One example: modern copying GC requires availability of
> about twice the memory that you ever use (so that you can > copy). And that doesn't count data (such as indirections > and per-object data) used to manage the free store > objects. A conservative memory manager has much more > memory to play with. > > -- Bjarne Stroustrup; http://public.research.att.com/~bs The last GC I sent you did not require availability of twice the memory you ever use, and it was a copying one. It also did not use indirections, as each pointer points to the real objects and not to another pointer, and the per-object data needed where minimal (16 bytes, if I recall correctly). |
|
Posts: 18 / Nickname: mlybbert / Registered: April 27, 2005 11:51 AM
Could you repost the link?
January 11, 2006 10:06 AM
|
|
/* The last GC I sent you did not require availability of twice the memory you ever use, and it was a copying one. It also did not use indirections, as each pointer points to the real objects and not to another pointer, and the per-object data needed where minimal (16 bytes, if I recall correctly).
*/ This truly sounds cool, but I can't find the post where you linked to this GC. Could you repost the link? |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: Could you repost the link?
January 12, 2006 2:16 AM
|
|
> /* The last GC I sent you did not require availability of
> twice the memory you ever use, and it was a copying one. > It also did not use indirections, as each pointer points > s to the real objects and not to another pointer, and the > per-object data needed where minimal (16 bytes, if I > recall correctly). > */ > > This truly sounds cool, but I can't find the post where > you linked to this GC. Could you repost the link? I sent it to Stroustrup without ever publishing it anywhere. But I can sent it to you as well if you like (if I have not deleted it, that is!). |
|
Posts: 18 / Nickname: mlybbert / Registered: April 27, 2005 11:51 AM
Re: Could you repost the link?
January 12, 2006 10:23 AM
|
|
/* [me] This truly sounds cool, but I can't find the post where you linked to this GC. Could you repost the link?
[response] I sent it to Stroustrup without ever publishing it anywhere. But I can sent it to you as well if you like (if I have not deleted it, that is!). */ I'd be interested. You can reach me at mlybbert(at)users(dot)sourceforge(dot)net. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: Could you repost the link?
January 13, 2006 4:56 AM
|
|
> /* [me] This truly sounds cool, but I can't find the post
> where you linked to this GC. Could you repost the link? > > [response] I sent it to Stroustrup without ever publishing > it anywhere. But I can sent it to you as well if you like > (if I have not deleted it, that is!). > */ > > I'd be interested. You can reach me at > mlybbert(at)users(dot)sourceforge(dot)net. Unfortunately I have erased it. If mr Stroustrup has it, then he can sent it back to me/you (I erased it because I was out of space and I did not consider it something worth keeping, as it was a platform/architecture-specific solution). Anyway, it went like this: 1) it was for win32 on 80x86 only, as it used very platform-specific APIs. 2) it used the imagehlp library to find out where the app globals are.3) garbage-collected threads were constructed by a custom call, in order to get the thread's id, handle and stack top. 4) the functions GetThreadContext and SetThreadContext (Microsoft debug library) were used to manipulate thread contexts.The collection algorithm went like this: 1) suspend all registered threads. 2) scan all globals, registered threads' stacks and CPU contexts for garbage-collected object pointers. 3) if a pointer was found, then mark the object as reachable, calculate its new address, scan the object for further pointers. 4) rescan all globals, registered threads' stacks and CPU contexts; adjust pointers to point to the new addresses of objects. 5) traverse the list of objects, moving reachable objects to their new positions, and finalizaing unreachable ones. 6) resume all registered threads. In order to find valid pointers, I used a magic number before the memory block. |
|
Posts: 18 / Nickname: mlybbert / Registered: April 27, 2005 11:51 AM
Re: Could you repost the link?
January 13, 2006 2:15 PM
|
|
/* [me] This truly sounds cool, but I can't find the post where you linked to this GC. Could you repost the link?
[response] I sent it to Stroustrup without ever publishing it anywhere. ... [me] I'd be interested. ... */ Thanks for the description. Unfortunately it is very platform-specific, but the Hans-Boehm collector notes that GC is generally going to be platform specific. Even so, it's interesting. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: Could you repost the link?
January 16, 2006 3:43 AM
|
|
"but the Hans-Boehm collector notes that GC is generally going to be platform specific"
If C++ supported aspect-oriented programming and compile-time reflection, then it would be trivial to write a precise garbage collector that was platform-indepentent. With compile-time reflection, it would be possible to construct precise garbage collection information for each object, including stack frames. With aspects, it would be possible to inject the code that calls the collector and registers those garbage-collection metadata about each object at run-time. Of course both compile-time reflection and aspects are different views of the same problem: manipulation of code at compile time. C++ needs a decent clean macro system that can be used to manipulate code at compile-time. |
|
Posts: 1 / Nickname: redmjoel / Registered: December 19, 2005 7:09 AM
Re: A Brief Look at C++0x
January 16, 2006 9:08 AM
|
|
Here's my top 3 wish list item:
1. Lambdas -- at least at the level of Boost::Lambda what: A way to pass functions into the STL why: Without a lambda-ish way of passing a function object into the STL algorithms and containers, there will not be a widespread use of the STL algorithms. Currently, it is a big headache to use the (for instance) std::find algorithms. Much more so than writing your own loops. 2. Garbage collection what: Automatic resource tracking (as in C++/CLI) why: Takes the burden of tracking memory away from the programmer if not needed. This is something that C++/CLI has gotten right, and it would be shame to not be able to use it in a wider context. The C++/CLI version doesn't pass an undue burden onto the run-time, as it would only be necessary to run the garbage collecter in code which actually uses the garbage collection keywords. This is something which is easily visible at link-time. It is possible that this could be an "optional" part of the standard, so that places where it is inappropriate would not have to implement it. This would be the case for DSPs for instance. 3. Initialization of collections what: Support for "vector<int> list = {1, 2, 3, 4, 5};" syntax why: This is a big headache for both novice users and experienced programmers. The current standard also violates the design goal of making user types equivalent to built-in types. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 23, 2006 5:28 AM
|
|
Here are some other interesting ideas. I am posting them not as 'things I want', but as interesting ideas for discussion:
1) friend access attribute customized on classes/functions that can have access. Example:
2) truly private implementations. The header files will contain 'interface' classes which might or might not have all the members, and the implementation file will declare the actual internal implementation of the class as well as private fields/methods not visible in the header file. Example:
The compiler should keep a hidden table of object sizes to use with operator new or member declaration, as well as for checking if implementation of object already exists.3) custom pointer syntax. Example:
4) more functionality in operator new, using a special class new<T>. For those classes that have a specialization of new, it is the New<T> that is called instead of operator new. This will allow various actions on an object not possible now. Example:
The above will allow things like this: a) performing actions that depend on allocated type; for example registering a finalizer in a garbage collector. b) performing actions that depend on after constructors have been called; for example, registering an object somewhere, while calling a virtual method of the object (not possible before instantiation). 5) accessing struct/class members with array syntax; operator lengthof that returns number of elements of array/tuple. This is necessary for compile-time introspection. Example:
6) aspects/introspection by classes for classes. Example:
Very useful for debugging purposes and other operations. With this capability, point #4 above is reduntant, as operator new can be a member of the aspect classes.7) instance creation by namespace string. Example:
Useful for loading modules at run-time. The compiler should place an internal array of class information in each executable/library. 8) classes that can be defined/extended on the point of declaration. For example:
Useful for for callbacks, etc. 9) local functions. Example:
It's quite easy to achieve. The inner function's stack should come right after the outter function's stack; think about is as struct inheritance. Stack frames should be dealt with as locally defined structs, and local variables should be accessed as member objects of the function. For example:
Local functions allow for interesting algorithms. 10) formalize CPU context. The standard library should provide a CPU context class as well as methods to get/set CPU context. Since C++ is a high-level language for a low-level environment, C++ should provide such functionality. This functionality will allow for user threads, user multithreaded garbage collection, co-routines, tail call optimization etc. The API should be fairly abstract: the CPU context should be handled as an array of bytes, but also as a struct with named registers. The API should offer the following functionalities: a) setting and getting the CPU context. b) getting the stack information (top and bottom address). c) using the stack: push, pop. d) setting up the next address to execute. 11) arbitrary length integer, real arithmetic; fractions; ranges. I think the standard library should have those. 12) sets. Like enumerations, but member values can be objects. Example:
Sets could be used like arrays or enumerations. Example:
The reason sets are useful is the same as enumerations: they limit the chances of using the wrong value (as well as provide names for standard values). |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 23, 2006 5:40 AM
|
|
Some new stuff that I just came up with:
1) constructor forwarding. Just as destructors are forwarded, so should constructors. If a derived class has no constructor, then it gets the constructors of the base class. This will make it easier to use the 'inherit from template parameter' pattern. Example:
2) template classes as friends, not only template specializations. Often the need arises for a template class to be friend of a non-template class, but it is not possible with the language as it is now without an intermediate class. Example:
|
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 23, 2006 5:46 AM
|
|
(sorry guys for replying to myself; is there an 'edit' button? have I missed it?)
Yet another one: 1) if a class does not have a parameterized constructor, and the programmer uses a constructing call with operator =, then the compiler should call the default constructor, then the operator =. Example:
|
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 23, 2006 6:37 AM
|
|
Nested comments. Some time it is needed to just comment out a piece of code that includes block comments. Example:
|
|
Posts: 5 / Nickname: limit / Registered: January 11, 2006 2:08 AM
Re: A Brief Look at C++0x
January 24, 2006 0:14 AM
|
|
> 12) sets. Like enumerations, but member values can be
> objects. Example: > >
I think that better to extend enum keyword functionality and trait it as predefined template with one template parameter that denote base type for enumeration constants. In this case your examples can be rewritten:
It is also solve a problem with exact base type for ordinary enumerations. C++ rules in this aspect is not so easy to remember.
Of course enum C {} is also possible. In this case old rules for base type would apply.
|
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 24, 2006 3:02 AM
|
|
Thanks for the reply. Good idea about the enum syntax. Any other comments? anyone?
|
|
Posts: 4 / Nickname: trelony / Registered: January 3, 2006 8:19 AM
Re: A Brief Look at C++0x
January 3, 2006 1:26 PM
|
|
What about more advanced features, like "import"? Putting templates into headers is not would I want to do. On Slashdot site people are asking for other features that are interesting for me too: Vtable manipulation, static virtual, properties, reflection. I would also like to see G++ signatures back - not everything has to be a template. Closures are also nice, but they will require GC, because otherwise it will be difficult to track all internal objects and clean them up.
And now - standard socket and threading libraries. |
|
Posts: 18 / Nickname: mlybbert / Registered: April 27, 2005 11:51 AM
Re: A Brief Look at C++0x
January 3, 2006 1:51 PM
|
|
/* What about more advanced features, like "import"? Putting templates into headers is not would I want to do.
*/ I believe that precompiled headers offers what the "import" crowd is asking for. Precompiled headers *are* available in C++, but like GC they aren't mandated, just allowed. /* On Slashdot site people are asking for other features that are interesting for me too: Vtable manipulation, */ This is interesting. Objective C allows it (if "it" is what I think it is), as does calling Lua, Perl, or Python from C++. Or even using something like Amulet did (http://www.cs.cmu.edu/~amulet/ ). /* ... (skip several that I'm not familiar with) Closures are also nice, but they will require GC, because otherwise it will be difficult to track all internal objects and clean them up. */ How about function-like objects? (http://public.research.att.com/~bs/bs_faq2.html#function-object ). /* And now - standard socket and threading libraries. */ They are nice. I understood Stroustrup's post to mean that there will be standard threading libraries, but as sockets require OS support, I wouldn't expect the language committee to cover them. |
|
Posts: 4 / Nickname: trelony / Registered: January 3, 2006 8:19 AM
Re: A Brief Look at C++0x
January 3, 2006 2:10 PM
|
|
Function objects work, but they need automatically include references to all external data, including data on a stack (that will not exist after the function object is returned). Java does it automatically with local classes. Maybe instead of "closures" we should ask for local classes.
|
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: A Brief Look at C++0x
January 4, 2006 5:45 AM
|
|
> What about more advanced features, like "import"? Putting
> templates into headers is not would I want to do. There is already template "export" (though it's only implemented on one compiler (front end), EDG), but it doesn't work very well. :) That is, due to the way C++ templates work, it doesn't break the dependency between the declaration and definition (unlike non-template functions). However, the "concepts" may do something about this, as it means that with it, template instantiation site and template definition site can be independently type-checked, giving us a similar type checking for templates, as for non-templates, and this is something you can't do with current templates. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 3, 2006 2:28 PM
|
|
I think that (some of) you are reading far too much into one short and "popular" article. If you want to understand what C++0x might be in any detail, you have much more information available to you. For starters see: http://public.research.att.com/~bs/papers.html
and the "wish lists" on http://public.research.att.com/~bs/C++.html . For gluttons for punishement there is the standards committee website: try google("WG21"). Please remember that until the final votes nothing is final; C++0x is work in progress. We (the members of the committee) would like feedback and suggestion, preferably feedback and suggestions based on more than a couple of seconds thought. We are working for a huge community: http://public.research.att.com/~bs/applications.html . -- Bjarne Stroustrup; http://www.research.att.com/~bs |
|
Posts: 4 / Nickname: trelony / Registered: January 3, 2006 8:19 AM
Re: A Brief Look at C++0x
January 3, 2006 2:47 PM
|
|
I forgot one more thing - is it possible to get overloading by result type?
|
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 3, 2006 2:51 PM
|
|
> I forgot one more thing - is it possible to get
> overloading by result type? Don't hold your breath. The additional complexity of the overload resolution would be significant. It would take a lot of demonstrated need for C++0x to go that way. -- Bjarne Stroustrup; http://www.research.att.com/~bs |
|
Posts: 4 / Nickname: trelony / Registered: January 3, 2006 8:19 AM
Re: A Brief Look at C++0x
January 3, 2006 8:14 PM
|
|
> > I forgot one more thing - is it possible to get
> > overloading by result type? > > Don't hold your breath. The additional complexity of the > overload resolution would be significant. It would take a > lot of demonstrated need for C++0x to go that way. > > -- Bjarne Stroustrup; http://www.research.att.com/~bs I do not see why it is difficult. It is already possible by returning a wrapper that lazily executes different actions in cast operators. So overloading by result type would just make it official. - Alexey. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: A Brief Look at C++0x
January 3, 2006 4:39 PM
|
|
How about lambda expressions?
Also, I would add that C++ is moving too slowly. Even C#, which was a joke in version 1.0 and mediocre at version 2.0 offers very interesting features in version 3.0, and it will be out probably just a couple of years from now. C++ 0x enabled compilers will not appear before 2010, and I am afraid we will be hopelessly behind other languages by that time. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 3, 2006 5:02 PM
|
|
> How about lambda expressions?
Maybe. There is much talk, but no concrete proposals. I think that simple lambdas could be a good thing. However, syntactically heavy lambdas or an attempt to completely support functional programming could be complete disasters. > Also, I would add that C++ is moving too slowly. Even C#, > which was a joke in version 1.0 and mediocre at version > 2.0 offers very interesting features in version 3.0, and > it will be out probably just a couple of years from now. > C++ 0x enabled compilers will not appear before 2010, and > I am afraid we will be hopelessly behind other languages > by that time. In terms of "sexy new features" maybe, but other languages have their own problems where it matters: to deliver correct, well-performing, and maintainable software. C++ isn't perfect, but neither is any of its competitors. Note also that C is still very much alive despite its complete absence of modern features. Web discussions may be beauty contests, but real-world software development rarely are just that. 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. -- Bjarne Stroustrup; http://www.research.att.com/~bs |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: A Brief Look at C++0x
January 3, 2006 6:19 PM
|
|
> In terms of "sexy new features" maybe, but other languages
> have their own problems where it matters: to deliver > correct, well-performing, and maintainable software. Don't get me wrong - I wouldn't dream of picking anything but C++ for a mid-size or big project. It just scales so beautifully - you can use advanced abstraction mechanisms and inline assembly in the same file, and I am not aware of any other popular language that offers this ( hopefully Walter Bright will not jump in with his D evangelism here ;) ). However, "sexy features" are needed at least to attract CS students and enthusiasts in general. You created C++ to make programing more *enjoyable* experience, and that was a great goal. Why not continue that path? |
|
Posts: 13 / Nickname: tag / Registered: November 16, 2004 7:25 PM
Re: A Brief Look at C++0x
January 6, 2006 5:38 AM
|
|
> 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. 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. 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. 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. 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. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 7, 2006 9:39 AM
|
|
> > 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 |
|
Posts: 13 / Nickname: tag / Registered: November 16, 2004 7:25 PM
Re: A Brief Look at C++0x
January 7, 2006 0:18 PM
|
|
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] |
|
Posts: 8 / Nickname: igaztanaga / Registered: January 3, 2006 9:57 PM
Re: A Brief Look at C++0x
January 7, 2006 0:28 PM
|
|
> > > 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. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 7, 2006 1:43 PM
|
|
> 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. |
|
Posts: 8 / Nickname: igaztanaga / Registered: January 3, 2006 9:57 PM
Re: A Brief Look at C++0x
January 7, 2006 3:20 PM
|
|
> 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. |
|
Posts: 18 / Nickname: mlybbert / Registered: April 27, 2005 11:51 AM
Re: A Brief Look at C++0x
January 9, 2006 10:41 AM
|
|
/* Typically, the problem is not that there is no solution. Most often the problem is that there are many.
*/ This reminds me of Larry Wall's "State of the Onion" statement: /* So I'm just wondering if we're getting ourselves into a similar situation with open source software. More software is not always better software. Google notwithstanding, I think it's actually getting harder and harder over time to find that nugget you're looking for. This process of re-inventing the wheel makes better wheels, but we're running the risk of getting buried under a lot of half-built wheels. And there are two take-home lessons from that. The first is that, as an open source author, you should be quick to try to make someone else's half-built wheel better, and slow to try to make your own (http://www.perl.com/pub/a/2005/09/22/onion.html?page=10). */ |
|
Posts: 1 / Nickname: agurtovoy / Registered: January 19, 2006 11:47 AM
Re: A Brief Look at C++0x
January 19, 2006 5:29 PM
|
|
> 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. That's quite an accusation. Do you have any data to support it? > For example, why weren't boost threads, boost > sockets, boost XML, boost unicode, and boost files among > tthe very first boost components? Because, beleive it or not, building any sizeable domain-specific library that a skilled C++ engineer would be satisfied with actually requires lots and lots of these low-level "neat" libraries [1] that the C++ standard is missing. [1] Often in the form of both the actual code and the conceptual foundation. > Such foundation for > applications are hard and non-glamorous - it takes a major > effort to get people to create and maintain such > components. Right, and, say, Boost.Type Traits, Boost.Graph and Boost.Regex (one of the very first Boost libraries) were a piece of cake, totally glamorous, and took no effort to create and mantain. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: A Brief Look at C++0x
January 8, 2006 6:36 AM
|
|
> > 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. IIRC, Boost.Threads was among the first ones - I am not sure why W. Kempf gave up on it. But generally I agree, people work on whatever they find interesting. For XML, there are Apache libraries (xerces and xalan), and for Unicode ICU - they are de facto standard in C++ world. Maybe it would be a sensible approach to just start from them and add a API layer on top of them that would be more in the spirit of C++ Standard Library? |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 8, 2006 8:07 AM
|
|
>
> IIRC, Boost.Threads was among the first ones - I am not > sure why W. Kempf gave up on it. But generally I agree, > people work on whatever they find interesting. I know (of course) and now there is a boost::treads, but the fact is that there is less activity that I would like to see and less than one might expect given the size of the C++ community (the underlying problem is that the C++ community is fractured). Boost wasn't meant to be just STL-like libraries, but it has come to be perceived that way by some. One technical problem (that the boosters are trying to find a solution to) is that boost is a monolith. This has been a problem with outher libraries also, such as ACE. For example, say I want to be able to download and use just the regular expressions and don't want any other library to complicate my system, how can I get just boost::regex and what it depends on and nothing else. > For XML, there are Apache libraries (xerces and xalan), > and for Unicode ICU - they are de facto standard in C++ > world. Maybe it would be a sensible approach to just start > from them and add a API layer on top of them that would be > more in the spirit of C++ Standard Library? Yes, that would be one plausible approach. All we need is a small group of people to do it; people who have the patience to follow through and who won't be dismayed when -inevitably - their first cut won't be good enough. -- Bjarne Stroustrup; http://www.research.att.com/~bs |
|
Posts: 20 / Nickname: bigboy / Registered: June 14, 2004 10:43 AM
Re: A Brief Look at C++0x
January 8, 2006 1:32 PM
|
|
> > For XML, there are Apache libraries (xerces and xalan),
> > and for Unicode ICU - they are de facto standard in C++ > > world. Maybe it would be a sensible approach to just > start > > from them and add a API layer on top of them that would > be > > more in the spirit of C++ Standard Library? > > Yes, that would be one plausible approach. That's exactly what I've done with XMLSTL so far. It is a unifying wrapper over both MXSML DOM (virtually complete) and Xerces DOM (a significant coverage so far). One remaining issue with the Xerces DOM version is I've yet to decide - and will be happy to take input - is how to do the various initialising actions that Xerces DOM. I'm considering Schwarz counters, but am still pondering the matter. > All we need is > a small group of people to do it As soon as I've got the first draft of Extended STL volume 1 (http://extendedstl.com/) done - this week! - and placated my commercial client (who very kindly gave me 6 weeks to work on my book, and who has some needs to satisfy next week), I plan to release the first alpha. Given the amount of discussion and hearty sentiment on the need to pull together in this forum, I expect a lot of input/help. Of course, if it falls on deaf ears, then this would be a very sad indictment of all-talk-and-no-trousers. But I am really hopeful that it won't. > people who have the > patience to follow through As I said, it's largely complete for MSXML DOM. There are several remaining issues that need to be addressed before it could be ready for a proper release - such as it is currently using a couple of components from the Synesis libs (current requiring the use of a DLL), until I modify things and make it all header-only open-source like the rest of STLSoft. But I plan to release it virtually as it stands now, so that people can play and criticise the interfaces first, while I put in the couple of days' work to get rid of such dependencies. I've got several example programs that conditionally compile both variants - which live in xmlstl::msxml::dom and xmlstl::xerces::dom - which should serve as good illustrations of the library, and how closely (but not yet completely) I've managed to unify the syntax. (FWIW: The layers provide, if your compiler supports it and you don't define XMLSTL_NO_METHOD_PROPERTY_SUPPORT, properties for the various components - node, document, attribute, etc. - so you can write code such as if not, you can use the function forms: The MSXML variant works with both ANSI and Unicode compilation. And, for those who are concerned about modern-only libs, this works with compilers as dull-witted as VC6 (albeit without the properties). <g>) > and who won't be dismayed when > -inevitably - their first cut won't be good enough. That won't happen. I'm like a T-1000 to criticism. ;-) But I can't make the community interested in my work, any more than anyone else. But, Bjarne, you can, so I would ask that you at least follow along on the progress every now and then, and, should it meet your standards, you might comment on it? It that fair enough? Matthew |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: A Brief Look at C++0x
January 8, 2006 4:44 PM
|
|
> > > For XML, there are Apache libraries (xerces and
> xalan), > > > and for Unicode ICU - they are de facto standard in > C++ > > > world. Maybe it would be a sensible approach to just > > start > > > from them and add a API layer on top of them that > would > > be > > > more in the spirit of C++ Standard Library? > > > > Yes, that would be one plausible approach. > > That's exactly what I've done with XMLSTL so far. > It is a unifying wrapper over both MXSML DOM (virtually > complete) and Xerces DOM (a significant coverage so far). Is it something like Arabica? http://www.jezuk.co.uk/cgi-bin/view/arabica/roadmap |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: A Brief Look at C++0x
January 8, 2006 3:39 PM
|
|
> But I can't make the community interested in my work, any
> more than anyone else. But, Bjarne, you can, so I would > ask that you at least follow along on the progress every > now and then, and, should it meet your standards, you > might comment on it? It that fair enough? A rather obvious suggestion, but still...: I suggest you post about it at Boost, once you have something that people can look at and play with, and invite comments. I know the boosters have expressed interest in getting an XML library, if you'd be interested in submitting it there. As many committee members are on the mailing list, you're sure to get their attention, this way. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 8, 2006 4:46 PM
|
|
> > But I can't make the community interested in my work,
> any > > more than anyone else. But, Bjarne, you can, so I would > > ask that you at least follow along on the progress > every > > now and then, and, should it meet your standards, you > > might comment on it? It that fair enough? > > A rather obvious suggestion, but still...: I suggest you > post about it at Boost, once you have something that > people can look at and play with, and invite comments. I > know the boosters have expressed interest in getting an > XML library, if you'd be interested in submitting it > there. As many committee members are on the mailing list, > you're sure to get their attention, this way. Boost is the best forum that I can think of. I'm not the only person interested in XML tools (e.g. see the libraries wishlist). I do try to keep up with the various proposals and developments that might become proposals, but there are many and I don't have more hours in a day than anyone else. So, it's a very good idea to be in a forum where several people from the committee participates rather than just relying on me. -- Bjarne Stroustrup; http://www.research.att.com/~bs |
|
Posts: 20 / Nickname: bigboy / Registered: June 14, 2004 10:43 AM
Re: A Brief Look at C++0x
January 8, 2006 4:55 PM
|
|
> > But I can't make the community interested in my work,
> any > > more than anyone else. But, Bjarne, you can, so I would > > ask that you at least follow along on the progress > every > > now and then, and, should it meet your standards, you > > might comment on it? It that fair enough? > > A rather obvious suggestion, but still...: Well, in one way it's a cheap sneak, but in another it's not. Bjarne's here. He's (rightly) bemoaning the (possibly unjustified) perception that the C++ standards process is a dim and impenetrable domain. People are responding. Is it too much to ask that such responses receive a modicum of active attention? For my part, I've several things I'd like to propose for the standard - some very small and simple (one of which is all but ready to be submitted); some large and not-so-simple - but despite being a member of the Ed Panel of The C++ Source, and having mentioned such to, and requested pointers from, my fellow panel members (several of whom are on the C++ standards committees), I am still largely in the dark as to how to go about putting forward proposals. I know that I need to make some mention on std.lang.c++ and to follow the instructions at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html, but beyond that it's still pretty opaque to this little pixie. Will my submission be immediately disseminated to panel members? Will it be dropped in the bit-bucket because I cannot attend a standardization committee meeting myself? (A previous post on this thread intimated that the members are pretty much full up on extant proposals, and are therefore unlikely to be able to sponsor any new ones ...) Do I need to join the committee (assuming they'd have me .. LOL)? Do I have to stump up $800? (Having taken off all the time I have in the last couple of years for the perverse pursuit of writing books, I suspect that were I to suggest lashing out such an amount merely to give me the right to volunteer my services freely to my business manager (and better half), she might well render me incapable of furnishing her with any more sons.) So, if, at this point in time I/we have the attention of the author of the language, it can't be too surprising that I/we are grabbing on to his wrist like hungry little children to prevent his departure. (Ok, outrageously honey-soaked analogy, I grant you, but there's truth running through it.) (FYI: Chuck (Allison: editor of The C++ Source) has agreed to my "diarising" my experiences, such as they may be (warts and all), in making these proposals in The C++ Source, so at least others in this position may be a little better informed should they seek to make proposals in the future.) > I suggest you > post about it at Boost, once you have something that > people can look at and play with, and invite comments. I > know the boosters have expressed interest in getting an > XML library, if you'd be interested in submitting it > there. As many committee members are on the mailing list, > you're sure to get their attention, this way. I'm not interested in submitting it as a Boost library, but I'll bear in mind the possibility that useful criticism might be elicited from the Boost community. Cheers Matthew |
|
Posts: 20 / Nickname: bigboy / Registered: June 14, 2004 10:43 AM
Re: A Brief Look at C++0x
January 8, 2006 5:06 PM
|
|
> but I'll bear in mind the possibility that useful
> criticism might be elicited from the Boost community. Post-"Post Message" click that reads as sarcastic, which was not intended. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 8, 2006 10:00 PM
|
|
Matthew:
> ... despite being a member of the Ed Panel > of The C++ Source, and having mentioned such to, and > requested pointers from, my fellow panel members (several > of whom are on the C++ standards committees), I am still > largely in the dark as to how to go about putting forward > proposals. I know that I need to make some mention on > std.lang.c++ and to follow the instructions at > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n18 > 10.html, but beyond that it's still pretty opaque to this > little pixie. Will my submission be immediately > disseminated to panel members? I believe that any committee member would do that if you sent them an email asking them to. Unless the proposal looked solid (see the document you quote), they might suggest that you do some more work and talk with other people before forwarding it to the committee. The most typical problem I see with proposals sent to me is that they fail to consider alternatives. Often, you have to consider several quite different ways of achieving similar results. An example would be garbage collection: Someone might propose a conservative scheme, a precise scheme, a smart-pointer based approach, or an approach based on language restrictions. No proposal will get very far unless there is a discussion of the general alternatives in addition to a mass of details about the preferred scheme. Just deeming significantly different schemes "braindead" won't do much good. They may be so, but the committee will want to know exactly how they are :-) remember, there will be people on the committee with a dramatically different background from you and a dramatically different mix of application areas as their main concern. > Will it be dropped in the > bit-bucket because I cannot attend a standardization > committee meeting myself? (A previous post on this thread > intimated that the members are pretty much full up on > extant proposals, and are therefore unlikely to be able to > sponsor any new ones ...) That's a real problem. You know what happens to successful C++ programmers? They get overloaded. > Do I need to join the committee > (assuming they'd have me .. LOL)? Do I have to stump up > $800? You don't *need* to join the committee, but if you don't you somehow have to convince someone else to spend significant time working with you on a proposal and to spend the time presenting and discussing it at the face-to-face meetings. And yes, if you want to join the committee, you have to pay unless you can demonstrate some quite unusual reason not to. The ISO is not very forgiving about money and some of the national bodies are worse. More or less informally joining up with some people who are local (in some sense) to you may be a good first step. Various nations have discussion groups (e.g. France, Germany, and the UK). -- Bjarne Stroustrup; http://www.research.att.com/~bs |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: A Brief Look at C++0x
January 9, 2006 5:07 AM
|
|
> And yes, if you want to join the committee, you have to
> pay unless you can demonstrate some quite unusual reason > not to. The ISO is not very forgiving about money and some > of the national bodies are worse. More or less informally > joining up with some people who are local (in some sense) > to you may be a good first step. Various nations have > discussion groups (e.g. France, Germany, and the UK). Just to comment on this: Not all national bodies require member fees. For example the UK one has free membership. I assume BSI (UK's national body) pays ISO to participate, but membership of the BSI C++ Panel (BSI's delegate to WG21) is free. (Normally, you have to be UK citizen to join, but I got an offer to join the panel, as Norway is not active in the committee, and they knew me through my participation in ACCU. The same is the case for a couple of others, like Thorsten Ottoson, who lived in Australia for a while). For those who may wonder about the organisation of ISO: As I understand, the members of ISO are countries, and ISO is made up of the so-called "national bodies" in these countries - each country has an organization associated with ISO - in UK, it's BSI, etc. Delegates of these national bodies constitute WG21 at standards meetings. However, again, as I understand, you don't need to be a member of a national body to participate at WG21 meetings, as according to ISO rules, anyone can attend (space permitting). The exception is the last day, when voting is done, where only members can vote. I couldn't stay for the voting at Lillehammer, but I think it's just the Head of Delegation who votes on behalf of their country, anyway, so individual membership may not matter that much in this case. However, being a member of a national body gives you access to the commitee's mailing lists, but as such, they may be considered (where you pay membership fees) pricey lists... :) I hope Mr. Stroustrup will correct any errors in this. |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: A Brief Look at C++0x
January 9, 2006 5:14 AM
|
|
> Do I need to join the committee
> (assuming they'd have me .. LOL)? LOL, :) for one thing, there's no entry-test to join a national body, and furthermore, from what I've seen of your writing, you're well qualified to participate, had there been one. |
|
Posts: 6 / Nickname: abrahams / Registered: October 6, 2004 10:03 AM
Re: A Brief Look at C++0x
February 21, 2006 9:21 AM
|
|
> One technical problem (that the boosters are trying to
> find a solution to) is that boost is a monolith. This has > been a problem with outher libraries also, such as ACE. > For example, say I want to be able to download and use > just the regular expressions and don't want any other > library to complicate my system, how can I get just > boost::regex and what it depends on and nothing else. First of all, let me acknowledge that Boost has (intentional) internal dependencies. That said, while I'm sure Bjarne didn't mean it that way, most of the above is misleading at best. So let me clear a few things up: 1. Boost is not a monolith in any sense, except maybe that we don't provide separate downloads of individual libraries. 2. As of a year or two ago, Boost's coupling was *nothing like* ACE's. A friend of mine was working for a company that built refactoring software that could graph dependencies. When they threw the technology at ACE, it quickly became known as "the blob": because everything was linked to everything else, you couldn't make out the individual edges in the graph. All you could see was a big black mass. When we did the same with Boost, there were a few small areas that could be improved, but for the most part the dependencies were hierarchical and non-cyclic. I don't know what has happened with ACE recently (things may have improved), but Boost has maintained the practices that resulted in that low coupling. 3. We have a tool that can separate out individual libraries and their dependencies: http://www.boost.org/tools/bcp/bcp.html. So far it has been a little overly conservative, but we are working on ways to make it less so. For example, some dependencies only arise when optional features of a given library are used. We're adding features to make sure that those dependencies are pruned when users don't explicitly request the optional features. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 3, 2006 6:49 AM
|
|
My (long and bitter) comment is here:
http://slashdot.org/comments.pl?sid=172797&cid=14384078 I apologise about it, but I just can not accept the fact that C++ could be so much better, but it is not. C++ has excited me more than any other language, but has also disappointed me just as much. |
|
Posts: 2 / Nickname: mnicolella / Registered: January 3, 2006 1:58 AM
Re: A Brief Look at C++0x
January 3, 2006 7:00 AM
|
|
By the way, there is an error in the article's code here:
Original text: ----------------------- The difference here is that we don’t have to mention the type of the iterator: auto means “deduce the type of the declared variable from the initializer”. Such uses of auto are far less verbose and also less error- prone than current alternatives, such as: for (vector< double, My_alloc<double> > p = v.begin(); p!=v.end(); ++p) cout << *p << endl; ----------------------- p should actually be declared as vector< double, My_alloc<double> >::iterator It's interesting and funny that the error is in the code that you point out is more error-prone. I don't think the error was intentional ;) |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 3, 2006 7:51 AM
|
|
It was not deliberate.
Sorry. Yes, it supports my point in a somewhat weird way. (Actually I had found and fixed that problem, but Artima got caught by a versioning problem with my text). |
|
Posts: 20 / Nickname: bigboy / Registered: June 14, 2004 10:43 AM
Re: A Brief Look at C++0x
January 4, 2006 1:49 AM
|
|
Original text
========================== no properties. For example, GUI libraries have 100s of widgets, yet we still have to write getFoo(), setFoo(), isFoo() etc. By using properties, code would be greatly simplified, and there would be no run-time overhead since properties is about syntactic sugar ========================== Sorry, but I must demur. There is a perfectly effective, 100% speed-efficient, and, syntax aside, adequate mechanism of implementing properties in C++, as described in Chapter 35 of (my book) Imperfect C++. (To tame the syntax, it uses macros, which is a bit of a shame, but other than that it is without substantive flaw. It also facilitates the user having an overhead of one byte (+packing) per class, irrespective of the number of properties.) The latest release of the recls library incorporates properties into the recls/C++ and recls/STL mappings. (Downloadable from http://recls.org/) I'm currently working on a substantial library, called XMLSTL, which is a library that wraps (currently) MSXML and Xerces DOM, with SAX and other XML libs to come. It unifies syntax between the underlying libraries, has minimal coupling, and uses my C++ Properties technique. I am hoping to get an alpha out for the people who've expressed interest thus far (and anyone else) to play with this month. (Perhaps lacking in humility / realism, I see no reason at this stage that this won't be an adequate answer to the call for submissions on XML presented in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html, and will be working towards that this year.) On a broader point, I don't see what all the fuss is about. Apart from auto, which will be a huge boon, there's precious little lacking in current C++ for anyone willing to apply a little imagination. Sorry if that's a too-last-century opinion. :-) Cheers Matthew |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 4, 2006 8:31 AM
|
|
GC requires type information. Current GCs do not have type information in their hands, so they have to scan all the available data for finding pointers. And then they have to do various tricks in order to find if something is a pointer or not. And let's not forget weak pointers and GCs, which are not possible as the language is right now.
What I have done in order to have weak pointers in my own GC is to have the high bit set if it is a weak pointer. Since using the high bit makes the pointer point into some unreachable or kernel area, this solution works, and it is quite efficient. But it is a hack. Regarding properties, whoever said that "The subtle advantage of "hiding" a private data member by treating it as a public data member escapes me" is totally wrong (in fact that article has so many holes in it, I do not know where to begin from; and it is funny that the author then goes on to implement properties at library level). It makes a huge difference in programming, especially in things like GUI frameworks. Properties is about simplicity. Whoever says "it is not C++", well, it is not the C++ you are used to, but I do not see any reason why it shouldn't be there. If you don't like it, don't use it. After all, C++ is the language of freedom: you don't pay for what you don't use. As for all the other things requested, I was the guy that wrote the long list of "things I want" and "things that are wrong" in Slashdot. Again, I apologize for being bitter, but it just seems so impossibly wrong to wait for 10 years for 'auto' to possibly be adopted (for example). |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: A Brief Look at C++0x
January 4, 2006 11:01 AM
|
|
> Regarding properties, whoever said that "The subtle
> advantage of "hiding" a private data member by treating it > as a public data member escapes me" is totally wrong (in > fact that article has so many holes in it, I do not know > where to begin from; Since it has so many holes, you say, could you name a few? > and it is funny that the author then > goes on to implement properties at library level The author (Lois Goldthwaite) explains that in the paper: "It is a foregone conclusion that TG5Â’s deliverable [C++/CLI] will include support for properties as a feature of the core language. But I want to explore how far a portable C++ library implementation can go in providing the perceived advantages of properties, without requiring any change in the compiler. If this approach proves fruitful, it could lead to a coding style usable in both dialects of C++." (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf) In other words, she argues that if you want it, you can do it as a library solution: You don't have to change the core language to get it. That makes perfect sense in this context; it's not funny at all. ). It > makes a huge difference in programming, especially in > things like GUI frameworks. Properties is about > simplicity. Whoever says "it is not C++", well, it is not > the C++ you are used to, but I do not see any reason why > it shouldn't be there. If you don't like it, don't use it. > After all, C++ is the language of freedom: you don't pay > for what you don't use. A language change has several costs, even for "perfect" features (i.e. ones that don't break backwards compatibility), such as cost of making a proper specification, compiler or library implementation, education, etc. The principle you refer to is about cost in terms of speed/memory use, _not_ about the cost of adding features. Don't muddle the two, they are very different. > As for all the other things requested, I was the guy that > wrote the long list of "things I want" and "things that > are wrong" in Slashdot. Again, I apologize for being > bitter, but it just seems so impossibly wrong to wait for > 10 years for 'auto' to possibly be adopted (for example). As I wrote in the reply to you, there, if people like yourself (who want these things) participate in the language development, we could probably have had done more, by now. The point is that someone has to _do_ these things; it's "easy" enough to propose a bunch of features, and then complain that "noone does the work of implementing them"... The committee has a very long wishlist (similar to the one you posted), but limited manpower to implement it in the language. Even so, C++ is one of the most complex and feature-rich languages around. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 5, 2006 7:10 AM
|
|
In other words, she argues that if you want it, you can do it as a library solution
But the library solution has several drawbacks: 1) it introduces a memory overhead: the extra fields needed inside property objects. 2) it introduces a compiler overhead: the compiler should compile all the code for each instantation of the property template. 3) it introduces a programmer's overhead: it is quite easy to forget 'initializing' a property member with the proper pointers, especially if a class gets changed a lot. A language change has several costs, even for "perfect" features (i.e. ones that don't break backwards compatibility), such as cost of making a proper specification, compiler or library implementation, education, etc. I agree, but some of the proposed things are quite simple to implement, especially if the relevant thing has been done in other languages. Take properties, for example: C# has a very good implementation on properties. A real good base to start from. It is just not logical to have to wait 10 years to get properties. 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 think these new features are ok but we need libraries for network, serialization, inter-process communication, xml, data-base, threads... I couldn't agree more. These libraries are long overdue. C++ is being abandoned in favor of Java, due to Java having a way much more complete SDK. I don't think garbage collector is needed at all. It is badly needed, but it should be an option. In most large projects, a great deal of effort is spent chasing pointers. 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. and that new smart pointers can avoid nearly all manual memory management No, smart pointers are not that good. First of all, they are much slower than GC; secondly, you can not use smart pointers in situations with circular references, and that rules out a lot of data structures. And memory is not the only resource you have to manage, so I don't know if garbage collector overhead is justified. One of the best things in C++ is RAII...and that's because C++ allows objects to live on the stack. When asking for garbage collection, I do not mean that stack based allocation should be abolished. I think C++ has a bright future In my company (more than 30 programmers), I am the only one that knows and supports C++. There are some other guys that knew C++, but have abandoned it...and having participated in Java projects, I can tell you that development with Java is waaay faster than C++...in fact, experienced programmers usually get the code right in their first try, something that is much less feasible in C++...and there is much less headaches with Java on finding libraries. 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. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: A Brief Look at C++0x
January 5, 2006 10:23 AM
|
|
> I can tell you that
> development with Java is waaay faster than C++... 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. |
|
Posts: 20 / Nickname: bigboy / Registered: June 14, 2004 10:43 AM
Re: A Brief Look at C++0x
January 5, 2006 0:38 PM
|
|
> But the library solution has several drawbacks:
> > In other words, she argues that if you want it, you can > do it as a library solution > > But the library solution has several drawbacks: > > 1) it introduces a memory overhead: the extra fields > needed inside property objects. 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. For what I call External Properties, there is a maximum 1-byte (+packing, if any) overhead for _all_ properties within a class. For example, in the current alpha version of XMLSTL, the node class for the MXSML mapping is 8 bytes: 4 for the IXMLDOMNode pointer, and 1 byte (+3 packing) for the property overhead for 23 properties. As I mentioned in a previous post, most compilers inline all the harness code, making it fully runtime efficient. > 2) it introduces a compiler overhead: the compiler should > compile all the code for each instantation of the property > template. 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. (Actually, I must fess up and concede that the C++ Properties technique has required one compiler - Digital Mars C++ - to go through a bug fix recently, to avoid an unwelcome ICE. But most compilers support it admirably, and with the stated efficiencies: CodeWarrior 8, Comeau 4.3.3, Digital Mars 8.46+, GCC 3.4+, Intel 6+, VC++ 7.1+) > 3) it introduces a programmer's overhead: it is quite easy > to forget 'initializing' a property member with the proper > pointers, especially if a class gets changed a lot. My implementation naturally avoids such a risky strategy. Everything is automatic. It's clear you've not read Ch 35 of Imperfect C++. Maybe now's the time to get hold of a copy. ;-) > I think these new features are ok but we need libraries > for network, serialization, inter-process communication, > xml, data-base, threads... > > I couldn't agree more. These libraries are long overdue. > C++ is being abandoned in favor of Java, due to Java > having a way much more complete SDK. Perhaps you'll be interested in checking out XMLSTL when I release the alpha in a few weeks. I plan to post a note on the Artima forum, if you keep an eye out there, or anywhere else you might recommend. (I'm currently spending most of my time working on volume 1 of my next book, Extended STL, which, I believe, does a pretty good job of showing just how much can be achieved within the current definition of the language, given a little thought and more than a little effort. <g>) > 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??? Sean Kelly and I are about to put forward the first (and simplest: it requires nothing of compilers / library beyond C++-98) of what we hope may be several proposals to the C++ standard, as soon as we can work out how one goes about it. Any pointers? Cheers Matthew |
|
Posts: 8 / Nickname: igaztanaga / Registered: January 3, 2006 9:57 PM
Re: A Brief Look at C++0x
January 5, 2006 3:20 PM
|
|
> I don't think garbage collector is needed at all.
> > It is badly needed, but it should be an option. In most > large projects, a great deal of effort is spent chasing > pointers. > > 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. 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. > and that new smart pointers can avoid nearly all manual > memory management > > No, smart pointers are not that good. First of all, they > are much slower than GC; secondly, you can not use smart > pointers in situations with circular references, and that > rules out a lot of data structures. ¿Much slower than GC? A lot of GC are based also on shared_ptr/weak_ptr scheme. And the language has to trigger the GC to start looking freeable objects. The difference is that I KNOW what is the cost of shared_ptr (atomic increment for every copy) and I can avoid those copies if in my code that's critical. The problem with GC is that I don't know what's going on. I agree that perhaps GC is very useful and productive, but since I'm used to manage memory by hand, I don't find memory allocation is a productive burden. And I DO think that almost all manual allocation can be avoided, when move semantics are added to the language + smart pointers. But manual does not mean that I lose control over allocation, I know what I'm doing, it's just I'm avoiding typing and avoiding usual errors. That's because I know what std::string does, what std::vector does, what std::shared_ptr does and most importantly I know WHEN. Now imagine another resource: shared memory, a file, a communication device... There is no garbage collector for this. You have to close the file, you have to release shared memory, you have to close the device. And there is no GC collecting open files to close them. Memory is just another resource that in C++ I can control uniformly using RAII, destructors or another scheme. > And memory is not the only resource you have to manage, > so I don't know if garbage collector overhead is > justified. > > One of the best things in C++ is RAII...and that's because > C++ allows objects to live on the stack. When asking for > garbage collection, I do not mean that stack based > allocation should be abolished. In my experience with languages with garbage collectors usually the perfomance is worse and the memory use, higher. Many times happens the same with manual management. But there is a difference in C++: I know what's happening. And I think that I can do it better than the GC (I'm not joking). Maybe some starter or medium programmers produces less buggier programs with GC, but when you know when memory is being allocated, and what the language is doing with every statement, no GC can't beat that. For example: Java has garbage collector. I really think that you can do efficient programs in Java. But that isn't the norm. You just have to know where the performance win is. But since GC is going its own way, in another thread, enters when it wants (or in a low priority thread) you can't control that. You don't know if assigning a variable is allocating heap memory (and even less when is releasing it). Is not about features, it's about control. That's way every Java program I try needs huge memory quantities. And that really annoys me, because your program is not alone in the computer. If every program uses that much memory we could only start 10 processes in a computer. We are not alone in the world, and our application is not the only one running in the computer. 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. There are unefficient C++ programs, but I can always find an efficient alternative. It's not about the programming language. I repeat: I'm sure you can program efficiently in Java. It's a problem of programmers. It's a problem of control. You know what's happening behind the curtains. You don't pay for you don't use. If you don't think about allocations, you lose control. And your program suffers, because memory allocation is not free. Maybe you will be more productive (but I doubt it if you are an experienced C++ programmer), and that can be fine in many areas, but not in others. > I think C++ has a bright future > > In my company (more than 30 programmers), I am the only > one that knows and supports C++. There are some other guys > that knew C++, but have abandoned it...and having > participated in Java projects, I can tell you that > development with Java is waaay faster than C++...in fact, > experienced programmers usually get the code right in > their first try, something that is much less feasible in > C++...and there is much less headaches with Java on > finding libraries. In my company everyone compiles in C++. Everyone. Some come from Java world. It's because we don't do web applications? Maybe yes. But we have programmers that can do web applications and program also embedded processors, using just a single language: C++. And do it efficienly. And some universities around here who changed from C++ to Java are now teaching C++ again, because they feel that students can't understand some basic programming concepts with Java. We just need libraries. LOTS of them. That's the difference with Java/.NET. And I think we are doing great efforts with Boost. |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: A Brief Look at C++0x
January 7, 2006 9:32 AM
|
|
>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. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 8, 2006 4:25 PM
|
|
> "-No true message passing."
> > Boost.Signals does this quite well, not requiring you to > specify the interface up-front. I am not talking about signals and slots, but message passing ala Objective C / Smalltalk. > > "-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. No, I am talking about probing a type for information about its structure at run-time. There is no performance impact at run-time; there is memory impact, but introspection could be optional. |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: A Brief Look at C++0x
January 4, 2006 6:03 AM
|
|
> Apart from auto, which will be a huge boon, there's
> precious little lacking in current C++ for anyone willing > to apply a little imagination. As Mr. Stroustrup has said, he gets letters from people complaining that C++ is too complex, but they would still like to add a feature or two... :) Yes, you have a good point about properties: As Stroustrup has said, a focus of the C++ language development (ever since the start, from what I can tell), is to give general features that work well together, rather than special-case constructs, where possible. As a result of this, a lot of cool stuff is invented or discovered for C++, all the time. As you point out (and others, like Lois Goldthwaite: "C++ Properties - a Library Solution (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf)", it's possible to implement properties in the current language. It's similar with things like lambda (like Boost.Lambda), but we could really use language support, here. However, as has been pointed out in this discussion, it comes down to the available manpower in the committee, who all work for free (and membership is available to all), so the C++ development is really a kind of "open source" project. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: A Brief Look at C++0x
January 4, 2006 6:01 PM
|
|
> As Mr. Stroustrup has said, he gets letters from people
> complaining that C++ is too complex, but they would still > like to add a feature or two... :) But seriously, that makes sense at least sometimes. C++ is complex to learn (or at least to master), and not much be done about it, but by adding features like module system (or at least standardized "#pragma once" instead of header guards), type inference, lambda expressions,... it can be made easier to use for working programmers. What's wrong with that? |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 4, 2006 7:02 PM
|
|
> > As Mr. Stroustrup has said, he gets letters from people
> > complaining that C++ is too complex, but they would > still > > like to add a feature or two... :) > > But seriously, that makes sense at least sometimes. C++ is > complex to learn (or at least to master), and not much be > done about it, but by adding features like module system > (or at least standardized "#pragma once" instead of header > guards), type inference, lambda expressions,... it can be > made easier to use for working programmers. What's wrong > with that? I suggest a small exercise: Look back at this brief discussion (less than two days, about 15 participants, about 40 messages) and count the number of suggested extensions, also note which ones were deemed "obvious", "long overdue", "most needed", etc. That done, try putting yourself in the shoes of the committee and decide how to proceed. -- Bjarne Stroustrup; http://research.att.com/~bs PS I saw no suggestion that would have been new a couple of years ago. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: A Brief Look at C++0x
January 4, 2006 7:50 PM
|
|
> I suggest a small exercise: Look back at this brief
> discussion (less than two days, about 15 participants, > about 40 messages) and count the number of suggested > extensions, also note which ones were deemed "obvious", > "long overdue", "most needed", etc. > > That done, try putting yourself in the shoes of the > committee and decide how to proceed. Well, I also suggested "obvious" and "most needed" features, while considering other peoples' proposals (such as properties, run-time reflection or GC) " bad", "dangerous" or even "disastrous" :) The comitee obviously cannot please everybody. However, I can't help but feel that C++ was progressing much faster before it was standardized. Did you really please *everybody* when you introduced multiple inheritance or exceptions, for instance? OK, this is not a fair question, because I read "The Design and Evolution of C++" (great book, BTW!) so I know the answer, but the point is that these features really make our work more enjoyable. In short, maybe the comitee should pay less atention to "the crowd" (me included) and just push forward. In the past it worked very well - I see no reason why it wouldn'twork in future as well. And finally (and it should have been really the first sentence in my first message), let me thank you for the great job you have done so far, and wish you success in the future. C++ is a great programming language; I have enjoyed programming with it in the past 10 years and hope to continue so at least for another decade. |
|
Posts: 6 / Nickname: vorlath / Registered: December 16, 2005 1:35 AM
Re: A Brief Look at C++0x
January 5, 2006 6:50 AM
|
|
C++ is downright stagnant. I still have the same problems now that I had 10 years ago. STL was great, but it was a long time coming.
If I was on the committee, I'd pick something and work on it. I feel that nothing's been done other than STL since the birth of C++. Why is that? It may not be true, but I know I'm not alone in this sentiment. Pick something, anything. There are now different implementations of STL because it's in the standard. Why have other areas been left in the dark? Even a recommended interface, even if flawed, can be improved upon, but would greatly help in reducing the insane number of #ifdef's required just to use the language. I'm not dissing the committee. I just think if they pushed forward as ntrif has said, then things would get moving (one would hope). BTW, the public can only keep suggesting what they want. And keep repeating them. That's what we're here for. The committee has to decide. No need to feel the obligation to respond if certain issues have already come up. I'm sure most everything has already been thought up at some point anyways. Sure, hearing the same thing over and over gets frustrating, but that's the way it has to be. I'm just getting worried because at the point where the computing field is right now, we're in desperate need of better tools and no one seems to know in what direction to go. This isn't just C++, but all languages. I think this could be a great opportunity for C++ if taken advantage. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 5, 2006 4:11 PM
|
|
> If I was on the committee, I'd pick something and work on
> it. Feel free. Details on the WG21 site. There you'll also find all the current proposals, complete with longish discussion/analysis papers. My "wish lists" on my C++ page will give you a brief summary of what people have asked for and this discussion should also provide a few dozen ideas. On my publications page, you can find a few of the papers that I have authored or co-authored. Here is a brief list of currently active topics concepts (a type system for template arguments) auto/decltype memory model (to support concurrency) threads libraries nullptr improved enumerations (or opaque types) file system library module system reducing the number of "undefined behaviours" initializer lists control of default class behaviours generalized constant expressions support for dynamically linked libraries arbitrary precision arithmetic more C99 compatibility static assertions move semanics simple compile-time reflection class namespaces local classes as template parameters (that's just a sampling - to be sure consult the WG21 site) -- Bjarne Stroustrup; http://www.research.att.com/~bs PS Please don't complain that not enough is being done unless you have yourself contributed what you can. The ISO C++ standard process is a volunteer effort; not a well financed corporate effort with an associated marketing machine. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: A Brief Look at C++0x
January 6, 2006 5:51 AM
|
|
> PS Please don't complain that not enough is being done
> unless you have yourself contributed what you can. The ISO > C++ standard process is a volunteer effort; not a well > financed corporate effort with an associated marketing > machine. I was under impression that compiler vendors are active members of the C++ standard comitee. Maybe we should send our complaints to them? After all, some of us are paying for our C++ compilers. One way or another, I really believe it is important to move faster if we don't want C++ to become another COBOL. Just read first posts at this discussion at Code Project (which used to be a C++ community just a couple of years ago, and now it is mostly a C# place): http://www.codeproject.com/lounge.asp?msg=1323694&mode=all&userid=14112#xx1323694xx And again, please don't take this as disrespect: I am grateful for the work you have done and believe C++ is the best general purpose programming language today. It is just not realistic to expect all 3 million C++ programmers to take part in the standard process: most of us are simply not qualified for that. Personaly, I have no expertize at making compilers at all, and the kind of libraries I work on (natural language processing) are definitely not candidates for the Standard Library. |
|
Posts: 18 / Nickname: mlybbert / Registered: April 27, 2005 11:51 AM
Just curious
January 5, 2006 4:58 PM
|
|
Since ISO standards are put on a 10-year upgrade track, what does the committee do after a standard is put out? I know that erratta is corrected, etc. Does the committee immediately begin work on the next decade of changes? Is there really that much work to be done?
|
|
Posts: 2 / Nickname: mbergal2 / Registered: January 5, 2006 7:20 PM
Re: Just curious
January 6, 2006 1:48 AM
|
|
> PS Please don't complain that not enough is being done
> unless you have yourself contributed what you can. The ISO > C++ standard process is a volunteer effort; not a well > financed corporate effort with an associated marketing machine. How do you see the process for addressing problems/issues C++ users have with C++ language? Especially when there is no "well financed corporate effort" as in Java or C#, where scores of people are paid to listen to user problems and make language/libraries better. Some of that was addressed in your post on January 4 and it is important to me to comment on that. You wrote: BS> The standards process is open and - believe it or not - BS> cheap compared to other processes defining our world. I do not think that standard process is sufficently open. Two issues come to mind immediately: 1. A lot of committee discussions take place on the mailing lists not available to general public. 2. The community might not even know what is happening, because the information is not easily accessible. I think this illustrates the problem very well: Q: How do I get to main Python web site? A: http://www.python.org Q: How do I get to main C++ one? A. Is there one? May be you should got to the commitee site. http://google.com, then search for WG21, then choose first link in the results. BS> However, the investment for an individual is mostly time BS> (weeks a year) and - if you want to vote - $800 a year." I hope you are not saying that to affect the situation the only sensible choice C++ user have is to spend $800+travel expenses a year and weeks of his time as a member of the committee. I believe that this is just too much to expect. I also think that we need to make sure that C++ development doesn't depend on availability of enthusiasts willing to sacrifice their personal time, money and energy. |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: Just curious
January 6, 2006 3:25 AM
|
|
> I also think that we need to make sure that C++
> development doesn't depend on availability of enthusiasts > willing to sacrifice their personal time, money and energy. 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. However, C++ shares this with many other languages (such as Perl, Python, PHP, etc.). However, unlike them, it's an ISO standard, meaning there's neither a BDFL, either. |
|
Posts: 2 / Nickname: mbergal2 / Registered: January 5, 2006 7:20 PM
Re: Just curious
January 6, 2006 10:49 PM
|
|
> 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 |
|
Posts: 1 / Nickname: mf / Registered: January 12, 2006 9:00 PM
Re: A Brief Look at C++0x
January 15, 2006 6:39 PM
|
|
Hi,
"PS Please don't complain that not enough is being done unless you have yourself contributed what you can. The ISO C++ standard process is a volunteer effort; not a well financed corporate effort with an associated marketing machine. " Personally I feel that I am neither experienced nor smart enough to contribute technically in a meaningful way. However, given that the process is a resource limited volunteer effort, would the situation improve if the community (ie all of us demanding users) were to contribute somehow financially? Given the enormous amount of money that is spent on projects developed by people/companies using this wonderful language it seems bizarre that development of same is resource limited! Surely there are enough community conscious people/companies that we can alleviate this problem? I know I would be happy to contribute, and surely the big companies that are making large sums of money from c++ community are also (morally) obliged to do so? Obviously this would have its own difficulties, but would they be easier to manage than resource limitations? Cheers, Michael |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: A Brief Look at C++0x
January 16, 2006 4:46 AM
|
|
> Given the enormous amount of money that is spent on
> projects developed by people/companies using this > wonderful language it seems bizarre that development of > same is resource limited! Surely there are enough > community conscious people/companies that we can alleviate > this problem? I know I would be happy to contribute, and > surely the big companies that are making large sums of > money from c++ community are also (morally) obliged to do > so? It's an interesting idea. According to a recent blog by Guido van Rossum, he gets to spend 50% of his time at Google working with Python, no strings attached (the other 50% will be with Python, too. :) ). After all, Google is a big user of Phyton (after C++ and Java), so this benefits themselves, as well. Maybe if larger companies that are using C++, where some of the more active members of the C++ committee, or other C++ contributors, work, could do similarly - allow them to work on C++ proposals, prototype implementations, etc. in a part of their working day. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 9, 2006 8:09 PM
|
|
Sorry for following up on myself, but could I have a quick poll? Please make at most three suggestions for C++0x. For each, give a max two lines of explanation of what is wanted and max two lines of explanation why it is wanted. For example:
concepts what: a type system for types for use with template argument why: to get better error messages and better overloading of templates Try to really make it your first choices. Imagine you could get at most those three and no other. Don't be afraid to repeat other people's wishes. Please be specific; that is, don't make suggestions that are generalized to be whole categories of extensions, such as "better support for generic programming". Please give suggestions in order of preference. -- Bjarne Stroustrup; http://www.research.att.com/~bs |
|
Posts: 8 / Nickname: igaztanaga / Registered: January 3, 2006 9:57 PM
Re: A Brief Look at C++0x
January 10, 2006 6:45 AM
|
|
-> threads/interprocess communication
what: tools for multi-processing multi-threading: thread/process launch, mutex, condition variables, read-write locks, pipes, message queues, shared memory, memory mapped files. STL containers in shared memory/memory mapped files. why: One of the biggest gaps in C++. We can't launch an application/thread in C++ in a standard way and communicate with other processes/threads. Basic building blocks for every real-world system. Benefits: Responsiveness, huge performance improvements, easier programming and scalability. -> network what: tools for network programming. Support for synchronous and asynchronous network programming. why: One of the biggest gaps in C++. We can't communicate with other computers in a standard way. Network is present in every aspect of our lifes and is a high performance application suitable for C++. -> move semantics/rvalue reference what: possibility to assign the resources of one object to another, instead of copying the resources. why: Huge performance benefits, specially in STL containers and algorithms. Perfect forwarding. Avoiding many manual memory allocations with no perfomance loss. Containers of noncopyable objects. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: A Brief Look at C++0x
January 10, 2006 5:38 AM
|
|
> Sorry for following up on myself, but could I have a quick
> poll? Please make at most three suggestions for C++0x. For > each, give a max two lines of explanation of what is > wanted and max two lines of explanation why it is wanted. 1. Module/component system what: language support for building components and modules why: to enable making C++ components in a portable way 2. Lambda expressions what: (informally) unnamed functions why: reduce the amount of code and possibility for errors by applying STL algorithms instead of loops 3. Move semantics what: ability to "move" objects rather than copy them why: improved performance especially when dealing with containers. |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: A Brief Look at C++0x
January 10, 2006 6:59 AM
|
|
> > Sorry for following up on myself, but could I have a
> quick > > poll? Please make at most three suggestions for C++0x. > For > > each, give a max two lines of explanation of what is > > wanted and max two lines of explanation why it is > wanted. > > 3. Move semantics > what: ability to "move" objects rather than copy them > why: improved performance especially when dealing with > containers. There exists an "rvalue references" proposal that enables move semantics, and I think this was kind of accepted "in principle" at the Lillehammer-meeting, and sent to the the Core Working Group for further consideration. I see from the minutes of the following Tremblant meeting last fall, that they haven't yet got a chance to consider it, though: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1915.html However, there already exists proposed wording for it: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1770.html, as well an extension to cover *this: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1821.htm. So this one is pretty certain. "rvalue references" both enables move semantics, and solves the "forwarding problem" (at least the part involved with the type of the parameters). As for lambda: Well, as it's not on any list of active proposals - for that matter, I haven't seen any (in)formal proposal for this... I wouldn't bet on it. :) However, if someone did the work of making and following up such a proposal, including, in particular, what it would take to implement it, such as its effect on the rest of the language, then who knows... Modules: At least it's under active consideration (a proposal for it was presented at the Lillehammer meeting), but I don't see it mentioned in the Tremblant minutes. |
|
Posts: 1 / Nickname: jghickman / Registered: January 10, 2006 1:33 AM
Re: A Brief Look at C++0x
January 10, 2006 7:21 AM
|
|
Hello Dr. Stroustrup,
> Sorry for following up on myself, but could I have a quick > poll? Please make at most three suggestions for C++0x. For > each, give a max two lines of explanation of what is > wanted and max two lines of explanation why it is wanted. 1) Portable GUI - because the need comes up so often. But since the odds aren't good here, I'll list 4 items rather than 3. :-) 2) Threads/Synchronization - because there's an increasing need for multi-threaded software. 3) Sockets - because we need portable, type-safe and exception-safe interfaces for communication between distributed systems. Finding a design that supports the right mix of exception-safety, performance, and platform-independence (while still allowing platform-specific functionality) isn't the most straight-forward of problems. 4) Matrix/Vector Linear Algebra - because various aspects of this functionality seem to get "re-invented" a lot. but this one's obviously a little more specialized than the others. -Greg |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 10, 2006 4:22 AM
|
|
> Sorry for following up on myself, but could I have a quick
> poll? Please make at most three suggestions for C++0x. For > each, give a max two lines of explanation of what is > wanted and max two lines of explanation why it is wanted. > For example: > > concepts > what: a type system for types for use with template > late argument > why: to get better error messages and better > tter overloading of templates > For now I will post only one: garbage collection what: we all know what it is about, don't we? why: it will simplifies programming by relieving the programmer from memory tracking issues, allowing him/her to concetrate on the problem at hand |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 10, 2006 6:55 AM
|
|
I actually have some more requests, so please allow me to post again.
1) garbage collection. what: we all know what it is about, don't we?. why: it will simplifies programming by relieving the programmer from memory tracking issues, allowing him/her to concetrate on the problem at hand. 2) pass-by-name semantics. what: to be able to invoke functions by passing parameters by name. why: it simplifies writing constructors for classes with lots of options; it simplifies calling functions with lots of parameters. 3) tuples as first class values. what: to be able to handle composite literals, i.e. expression lists surrounded by curly brackets, as first class entities. why: it will solve the problem of sequence constructors, as well as provide a way to declare composite values in a structured manner, similar to S-expressions. Let me expand on my third request a little. It is impossible, for now, to do the following in C++:
If the expression within the curly brackets was a first-class entity, then we could write the vector constructor like this:
The operator [] could be used for indexing of a tuple's members. Arrays are homogeneous tuples after all.Tuples as first class entities will also allow us to do declarative programming. For example, a GUI dialog could be declared as a series of nested tuples. If coupled with pass-by-name, it could make our life much easier for many things. Example:
Or an HTML page:
The above code, when executed, would actually process the tuple 'page1' and produce a string buffer with the appropriate HTML. Tuples themselves could be templates, parameterized over the type of their content. A 'tuple' declaration without template parameters is a generic tuple; a 'tuple' declaration with parameters could only accept a literal that reflects the structure of the tuple. Examples:
Tuple types will be like template constraints: a type system for tuples. It will allow compiler validation of declarative forms. |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: A Brief Look at C++0x
January 10, 2006 6:07 AM
|
|
> > Sorry for following up on myself, but could I have a
> quick > > poll? Please make at most three suggestions for C++0x. > For > > each, give a max two lines of explanation of what is > > wanted and max two lines of explanation why it is > wanted. > > For now I will post only one: garbage collection > > what: we all know what it is about, don't we? > > why: it will simplifies programming by relieving the > programmer from memory tracking issues, allowing him/her > to concetrate on the problem at hand Such as optimising the program, due to the effect of the garbage collector? :) Sorry, I couldn't resist. :) As mentioned in another posting, garbage collection doesn't _remove_ the problem of resource management, only _changes_ it, with different "gotchas", and it only handles memory, which doesn't necessarily make resource management easier, and could make it harder. However, as this is a suggestion for an _optional_ feature (and your posting wasn't intended to restart that discussion, I guess), then using it is at least voluntary. Moreover, I've heard that, for some scenarios, GC may be faster than reference counting (some call the latter a kind of GC, anyway, but with GC, here, I mean a "traditional" one, such as no support for destructors), such as in a multithreaded system, due to locking issues (the reference count may need to be locked for each copy made, or at least the use of atomic instructions). |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 10, 2006 7:02 AM
|
|
> Such as optimising the program, due to the effect of the
> garbage collector? :) > > Sorry, I couldn't resist. :) As mentioned in another > posting, garbage collection doesn't _remove_ the problem > of resource management, only _changes_ it, with different > "gotchas", and it only handles memory, which doesn't > necessarily make resource management easier, and could > make it harder. I absolutely agree. But GC is very useful because many computational problems do not have other types of resources except memory. GC is important. > > However, as this is a suggestion for an _optional_ feature > (and your posting wasn't intended to restart that > discussion, I guess), then using it is at least > voluntary. Yes, totally optional. With C++, "you don't pay for what you don't use". > > Moreover, I've heard that, for some scenarios, GC may be > faster than reference counting (some call the latter a > kind of GC, anyway, but with GC, here, I mean a > "traditional" one, such as no support for destructors), > such as in a multithreaded system, due to locking issues > (the reference count may need to be locked for each copy > made, or at least the use of atomic instructions). Even if GC makes programs a little slower, you have to question yourself what is better: a) to have manual memory management, utra-fast execution but very slow development or b) automatic memory management, slightly-less fast execution but quick development? And as I have said before, GC for C++ does not mean GC for Java. Since most C++ objects live in the stack anyway, the only objects to be managed by GC in a C++ program are complex arbitrary structures, usually defined by run-time rules, and many times with cyclic references. |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: A Brief Look at C++0x
January 10, 2006 7:32 AM
|
|
> > Moreover, I've heard that, for some scenarios, GC may
> be > > faster than reference counting (some call the latter a > > kind of GC, anyway, but with GC, here, I mean a > > "traditional" one, such as no support for destructors), > > such as in a multithreaded system, due to locking > issues > > (the reference count may need to be locked for each > copy > > made, or at least the use of atomic instructions). > > Even if GC makes programs a little slower, you have to > question yourself what is better: a) to have manual memory > management, utra-fast execution but very slow development > or b) automatic memory management, slightly-less fast > execution but quick development? Yes, my concern is mainly optimising developer time - trying to optimise the code in the Java project I worked on, due to it being too slow from GC-trashing, was certainly not very optimal on developer time, and in that case, I think stack-allocated objects, and perhaps some reference-counting, or other ownership strategies, like a hierachical parent-child one, would have done just fine, and saved me from that problem. But a) C++ wasn't an option (having to work in a browser), and b) GC in Java is mandatory, not optional. However, there may well be other projects, or features, that could be hard to do well in other ways than using GC. The problem is when all you have is a hammer... :) > And as I have said before, GC for C++ does not mean GC for > Java. Since most C++ objects live in the stack anyway, the > only objects to be managed by GC in a C++ program are > complex arbitrary structures, usually defined by run-time > rules, and many times with cyclic references. C++/CLI has such a scheme, where you can both have stack-allocated objects and RAII, as well as GCed objects, all working well with CLI/CLR. |
|
Posts: 1 / Nickname: jlopez / Registered: June 2, 2005 1:02 AM
Re: A Brief Look at C++0x
January 9, 2006 11:18 PM
|
|
May I suggest you post this poll announcement as a separate entry, maybe into your artima weblog? Buried like it is in a seven day discussion log, it might not get as much attention as possible.
|
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 10, 2006 7:19 AM
|
|
> May I suggest you post this poll announcement as a
> separate entry, maybe into your artima weblog? Buried like > it is in a seven day discussion log, it might not get as > much attention as possible. Yes. I know. I'm kicking myself for not suggesting it earlier. This kind of poll is something I have done many times before, mostly at users' group meetings and BOFs. In addition to giving me valuable information it tends to educate to participants about the (to them) amazing diversity of opinions/needs/suggestions. Usually, the union of 50 people's top two or three choices is 50+ distinct suggestions. I don't have a blog. -- Bjarne Stroustrup; http://www.research.att.com/~bs |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: A Brief Look at C++0x
January 10, 2006 7:48 AM
|
|
> This kind of poll is something I have done many times
> before, mostly at users' group meetings and BOFs. In > addition to giving me valuable information it tends to > educate to participants about the (to them) amazing > diversity of opinions/needs/suggestions. Usually, the > union of 50 people's top two or three choices is 50+ > distinct suggestions. Maybe some of the effect is due to people not wanting to repeat what others have already suggested, so they select other proposals that haven't been proposed, yet? One way to alleviate that concern could be to have "secret voting" (however, maybe that's how you did it, sometimes). However, even then, there might be some of the same effect ("Many will probably propose feature X, and I'd like to have both X and Y, so I'll propose feature Y, giving that a chance, as well."). At least, phrased as it was ("Please make at most three suggestions for C++0x"), it doesn't state that you should propose your three _most wanted_ features (even though that might be intended, implicitly), so the result might exhibit the above mentioned effect to some degree. I'm sure that even without such an effect, there would still be a large number of distinct proposals, though. |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: A Brief Look at C++0x
January 10, 2006 8:18 AM
|
|
> > This kind of poll is something I have done many times
> > before, mostly at users' group meetings and BOFs. In > > addition to giving me valuable information it tends to > > educate to participants about the (to them) amazing > > diversity of opinions/needs/suggestions. Usually, the > > union of 50 people's top two or three choices is 50+ > > distinct suggestions. > > Maybe some of the effect is due to people not wanting to > repeat what others have already suggested, so they select > other proposals that haven't been proposed, yet? > > One way to alleviate that concern could be to have "secret > voting" (however, maybe that's how you did it, sometimes). > However, even then, there might be some of the same effect > ("Many will probably propose feature X, and I'd like to > have both X and Y, so I'll propose feature Y, giving that > a chance, as well."). > > At least, phrased as it was ("Please make at most three > suggestions for C++0x"), it doesn't state that you should > propose your three _most wanted_ features (even though > that might be intended, implicitly), so the result might > exhibit the above mentioned effect to some degree. > > I'm sure that even without such an effect, there would > still be a large number of distinct proposals, though. I have tried either way; that is with or without an hours discussion before the vote. A discussion sways people to pick a few top choices from the discussion, but there is still a large spread of "second or third choices". Conversely, there tend to be front runners even without a discussion, but interestingly those front runners vary from community to community. "Can you give use the data?" is an obvious question. I can't really, I simply integrate my impressions in my talks, papers, and wish lists (see my C++ page). Obviously, the committee's choices are consistently more "technical" than the choices for any user community. -- Bjarne Stroustrup; http://www.research.att.com/~bs |
|
Posts: 5 / Nickname: limit / Registered: January 11, 2006 2:08 AM
Re: A Brief Look at C++0x
January 11, 2006 10:57 AM
|
|
> Sorry for following up on myself, but could I have a quick
> poll? Please make at most three suggestions for C++0x. 1. Support for modules what: language support for modules as described in WG21/1778 or similar why: solve, please, the problem with order of dynamic initialization of non-local entities at last. 2. Standard way for specifying character encoding of source file. what: standard #pragma or another mechanism. For example: #pragma meta(encoding="windows-1251") // encoding name as registered in IANA why: Better internationalization support. 3. class/struct/union namespaces as described in SC22/WG21/1420 or similar what: let consider code example: namespace Implementation { class Foo { class Rep { typedef int& TReference; TReference f(); // and much more members } }; } Current style for out of class implementation: inline Implementation::Foo::Rep::TReference Implementation::Foo::Rep::f() { /* */ } Easy and simple, you are sure?. But do not forgot about template members of template class with template template parameters!!! Proposal: class namespace Implementation::Foo::Rep { inline TReference f() {/* */} // another members implementation } or namespace class Implementation::Foo::Rep { } 'class' in both cases is optional keyword and may be also 'struct' or 'union'. why: stop discrimination for users that prefer to hide implementation details from class definition. 4) CTTI (sorry, can't stop :) ) what: compile time type information (typeof, bases typelist and so on). why: allows new programming technics. Can I also protest again the unhelpful suggestions? Thanks's. 1) garbage collection. what: last hope for thoughtless programmers. why: smart pointers are enough in most cases. 2) network library, GUI library, Klingon language parsing library and others "must have" libraries as parts of C++ standard. what: some stuffs that "must have" only for it contributors . why: too large standard library knock down the language standartization process and the compilers vendors. Please see how much issues are still open for relatively small std library. And when we take the stable std0x library if it will include hundreds of "must have" libraries? In 202x? If someone wants XXX standard library let it begin independent standartization process. I will glad to see the "Standard XML library for C++", "Standard GUI library for C++" and so on but not in "International Standard for C++ programming language". This all is my HO, of course. Thanks for attention, Dmitriy Litskalov |
|
Posts: 5 / Nickname: limit / Registered: January 11, 2006 2:08 AM
Re: A Brief Look at C++0x
January 11, 2006 11:07 AM
|
|
Sorry for typo:
> Can I also protest again the unhelpful suggestions? again --> against |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 12, 2006 2:22 AM
|
|
> Can I also protest again the unhelpful suggestions?
> ions? Thanks's. > > 1) garbage collection. > what: last hope for thoughtless programmers. > why: smart pointers are enough in most cases. Smart pointers are good for trivial tasks only. > If someone wants XXX standard library let it begin > independent standartization process. If a library is not (at least) endorsed by the C++ standards commitee, no one will consider it a 'standard'. |
|
Posts: 5 / Nickname: limit / Registered: January 11, 2006 2:08 AM
Re: A Brief Look at C++0x
January 12, 2006 5:56 AM
|
|
> > 1) garbage collection.
> > what: last hope for thoughtless programmers. > > why: smart pointers are enough in most cases. > > Smart pointers are good for trivial tasks only. Garbage collection is also good for trivial tasks only. How garbage collector will be proccess the complex data structures with the crosslinked entities? While a C++ programmer is responsible for the memory management he must keep it in mind and it always possible to find the appropriate solution. For example two stage deletion or something else. I'm afraid that if garbage collection will become the part of standard runtime support then any novice or semi-skilled programmer will never think about the memory managament rely on the garbage collector possibilities. And you will never prove that some library has a memory leak. The library author will say "this is bug in garbage collector". |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 12, 2006 7:48 AM
|
|
> > > 1) garbage collection.
> > > what: last hope for thoughtless programmers. > > > why: smart pointers are enough in most cases. > > > > Smart pointers are good for trivial tasks only. > > Garbage collection is also good for trivial tasks only. No, garbage collection allows arbitrary organization of structures, up to a complexity level that smart pointers do not allow. > y. How garbage collector will be proccess the complex data > structures with the crosslinked entities? Please search the web on how garbage collectors work, there is plenty of documentation. >While a C++ > programmer is responsible for the memory management he > must keep it in mind and it always possible to find the > appropriate solution. Exactly, that's one of the problems: trying to keep track which objects must be deleted and where they must be deleted distracts from the main task. > I'm afraid that if garbage collection will become the > he part of standard runtime support then any novice or > semi-skilled programmer will never think about the memory > managament rely on the garbage collector possibilities. GC shall be optional. > And you will never prove that some library has a memory > leak. The library author will say "this is bug in garbage > collector". Any good idea is first ridiculed, then rejected, then finally accepted. |
|
Posts: 5 / Nickname: limit / Registered: January 11, 2006 2:08 AM
Re: A Brief Look at C++0x
January 12, 2006 8:58 AM
|
|
>
> Please search the web on how garbage collectors work, > there is plenty of documentation. I known this mechanics but do google by you advise. May be industry invent something new... Second link, http://www-128.ibm.com/developerworks/library/j-jtp10283/ : "The benefits of garbage collection are indisputable -- increased reliability, decoupling of memory management from class interface design, and less developer time spent chasing memory management errors. The well-known problems of dangling pointers and memory leaks simply do not occur in Java programs. (Java programs can exhibit a form of memory leak, more accurately called unintentional object retention, but this is a different problem.) However, garbage collection is not without its costs -- among them performance impact, pauses, configuration complexity, and nondeterministic finalization." See phrase in parenthesis. It point to same problem that I describe. And keep in mind that C++ pointers can be passed to the another subsystems which not under control of garbage collector. This is not closed Java world. For example in Windows GUI programming I can store one available reference to object in special lParam data field what maintained internally by common controls such as TreeView, ListView and so on. How garbage collector will known that this object live if no other references to it exists? This object must by deleted only in response to the special Windows message, not by any collectors. > > I'm afraid that if garbage collection will become the > > he part of standard runtime support then any novice or > > semi-skilled programmer will never think about the > memory > > managament rely on the garbage collector possibilities. > > GC shall be optional. Please clarify for me what does mean "optional". For example some library LibA rely on GC. Another library LibB uses LibA internaly in few places. LibB use handmade memory managament. I'm use LibB in my program. I'm never create objects from LibA directly. Moreover I don't known anything about LibA. Some questions: - Will be GC runtime engine linked to my program? - Will be GC engine recieve control in any point of my program even if I use LibB only on startup? - My program is single threaded. How GC recieve control? > Any good idea is first ridiculed, then rejected, then > finally accepted. May be. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A Brief Look at C++0x
January 13, 2006 4:41 AM
|
|
> retention, but this is a different problem.) However,
> garbage collection is not without its costs -- among them > performance impact, pauses, configuration complexity, and > nondeterministic finalization." I know all about gc problems - but with C++, these problems are minimal. Let's see them: 1) performance impact. C++ has advantages over Java. Specifically, Java requires all objects to be on the heap, and Java code is supervised. On the other hand, most C++ objects, especially small ones, are allocated on the stack, and code runs native. So C++ gc will not slow down a program, since the number of actual objects on the heap are much less than in Java, and C++ code does not need to be monitored. I see no performance impact. 2) pauses. GC will be optional. If you are doing a real-time project and pauses are unacceptable, don't use it. 3) configuration complexity. I don't understand what that is. What complexities? 4) nondeterministic finalization. Order of finalization is not something GC must be concerned with. Destructors/finalizers are there in order to finalize resources that are is difficult to determine when they shall be finalized. In most cases though, finalization of resources takes place when some sort of event takes place: a user option, a program exit, an algorithm end, a new file opened, etc. Furthermore, C++ has RAII, which Java lacks. > at I describe. And keep in mind that C++ pointers can be > passed to the another subsystems which not under control > of garbage collector. This is not closed Java world. For > example in Windows GUI programming I can store one > available reference to object in special lParam data field > what maintained internally by common controls such as > TreeView, ListView and so on. How garbage collector will > known that this object live if no other references to it > exists? This object must by deleted only in response to > the special Windows message, not by any collectors. It is silly to store garbage-collected pointers in non-pointer structures. The solution is one: don't do it. For those libraries that manage code manually, the solution is to keep doing it manually, unless a new version of the library comes that is garbage collected. > > > > I'm afraid that if garbage collection will become the > > > he part of standard runtime support then any novice > or > > > semi-skilled programmer will never think about the > > memory > > > managament rely on the garbage collector > possibilities. > > > > GC shall be optional. > > Please clarify for me what does mean "optional". Optional means that the programmer can a) allocate a data structure either in the garbage-collected heap or in the manually managed heap b) turn GC off and on at will > > For example some library LibA rely on GC. > Another library LibB uses LibA internaly in few places. > LibB use handmade memory managament. Since LibB uses LibA, it means LibB is constructed after LibA is constructed. Therefore I see no reason why LibB would have manual memory management where it knows that LibA uses GC. > Some questions: > - Will be GC runtime engine linked to my program? Yes. > - Will be GC engine recieve control in any point of my > program even if I use LibB only on startup? I do not understand this question fully, but if you use GC stuff, then the GC engine will be invoked somewhere. > - My program is single threaded. How GC recieve control? Personally I see no reason why GC should be a separate thread. So my reply is 'a single threaded app with gc shall have no other threads'. |
|
Posts: 18 / Nickname: mlybbert / Registered: April 27, 2005 11:51 AM
My two suggestions
January 10, 2006 9:40 AM
|
|
/* but could I have a quick poll?
*/ Aside from the new use for "auto" and concepts, I'd like: optional C++ extensions to macro system what: Add extensions to the preprocessing macro system such that old C macros work, but that programmers can take advantage of macros defined at a "conceptual level" instead of at a textual level -- perhaps by adjusting the parse tree instead of the source code. why: While C++ features like templates and const data can elliminate the need for many C macros, some programmers like the possibility of adding keywords to their own programs, without being constrained by template syntax, etc. This generalized construct sould then be used to define "pass by name" or similar wishes. And, yes, I know that this is asking for quite a lot, and that any feature giving access to the parse tree would be implementation defined. I'm not holding my breath. But, I also want: standardized locales what: Currently the locale system is somewhat "implementation defined," although the direction is to allow programmers to build up messages from a catalog of translated strings. Change this to have a specific interface. why: Currently programs using locales are officially standard C++ but may not be portable. |
|
Posts: 6 / Nickname: abrahams / Registered: October 6, 2004 10:03 AM
Pass By Name
March 4, 2006 8:32 PM
|
|
> optional C++ extensions to macro system
> what: Add extensions to the preprocessing macro system > such that old C macros work, but that programmers can take > advantage of macros defined at a "conceptual level" > instead of at a textual level -- perhaps by adjusting the > parse tree instead of the source code. > why: While C++ features like templates and const data can > elliminate the need for many C macros, some programmers > like the possibility of adding keywords to their own > programs, without being constrained by template syntax, > etc. This generalized construct sould then be used to > define "pass by name" or similar wishes. FYI, there's a library solution for "pass by name:" http://www.boost.org/libs/parameter |
|
Posts: 1 / Nickname: thesim / Registered: March 21, 2006 2:01 PM
C++
March 21, 2006 7:19 PM
|
|
Hello hello. Is this thing still on?
- Re, lambdas: Does anyone use bind()? - Re, threads: A reliable model of threading in C++ will not exist until exceptions and cancellation are unified. I almost fear it is too late for this in the general population though, due to the entrenched legacy behavior on most C++ platforms. |
|
Posts: 1 / Nickname: cyberpoep / Registered: February 23, 2006 11:43 AM
Re: A Brief Look at C++0x
February 23, 2006 4:55 PM
|
|
Sorry for interrupting this discussion but I'm new to C++ and when I saw Bjarne writing an article I thought wow maybe this C++ Genius may know the real C++ Genius http://www.cplusplusgenius.wagoo2.com/
Is there anyone in this forum who knows this guy. Is he really a genius? I wish he would upload the software he's refering to on his downloads page. Ok you can continue discussing this new C++ thing, but please let me know if you know anything about this guy. Thanks |
|
Posts: 3 / Nickname: semantic / Registered: May 21, 2006 3:47 AM
Re: A Brief Look at C++0x
May 21, 2006 8:46 AM
|
|
I realise I am joining in *very* late in the discussion,
but here goes: 1. default constructor what: The default ctor should be automatically defined (if the user does not provide one) *even if* the user provides other ctors. why: C++ supports value oriented programming (where classes can be used in the same way as builtin types), but having the default constructor behave differently (in this regard) than the copy constructor is confusing (as to why) and unneccessary. If you do not want a value class, inhibit the dflt ctor the same way you would inhibit the copy ctor. 2. hiding vs overloading What: A function "f" (with unique argument types) in a class "Derived" should not hide other f in the base class "Base". It should overload the other f in the base class. Why: Every time I have declared a "f" in a subclass (with other f in "Base", it has been with the intention to overload. Never to hide. Hiding violates LSP. This behaviour in C++ has always surprised me, and I have never felt that it has been right (in 15 years of C++ programming). I know about "using Base::f" but it seems better to have that behaviour as default (that is, overloading). 3. overloading resolution What: When looking for candidate (member) functions, do not consider functions that I can not access (eg. private functions). Only consider functions that are accessible to me at that point. Why: The whole idea of "separating interface from implementation" is about not needing to the implementation. It is not very robust if suddenly I can not compile a piece of code because the implementation needed and declared (in the class) a new function that happens to be the best match *if I could have used it*. I know about the pimpl idiom, but this should have the (in my vew) correct behaviour for the "basic" class usage already. |
|
Posts: 1 / Nickname: bismuth / Registered: August 17, 2006 3:09 AM
Re: A Brief Look at C++0x
August 17, 2006 7:34 AM
|
|
Not sure if this has been mentioned before, but how about adding the ^^ as a logical exclusive OR boolean operator?
It would complete the set, along with the current || and && Having &&= ||= and ^^= would be nice too. Yes, I know you can do all of this with the binary operators, but wouldn't it be better to do it properly? |
|
Posts: 11 / Nickname: lemonhead / Registered: November 23, 2006 0:53 AM
My Wishes
November 23, 2006 8:15 AM
|
|
1. Variadic templates
(as suggested and discussed elsewhere) 2. Anonymous nested objects (here: c.nested) with access to the containing object (here: c of type C). It should be possible to derive their type from a base class (here: 'Base'). struct Base {
virtual void foo() {}
};
struct C {
void foo_C() {}
// not possible in c++ nowadays
Base {
void foo() {foo_C();} // nowadays, c.nested has no access to the members of c.
} nested;
// not possible in c++ nowadays
Base nested {...};
// not possible in c++ nowadays
struct {...} nested : Base;
// not possible in c++ nowadays
struct : Base {...} nested;
// not possible in c++ nowadays
struct {...} nested;
} c;
Base* b = c.nested;
b->foo();
To access the members of c, c.nested doesn't need to store a reference. The adress difference of c and c.nested is the same for any object c with type C, so accessing c.foo_C() would technically be no problem. (Nowadays, this can be achieved using the barton-nackmann trick and multi-inheritance, but that's not a nice solution) 3. The same for nested functions - they should as well be able to access other members of the containing class or function. 4. A "This" keyword to identify the type of "*this". template<... ... ...> class A {
typedef A<... ... ...> This; // too clumsy, should be done by the compiler!!
};
5. exit loops with a break statement with return value for(...) {
...
if(..) break end_of_file(i);
else if(..) break end_of_file(i+5);
else if(..) break found_error("parsing_error");
...
if(..) break found_error("mature content");
}
cout << "normal_break" << endl;
label end_of_file(int line_number) {
cout << "end of file reached in line "<< line_number << endl;
}
cout << "normal break or end of file finished" << endl;
label found_error(char* message) {
cout << "found error " << message << endl;
}
cout << "normal break or eof or found an error" << endl;
These labels are similar to nested functions. The difference is, when they are finished, execution will continue in the line where the label block ends. The same could be achieved with helper functions, but then the code would be scattered in places where it is hard to find. |
|
Posts: 11 / Nickname: lemonhead / Registered: November 23, 2006 0:53 AM
Re: My Wishes
November 23, 2006 8:19 AM
|
|
Oops, a mistake in point 2. The last declaration should be
// possible in c++, but doesn't derive anything
struct {...} nested;
Btw, why the heck can't i edit my post??? |