Sign in to follow this  

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.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Quote:
Original post by NotAYakk
I'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 this post


Link to post
Share on other sites
Quote:
Original post by NotAYakk
Less 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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
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.


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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
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.


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 this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
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.


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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Rydinare
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.

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 this post


Link to post
Share on other sites
Quote:
Original post by Rydinare
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.

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 this post


Link to post
Share on other sites
Quote:
Original post by Bregma
Quote:
Original post by Rydinare
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.

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 Bregma
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.


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 this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Quote:
Original post by Rydinare
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.

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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Rydinare
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.


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 this post


Link to post
Share on other sites
Quote:
Original post by Driv3MeFar
Quote:
Original post by Rydinare
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.


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 this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
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.
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 this post


Link to post
Share on other sites
Quote:
Original post by Rydinare
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.

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

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
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.


template aliases?!
overloading of "auto" keyword for type inference?!
variadic templates (will speed up function<>, bind, etc compilation no end)?!
template aliases!?
inherited and delegating constructors?!
memory model for threads!?
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 this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Quote:
Original post by Rydinare
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.

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 this post


Link to post
Share on other sites
Quote:
Original post by the_edd
template aliases?!

Unnecessary, not to mention given stupid syntax.
Quote:

overloading of "auto" keyword for type inference?!

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:

memory model for threads!?

Meh.
Quote:

automatic virtual destructors (if at least one method is virtual)?

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

Share this post


Link to post
Share on other sites
Quote:
Original post by Rydinare
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.

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 this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Quote:
memory model for threads!?
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 this post


Link to post
Share on other sites
Quote:
Original post by Hodgman
Quote:
Original post by SiCrane
Quote:
memory model for threads!?
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 this post


Link to post
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.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this