# Really: C++0x

This topic is 3455 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

The other C++0x thread has devolved to flame-fests about languages, semantics, and other horrors. So can we just talk about C++0x? :-) I think this is the latest working group report: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2597.html I'm a bit ... intimidated ... by the raw wall of text. Is this what the headings mean?
Quote:
 Integrated into working paper: Already part of the proposed standard Proposed wording under review in Core: Wording has been made, but the final blessing has not. Almost certainly will be part of the proposed standard. Blessed by evolution - wording available for initial review by Core: Intended to be included in the standard, but the CWG hasn't gotten around to officially reading this version. Core issues addressed by specific papers: Side issue Active topics in the Concurrency sub-group: We want threads. These papers are intended to make it into C++09. Hurry up, in parallel. New work for Evolution: Evolution is mostly finished it's job -- these are the last little bits. Might as well use the resource. Should make it into the standard? Background papers for reference & Evolution of current proposals: These links should go somewhere, as they are important! Not quite ready for C++0x timetable, but actively pursued: Sorry! You have failed in getting your work into C++09. So we are dropping you. There is some hope that we'll fold you into C++10, or C++09.1! Heading for a separate TR: Omg, we are swamped by features. These will be put into the "beta for the next version of C++" TRs. Heck -- if you polish it, it might even beat the previous category! Not ready for C++0x, but open to resubmit in future: Not good enough to spend resources on, but not dumb enough for the next category. No interest, or superseded by other proposals: Go away. No really. Stop submitting this crap. We solved it better, anyhow!
I'm just trying to get a grasp on what is probably going to come out the other end of the C++0x sausage factory! Less wall-of-texty, anyone have a favourate feature they want to gush about?

##### Share on other sites
Quote:
 Original post by NotAYakkI'm a bit ... intimidated ... by the raw wall of text. Is this what the headings mean?

Yeah, that's a pretty good summary.

You missed the part about the subcommittees. The Evolution committee came up with core changes to the language, these and others are reviewed by the Core committee and will be adopted (or not) into the core language part of the standard.

There is also the Library committee, which reviews and adopts (or not) changes or additions to the library part of the standard. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2598.html

Then there is the C-compatibility committee, who try to make sure there is not too much deviation from the language changes adopted by the ISO C standards committee (many individuals are on both committees). Problem there is every time C++ tries to adopt new C features, the C committee seems to go out of their way to make C less compatible with C++. Committees, feh.

All of these committees work back-and-forth (and there is the committee of the whole as well). the preferred way to implement a new feature is in the library, not the language, if possible.

##### Share on other sites
Quote:
 Original post by NotAYakkLess wall-of-texty, anyone have a favourate feature they want to gush about?

I'm totally excited about closures! A new kind of undefined behavior awaits with all the referencing long-gone local variables kind of stuff :)

##### Share on other sites
Most of the things I like about C++0x are already in boost. Much of the rest is new complicated language features. Of the complaints levied against C++, "not enough complicated language features" is not in the top five.

##### Share on other sites
Quote:
 Original post by SneftelMost of the things I like about C++0x are already in boost. Much of the rest is new complicated language features. Of the complaints levied against C++, "not enough complicated language features" is not in the top five.

Well, in fairness, concepts is created with the intent of simplifying some of the template metaprogramming "tricks" used in the past. The intention is to make it less complicated, not more. I'm not sure it will work out that way, but at least the intention is there.

##### Share on other sites
Good intentions also created the export keyword, and we all know how well that worked out. About the only language change I'm interested in is rvalue references. Otherwise, the rest either seem unnecessary or not worth the complexity they add to the language. Maybe I'll change my mind once these features hit the mainstream, but I wouldn't place any bets on it.

##### Share on other sites
Quote:
 Original post by SiCraneGood intentions also created the export keyword, and we all know how well that worked out. About the only language change I'm interested in is rvalue references. Otherwise, the rest either seem unnecessary or not worth the complexity they add to the language. Maybe I'll change my mind once these features hit the mainstream, but I wouldn't place any bets on it.

