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.

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.

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.

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.

The new foreach is nice!

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.

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.

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.

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.