I think the main issue with C++ is the ingrained mentality to not break backwards compatibility. Certainly a noble goal, but there's a lot of things in the language which really would be done differently if they were allowed to make such tweaks without concern for backwards compatibility. I say this, because I make the distinction in contrast to some other languages, which made, both, the sorts of improvements I'm talking about, as well as change for the sake of change (as I'm learning the more I play with Java, in particular).

That being said, I'm excited to see Concepts more than most of the other libraries. My main concern is that if I don't think 99% of C++ developers will use it, because as it is templates are above the head of the average developer. But my instincts tend to agree with yours; it's kind of interesting how a feature that is supposed to lower the bar for entry into using templates effectively might actually wind up making it even more difficult.

##### Share on other sites
Quote:
 Original post by SiCraneGood intentions also created the export keyword, and we all know how well that worked out. About the only language change I'm interested in is rvalue references. Otherwise, the rest either seem unnecessary or not worth the complexity they add to the language. Maybe I'll change my mind once these features hit the mainstream, but I wouldn't place any bets on it.

Also, regarding the export keyword, ... hey, I think export was a great idea. The only problem was with C++'s archaic linking model, it's a royal pain to implement. But, as far as a feature, export would've been great.

##### Share on other sites
the only things I'm really looking forward for is the strongly typed enums, and the auto keyword. I'm not really all the convinced on the new chars format. The unicode etc. But maybe my mind will change on that stuff.

But will those unicode chars and more be available also for C language also? I don't really care since I don't use it. But wouldn't that make it harder for adjustment to older libraries updating to it?

I haven't read all the new features. But I do enjoy the regex, array, and shared_ptr being added also.

I do wonder if it will probably be pushed back to 2010 since 2009 is coming awfully quick. Really haven't heard any knew updates. Waiting for GCC-4.4.0 to be released in a rc so I can see what will be in GCC-4.5.0

I'm not really that fond of the proposel for modules. It looks too weird looking and easily confusing.

I wish they would come up with an option to have like in C#

property double someFoo(){    get()    {    }    set(double& newValue)    {        this->oldValue = newValue;    }};

And initialize arrays like
static int[10] myArray; // C# way

[Edited by - Eckos on June 23, 2008 2:20:37 PM]

##### Share on other sites
Quote:
 Original post by RydinareI think the main issue with C++ is the ingrained mentality to not break backwards compatibility. Certainly a noble goal, but there's a lot of things in the language which really would be done differently if they were allowed to make such tweaks without concern for backwards compatibility.

Yeah. Hot spit, the one thing that would have made C++ a real success would be to remove the one thing that made C++ the success that all the "better C++" reinventions hope to one day become.

Seriously, the two best features of C++09 have got to be auto declarations and delegating constructors. Those two features I would likely use every day. Well, almost every day. You know what I mean.

##### Share on other sites
Quote:
 Original post by RydinareWell, in fairness, concepts is created with the intent of simplifying some of the template metaprogramming "tricks" used in the past. The intention is to make it less complicated, not more. I'm not sure it will work out that way, but at least the intention is there.

Hey, I agree. A language with built-in concepts avoids having to build in wordy, fragile, hackish concept checks. A language with built-in closures avoids boilerplate functor code. A language with move references avoids the difficulty of robust and efficient copy-on-write. All of these features promise to simplify programming, by simplifying specific tasks that are currently less than trivial. But the result of all these features being brought together is a language that is more complicated than ever. It's the result of a committee approach that avoids, or lacks the power for, more fundamental language reworking.

##### Share on other sites
Quote:
Original post by Bregma
Quote:
 Original post by RydinareI think the main issue with C++ is the ingrained mentality to not break backwards compatibility. Certainly a noble goal, but there's a lot of things in the language which really would be done differently if they were allowed to make such tweaks without concern for backwards compatibility.

Yeah. Hot spit, the one thing that would have made C++ a real success would be to remove the one thing that made C++ the success that all the "better C++" reinventions hope to one day become.

Well, let's be fair here. If you're talking about commercial marketability of the language, I agree with you. When you have legacy projects, you want as little work as possible to carry them forward into the new architectures; thus the backwards compatibility.

However, one of the main reasons why many C++ developers spend half their day bitching about C++ is because all of that ugly legacy code hasn't been wrapped in a nicer interface, as would be forced by a more strict compatibility layer with legacy modules and because developers continue to use older constructs which should be obsolete, but are still supported due to backwards compatibility. As I said, though, any change that is made should be made because that change would be a benefit going forward. No changes for the sake of change.

Quote:
 Original post by BregmaSeriously, the two best features of C++09 have got to be auto declarations and delegating constructors. Those two features I would likely use every day. Well, almost every day. You know what I mean.

Those two are definitely going to rock. There's a bunch of useful ones. My concern still will be whether or not, with coworkers still behind the C++98 standard, if they'll pick up any of the useful practices from C++09. I will say that of the people I've worked with, approximately 10% were aware of basic things like std::stringstreams.

##### Share on other sites
Quote:
Original post by Sneftel
Quote:
 Original post by RydinareWell, in fairness, concepts is created with the intent of simplifying some of the template metaprogramming "tricks" used in the past. The intention is to make it less complicated, not more. I'm not sure it will work out that way, but at least the intention is there.

Hey, I agree. A language with built-in concepts avoids having to build in wordy, fragile, hackish concept checks. A language with built-in closures avoids boilerplate functor code. A language with move references avoids the difficulty of robust and efficient copy-on-write. All of these features promise to simplify programming, by simplifying specific tasks that are currently less than trivial. But the result of all these features being brought together is a language that is more complicated than ever. It's the result of a committee approach that avoids, or lacks the power for, more fundamental language reworking.

I definitely agree. That part of it is very unfortunate. For one example, the fact that template methods and virtual don't mix still drives me batty. This restriction could be worked around if C++ changed a few other fundamental oddities.

##### Share on other sites
I do, with only minor reservations, really like auto types. Far too much of my young life has been squandered typing std::vector<int>::const_iterator. My slight worry is that such a broadly applicable feature is more likely than most of the other features to lead to buggy, surprising corner cases. We'll just have to wait and see.

##### Share on other sites
The new foreach is nice!

##### Share on other sites
Quote:
 Original post by RydinareAlso, regarding the export keyword, ... hey, I think export was a great idea. The only problem was with C++'s archaic linking model, it's a royal pain to implement. But, as far as a feature, export would've been great.

Maybe not as great as you would think.

I'm pretty excited about variadic templates in the new standard. Other than that, most of the cool "new" stuff is already available in some form or another thanks to boost. So, I'm kind of "meh" about 0x.

##### Share on other sites
Quote:
Original post by Driv3MeFar
Quote:
 Original post by RydinareAlso, regarding the export keyword, ... hey, I think export was a great idea. The only problem was with C++'s archaic linking model, it's a royal pain to implement. But, as far as a feature, export would've been great.

Maybe not as great as you would think.

I'm pretty excited about variadic templates in the new standard. Other than that, most of the cool "new" stuff is already available in some form or another thanks to boost. So, I'm kind of "meh" about 0x.

Well, again, export was highly problematic with C++ as it is currently is. Practicality aside, if some of the internal C++ assumptions, such as the backwards compatibility and the archaic linking model were non-issues, export would've been great. As it was, I agree export was a definite misstep.

##### Share on other sites
Quote:
 Original post by SneftelI do, with only minor reservations, really like auto types. Far too much of my young life has been squandered typing std::vector::const_iterator. My slight worry is that such a broadly applicable feature is more likely than most of the other features to lead to buggy, surprising corner cases. We'll just have to wait and see.
I'm also slightly concerned about the new use of auto.

It's true that only the tiniest bits of code will be broken, but it is still a potentially breaking change to existing code. Those always bother me.

Next, it also throws off the semantics of auto_ptr (although to be fair, they're depricating it). If "auto" stops referring to scope, then somebody not familiar with the history could assume that auto_ptr is a type-deduced smart pointer. Which it obviously isn't.

While the type deduction mechanism is nice in theory, it can be very easy to misunderstand what the system has deduced for the type. If you assume that an auto type is one thing, and you treat it as another, you quickly enter the realm of undefined behavior.

I'm afraid that the late binding of auto types, especially within complicated templates, is going to be a great source of bugs.

Threading support makes me happy, although I won't trust it for several years.

On the whole, I'm content with the additions. I probably won't move away from the Boost implementations for some time, mostly because I don't expect to see these in console game compilers any time soon.

##### Share on other sites
Quote:
 Original post by RydinarePracticality aside, if some of the internal C++ assumptions, such as the backwards compatibility and the archaic linking model were non-issues, export would've been great. As it was, I agree export was a definite misstep.

No, the way export was specified was broken in ways that had absolutely nothing to do with backward compatibility and the linking model.

##### Share on other sites
Quote:
 Original post by SiCraneGood intentions also created the export keyword, and we all know how well that worked out. About the only language change I'm interested in is rvalue references. Otherwise, the rest either seem unnecessary or not worth the complexity they add to the language. Maybe I'll change my mind once these features hit the mainstream, but I wouldn't place any bets on it.

template aliases?!
variadic templates (will speed up function<>, bind, etc compilation no end)?!
template aliases!?
inherited and delegating constructors?!
automatic virtual destructors (if at least one method is virtual)?

I think there's a lot of goodness in there. Many of the things in that list will reduce complexity and combat verbosity and needless scaffolding.

I'm on the fence about concepts. Sometimes I'll be writing some sticky template code and the need for them is obvious, but having another sub-language is worrying.

##### Share on other sites
Quote:
Original post by SiCrane
Quote:
 Original post by RydinarePracticality aside, if some of the internal C++ assumptions, such as the backwards compatibility and the archaic linking model were non-issues, export would've been great. As it was, I agree export was a definite misstep.

No, the way export was specified was broken in ways that had absolutely nothing to do with backward compatibility and the linking model.

Well, I think we're going in circles. What I'm trying to say (and apparently failing at) is that export would've likely been specified differently if they could've done it fresh and in that case, it may have succeeded. Or, even moreso, an export keyword may have never been necessary.

##### Share on other sites
Quote:
 Original post by the_eddtemplate aliases?!

Unnecessary, not to mention given stupid syntax.
Quote:

By definition unnecessary and I'm not convinced that the way that they're currently specified will be problem free.
Quote:
 variadic templates (will speed up function<>, bind, etc compilation no end)?!

It will, in theory, speed up compilation for those libraries. However, until you've got a working C++09 compiler, you can't actually make a definitive statement that the compile will be faster. Integrating of new language features will increase compiler complexity and more complex compilers tend to be slower. Furthermore, the unpacking mechanism leads to increased number of instantiated templates which then means that the optimizer and linker have more work to do. Parsing might be faster, but you've simply pushed work off to the backend.

In any case, I'm currently unconvinced that the feature will be applicable to enough situations to warrant the addition to the language given the weakness of the unpacking notion. It seems that you'll largely be trading using boost::preprocessor for specifying your variadic templates for writing obtuse recursive definitions. For simple forwarding issues variadic templates might be nice, but when you try to actually do something with the arguments then you've got issues.
Quote:
 inherited and delegating constructors?!

Not worth the chaos they generate with respect to the notion of a fully constructed object.
Quote:

Meh.
Quote:
 automatic virtual destructors (if at least one method is virtual)?

Ok. I'll add this one to my list.

##### Share on other sites
Quote:
 Original post by RydinareWell, I think we're going in circles. What I'm trying to say (and apparently failing at) is that export would've likely been specified differently if they could've done it fresh and in that case, it may have succeeded. Or, even moreso, an export keyword may have never been necessary.

Ok, how would you keep the semantics of C++ templates and avoid the problems for separate compilation of templates mentioned in the Sutter article either with or without the export keyword? Feel free to change whatever you like about the classic linkage model so long as the end product of a program build contains a classic executable.

##### Share on other sites
Quote:
Original post by SiCrane
Quote:
Meh.
Meh??
I'd say that moving multi-core development out of the "Works on my machine" land (i.e. undefined behaviour) is long overdue (even if it *does* already work on my machine, it should be well defined in the standard ;))

##### Share on other sites
Quote:
Original post by Hodgman
Quote:
Original post by SiCrane
Quote:
Meh.
Meh??
I'd say that moving multi-core development out of the "Works on my machine" land (i.e. undefined behaviour) is long overdue (even if it *does* already work on my machine, it should be well defined in the standard ;))

Seconded. Proper language support for threads is sorely needed and long, looooong overdue. Sure, right now we can use boost or OpenMP or whatever, but it'll be darn nice not having to recompile those libraries when they release new versions just because I want some threading.

##### Share on other sites

This topic is 3455 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628638
• Total Posts
2983970

• 10
• 18
• 20
• 13
• 9