Slashdot Mirror
Stroustrup Says New C++ Standard Delayed Until 2010 Or Later
wandazulu writes "At the end of an article written by the creator of C++, where he talks about removing a feature from the new C++ standard, he drops a bombshell: The new C++ standard (typically referred to as C++0x) has been delayed until 2010 or later. What does this mean? No new C++ features like threads, proper enum classes, or hash tables. C++0x is dead, long live C++1x!"
First!
http://firefoxhtml5test.webs.com/
C++0x
Yes, well, that just rolls off the tongue, doesn't it?
Maybe he can get one of those hieroglyphs like Prince.
But I can assure you it's better than Cloud Computing with JavaScript :)
A crowbar which can be used to whack anyone who writes programs in C or C++ which take untrusted input (like, oh, web browsers, word processors, PDF readers, etc etc etc etc etc) until they give up and use a language that is typesafe and memory safe.
Test your net with Netalyzr
Or C++0x0A no need to change the name.
for(std::vector::iterator i = Jews.begin(); i != Jews.end(); i = Jews.begin())
{
(*i)->PutInOven();
delete (*i);
Jews.erase(i);
}
That's the problem with standardization committees.... Too slow. While all this happens all other proprietary languages like Delphi, C#, you name it, are adding features day after day to make life easy for the programmer. And that , believe me or not, means a lot. Yes, sometimes that means a lot more that portability and all that jazz.
It's time to realise that Abble's products are the biggest abomination these days. Just say NO to the dumb iAbble way!!
"C++0x... Yes, well, that just rolls off the tongue, doesn't it?"
Well, it does if you just pronounce it "Cocks".
It's not a bombshell by a long measure. Anyone who had been tracking C++0x standardization process (reading comp.std.c++, and WG papers) knows that the goal of getting the standard out by 2010 was fairly unrealistic, mostly because of concepts. The joke that "x" in C++0x is actually a hex digit and not decimal has been around for several years now.
The latest version of Cobol (eagerly expected by 6 people) will also be delayed till January 2011.
"No new C++ features like threads, proper enum classes, or hash tables"
"Concepts" is the only thing being removed from the new standard due to time constraints (which is a shame since they seemed like a great new feature).
I think you meant to say 'No new C++ features .... _until next year at the earliest_'
Of course if you want to try some of the new features in the meantime feel free to checkout the expiremental branch of gcc geared towards implementing C++0x.
The headline completely misses the central part of the article and focuses on a very minor point. Everyone has known for quite a while that C++0x would actually be C++1x. There's only a few months left in 2009, so there's absolutely no surprise there. The real meat of the article is that support for "concepts", a key (and arguably the most anticipated) part of C++0x, is being dropped. That's a major disappointment to many people, including Stroustrup.
Why the #$%! do computer scientists believe that languages are like movies and you need to release a sequel? There is nothing they can add to any language that cannot be done effectively with C and C++ with a good support library like BOOST and STL. Language-specidic Threads? Enum classes? Hash tables? All of those are ALREADY possible without another language being introduced.
The purpose of new languages? To sell books. To sell compilers. To keep academics publishing about their new inventions. But lets face it, we have enough languages now. If you can't accomplish what you want to do in a relatively short time with the options that are now available, the problem isn't the language.
Don't f*&($(&^) with my code standard.
remove your helmet and tell me your name
There will be buffer overflow after C++0xFF
the standards body has very specific steps that it needs to go through for approval of the standard, with defined notification, voting, etc time windows. mid 2008 it was already clear that it was impossible to follow these rules and get final approval by the end of 2009, even if you assume that nobody has _any_ changes or corrections to anything
David Lang
C++ concepts were effectively the same as Haskell typeclasses - an extremely powerful feature that allows for fully and properly typechecked (unlike present-day C++ templates, which are "typechecked" in essentially the same way macros are) abstraction and code reuse in a statically typed language. Removing them significantly reduces the power of the language, and effectively makes C++ a minor evolution of the language (most notable new features are now probably rvalue references and lambdas), and leaves templates as broken as they are today. It's too bad. I'd rather see the standard delayed even more, but done properly.
Even if they were not preemptive on the MAC in 1996, it would still work if you cared to call Thread.yield() once in a while.
Hashtable and Enumeration were there in 1996 as well. All newer versions of Java provide backward compatibility for the 1996 version of these classes. Code written in 1996 still runs fine.
Don't get me wrong, I like assembly, C and bash, I am just stating a fact.
No new C++ features like threads, proper enum classes, or hash tables
Cause one thing C++ sure doesn't have is enough features, right?
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
I did not RTFA but is there anything new in here? I learned that C++0x was being renamed to C++1x and would not be out untill 2010 a while ago. I think over half a year ago when I was visiting the IRC channels.
I haven't been following C++0x, but after reading the C++0x FAQ I am very pleased. It really fills a lot of the simple, practical holes in the language.
I think the success of C# is part of why these things are being considered. For example, C# recently added an advanced form of initializer lists - which is now in C++0x. Another example is the scoping of enums, which has long been a pain. Many coding standards require enums to be ALL_CAPS_WITH_UNDER_SCORES because they don't obey scoping rules: this is fixed. NULL is now replaced with nullptr, which is a minor improvement that looks much like how this was done in C++/CLI. (That's the bastardized C++ for .NET). Namespace cleanups, foreach, ... the list is huge, and it looks like C++ is "borrowing back" from Java and C#.
Competition is good.
I know that everything I just listed probably exists in many other languages, but C# and Java are very prominent in enterprise development, and are making huge gains. I will be very very glad to see a real ISO standard gaining ground again.
C++0x is a goofy name no wonder no one wants to work hard on it. How would you like that on your resume. C+=2 is much more consistent with the language and is much easier to read.
C++ has reached staggering complexity already; I don't think adding another 40 pages of complicated features is going to make the language any better.
What does this mean? No new C++ features like threads, proper enum classes, or hash tables.
As far as I understand, concepts have been "decoupled" from this standard, but not threads, proper enum classes, or hash tables.
I've been following C++0x for a long time now, and have been looking forward to it, but now I'm not so sure I'll ever use it. I was looking forward to Concepts more than anything and with that gone, it seems like a extremely minor upgrade. Also, even when the spec does come out, how many years before we can trust that most compilers can use it effectively... two, three? Then after we've been using it for a while, how long before books come out that tell us that we've been using it all wrong and we have to start over (ie: the Exceptional " " and Effective " " books from Sutter and Meyers)?
Okay, so I can use C++0x well in 10 years, okay I'll probably be so burned out by then I'll be a manager, or I will have convinced someone to let us use D for embedded work and something managed for everything else.
"We need a fourth law of Robotics: Stop Fingering My Wife"
Sorry, I meant to say that without a final C++ standard, we wouldn't have these features in a standard commercial compiler; I didn't mean to imply that they had been removed from the standard itself.
On the whole, I'd rather code in Ratfor.
"Do you really want to hold back all the other very important features like lambda, rvalue references, variadic templates, type deduction etc. just because of concepts?"
Unfortunately, without concepts, many of the templates that would make features like those REALLY powerful aren't implementable due to silly things like the compiler insisting upon being able to instantiate member functions that don't make sense for a class and won't be used, just because there isn't a means to tell the compiler "and if this member doesn't make sense, just don't instantiate it, and throw an error IF AND ONLY IF somebody tries to use it." (and yes, I know about SFINAE, but that gets REALLY UGLY to do).
I've been bit by this, where I ended up having to create two completely separate template classes, one for objects that don't have sub-members and one for objects that do, just because I couldn't tell the compiler "Look, if operator . doesn't exist for this method, then don't worry about it!"
That said: I will say, I felt that some of the implementation details of concepts felt "forced" to me, in the same way that the streams library feels "forced": they "hacked" (in the bad way) the library in using language semantics that weren't a good fit.
<sigh/> - I hope the extra time will allow them to put a bit more polish on how you actually express things, and make it feel less "forced"....
www.eFax.com are spammers
C++ can't be fixed by adding features.
C++ can only be fixed by removing features.
My minivan won't get me to Jamaica, so I need to add wings or pontoons? Or maybe I should buy an airline ticket instead?
Use the right tool for the job. Sticking another bag on the side of a language that's almost entirely bags isn't going to fix it. If you need a better language than C++, maybe you shouldn't be using C++.
They can't release a new standard until they figure out a way to keep the language from collapsing under its own weight, forming a black hole that would destroy the solar system.
That is all.
If you think C++ is staggeringly complex, you're probably not in a position to evaluate whether another 40 pages of complicated features is going to make the language any better.
Can we get a "-1 Wrong" moderation option?
Well, most of the things are already supported by compilers, or will be soon. (Se forexample http://gcc.gnu.org/gcc-4.5/cxx0x_status.html for the list of that gcc 4.5 (The newest released gcc version) supports. So it is likely that c++0x will be supported almost fully, within a year of release.
(Microsoft and intel have also implemented much of the standard).
The only thing I miss from the gcc is an implementation of "Lambda expressions" and they are working on those. (They have a branch which afair kinda works :}
Speaking as someone who was writing C++ for 4-5 years *before* ANSI came up with the original spec, that's not really the part I'm worried about. Judging by past experience, everyone except Microsoft will probably come up with a "good enough" compiler relatively quickly, and there will be a series of #defines that will allow one to simulate compliance on Microsoft compilers.
E pluribus unum
Some years ago, the C++ committee went off into template la-la land. Most of the work there focuses on template features that will be used by few, and used correctly by fewer.
Templates are useful, but "generic programming", doing arbitrary computation at compile time with templates, was a terrible idea. Templates can be abused as a recursive term-rewriting system, and through some clever and obscure tricks, recursive computations can be run at compile time. As a programming language, this trick is awful; awful from a syntax point of view, awful from an understandability point of view, and awful from a debugging point of view. If you need to do work at compile time, there have been much better approaches. LISP "macros" were standard LISP, not a second language. And even they created such a mess that Scheme had to be invented to clean out the language.
Orignally, templates were conceived as a saner way to do what C programmers did with macros, providing a way to have some type independence at compile time. But the template crowd got out of control.
The obsession with templates has led to a neglect of things C++ really needed, like better memory safety (C++ still has buffer overflows, and most of the security holes today stem from this), and better approaches to concurrency (the compiler has no idea what locks what, and it needs to know). Anything that wasn't template-related tended to be ignored by the committee.
The result of this failure has been C++ spinoffs - Java, C#, etc. Even Objective C has made a comeback in the Apple world. C++ has never even been able to displace C, twenty years on.
I've written a lot of C++, and I'm disgusted with this mess.
I've been following C++0x for a long time now, and have been looking forward to it, but now I'm not so sure I'll ever use it. I was looking forward to Concepts more than anything and with that gone, it seems like a extremely minor upgrade.
I would disagree on this part. I'm already using some C++0x features actively in production code, and I can say that they are well worth it. Lambdas are extremely handy as they finally let you use STL (and Boost) algorithms properly without lots of unneeded hand-waving. This may sound a minor thing, but remember how things have changed in C# world when anonymous delegates were introduced in C# 2.0, and their syntax simplified in 3.0? All of a sudden, everyone shifted to functional ("LINQ") techniques of writing code, abandoning hand-coded loops. The same thing happens here.
The second big part is rvalue references. They really do give major performance benefits for STL containers, especially of user-defined types (as smart implementations of C++03 already optimize their containers for standard types to avoid copy by using swap instead - but they can only legally do it for types they control...).
One other thing. C++0x may take a while to be released, but you'll see quite a few of its features in production-quality compilers before the spec is finalized. I've already pointed out that some are in VC++2010. There's even more in newer g++ versions (IIRC, they implement all that stuff, and also variadic templates). I've also seen mention of rvalue references and lambdas in the feature list of the most recent C++Builder release. All in all, this means that you'll have them at your disposal within a year or so one way or another.
The people who go on and on about pointers are usually the same ones who don't understand the std, or any of the new standards. Or even basic OOP concepts. These are the guys I refer to as "resume-only" C++ programmers.
Stroustrup sounds like a strain of strep causing croup, now you're talking about open STD and cocks... That's enough to make even a man with a snake phobia embrace Python instead of C++...
The key word is "can". Nobody's forcing you to abuse them.
I agree with the guy above though: C++ needs templates because it needs things like std::vector, std::string and smart pointers. The problems appear when "creative" people get hold of them.
No sig today...
The language that eventually became Fortran 90 was known as Fortran 8x during its development period.
Given that its now the latter half of 2009, the chances of C++ 0x actually having x==9 have been vanishingly small for quite a long time already.
Squirrel!
Just because one can understand memory allocations and pointers doesn't mean one wants to have to deal with them manually in all their programs.
Then use a framework, like Qt, that deals with all of that for you.
I write graphics software, and C++ allows me to write very efficient, flexible, and maintainable code that runs on a variety of architectures. Just because you don't need to mess around with pointers, that doesn't mean everyone doesn't need to.
We're already going through the same scenario as OpenGL 3.0 - lots of years spent on essentially a bare minimum of changes which in the end pissed off and disappointed practically everyone. Another coincidence, C++ is the primary language of OpenGL.
Any topic that involves geeks and C++ is just asking for flame wars, I'll submit my name to the mix.
Although I've been coding in c++ for more years than half of you have been alive, and am rather biased, I feel good programmers write good code independent of the language they use.
Hi, I Boris. Hear fix bear, yes?
Or, lack of a proper lambda.
I think \bigger problems
Is that backslash some kind of Haskell joke?
I was looking forward to a language called "cocks", to bring some fresh air to the old flamewars...
--
Stay tuned for some shock and awe coming right up after this messages!
C++0x adds syntactic sugar, no more.
I'm actually relieved to see concepts dropped, that was probably the biggest useless sugar ever (axioms were not just sugar, but they were the part less ready for inclusion anyway). Everything concepts can do can already be done in C++03 with SFINAE with expressions (which, thankfully, was required explicitly in C++0x unlike C++03 which is quite vague on that topic).
Lambdas are monomorphic, thus useless. Even a DSEL can do better. Worse, even MACROS can do better (since there is no stupid limit on templates being declared at file scope anymore).
Rvalue references is just broken magic; relying on NRVO works just fine to implement move semantics and is not as senseless.
The only real update that comes with C++0x is fixing the standard library so that it doesn't require stuff it doesn't need. Nothing developers haven't already solved by implementing their alternative to the standard library.
Yet, C++ remains the most awesome language ever.
Too bad the committee isn't working on actually useful additions, such as virtual templates, which would allow it to compete with dynamic typed languages such as Python.
" how many years before we can trust that most compilers can use it effectively... two, three?"
FYI, you can use a lot of it already http://gcc.gnu.org/projects/cxx0x.html
It's a fair bet that by the time it's signed off most of it will be available in gcc and you'll have an 'effective' implementation.
How quickly your shop upgrades compilers is a different problem.
i wish i could stop
I don't know why people continue to self flagellate themselves on C++.
Every time I try to start using some other language, it fails. Mostly because other languages do not provide necessary tools to build correct programs.
1) java failed to support variables in stack, and the whole VM/GC thing is horrible.
2) haskell failed in supporting for-loops (MapM_ is not exactly the same thing)
3) erlang failed when it made it too difficult to use existing libraries made with some other language
4) python failed when it's performance is not very good
5) C# failed because it's from microsoft
6) C failed because of it's lack of support for abstractions
So I keep coming back to c++ every time. It provides combination of performance, low level programming, high level programming, good abstractions, rich tools to build your programs, proper tools for debugging your programs, plenty of libraries available, caveats are well known and workarounds exists, and it keeps working year after year without any compability problems in all supported environments.
C++0x dropping concepts is a big news. This is because c++ is important. It also means that the concepts proposal was not good enough. Only the best proposals will survive. If concepts needs to go, then they go. C++ is too important to get ruin by proposals that do not work or leads programmers to deadends. Concepts looked like a fine proposal at first, but seems it was still not good enough.
This might make other languages think they're progressing faster and providing new features faster. The other languages are still struggling to provide even basic support for things that programmers need. It's not the new features that the languages provide that determines if the language is useful. It's what the language fails to provide that counts. If there are big gaps in it's support, the tool is just unusable for use.
Parent is not a troll. Please fix. If you don't agree with him, the proper thing to do is argue with him, not moderate him.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
See subject because it's stupid little shits like you that know squat about this field that ought to get a good punch in the jaw to knock you the fuck out.
here's an example of why we need an "auto":
template <typename parent_type, typename query_type>
struct recursive_query
{
typedef recursive_query<parent_type, query_type> this_type;
template<typename query_type>
recursive_query<this_type, query_type> operator[](query_type q);
};
struct query_base
{
template<typename query_type>
recursive_query<query_base, query_type> operator()(query_type q);
};
recursive_query<recursive_query<recursive_query<recursive_query<query_base, const char *>, int>, std::list<int> >, float> result =
// or would you rather write:
recursive_query<query_base>["foo"][5][my_list_of_ints][4.2];
auto result = recursive_query<query_base>["foo"][5][my_list_of_ints][4.2];
if you don't understand why you might need a recursive type like that, learn more about metaprogramming! it's the bee's knees!
The advantages of C and C++ have always been the speed of execution, and it's ability to get really close to the hardware. The problem now is that the speed of execution advantage is fading. Interpreted byte code languages like Java and C# are getting faster and faster, and they byte code has always made them more portable. Add to that that the extra complexity of C++ is often unnecessary, and you start reaching a point where more and more applications which would once have been written in C++ are now being written in C# or Java, this trend is only likely to continue with more and more applications moving onto the web, and continued improvements in the byte code languages themselves.
There is certainly still a need for C and C++, they are really the only viable languages for writing device drivers and certain core OS components, not to mention all the interpreters necessary for running all these byte code languages. The problem, as I see it, and I'm by no means an expert, is that C++ is continually trying to compete with languages like Java, which it will never be able to functionally do without giving up all of the things which make it powerful and which java can't do. Java is powerful because you don't have to worry about all the things you don't really care about, and C++ is powerful because when you do need to care about them you have the level of control you need(C# tried to allow both, but it doesn't really work that way). The more libraries and features you add to C++ to make it like java, the more complex and bloated you make it, and you're still chasing an unachievable goal because you can't make C++ into Java and you wouldn't really want to.
I'm not sure why the language is going in this direction, but it seems to me better to use C and C++ where they're appropriate and use Java/C# where they're appropriate and to stop trying to create some jack of all trades language which can't exist.
son of C and an impure virtual function.
Now you get 2, 2, 2 languages for the price of 1.
N' delay pas. Acheter now!
Please please let it die.
Can't we use a decent 21st century language
with embedded D or something for the
bare metal access sections.
Where are we going and why are we in a handbasket?
When so-called "software standards" include real Engineering testing and certification by third parties, civil liability for bad software that causes serious fiscal losses including lost time spent deploying bad software, and real repercussions for code monkeys that don't FOLLOW the standards, wake me up. Yawn.
+++OK ATH
VC2010 already supports a C++0x subset - see http://blogs.msdn.com/vcblog/archive/2008/10/28/visual-studio-2010-ctp-released.aspx
Who gives a shit. They lost me when they first announced C++0x
C++ was a great old language (sometimes, when the moons were aligned), but I've moved on. They needn't bother trying to patch up a patch up for an old obsolete language (and I do apologize to C fans.. I know I'm being harsh). Opinion, sure, but you gotta admit, we don't need a patched up C++.
A little, er. persuasion is in order here. Committees are what they are, but add some heat and they'll GET TO WORK and so can we.
I've been following C++0x for a long time now, and have been looking forward to it, but now I'm not so sure I'll ever use it. I was looking forward to Concepts more than anything and with that gone, it seems like a extremely minor upgrade. Also, even when the spec does come out, how many years before we can trust that most compilers can use it effectively... two, three?
http://gcc.gnu.org/gcc-4.5/cxx0x_status.html
It's not that bad. Many of the simple, neat features (like auto typing and initializer lists) are available already. Also, many of the library improvements are just standardizations of existing libraries, so it won't take that long for implementations to catch up. The main reason for all this is that one of the criteria for inclusion of a feature into the standard was the existance of an implementation. And this is why concepts were dropped. There is the conceptGCC implementation, but several people were not satisfied with the design of concepts that conceptGCC implements. If the decision was made to change that design, concepts were not standard-ready anymore (no existing implementation).
Since C++ is a super set of C by definition, your suggestion that it is a totally different language is clearly wrong.
As for, 'If you're Doing It Right then it's impossible to get a "buffer overflow"'. That's like saying if you don't make a mistake there won't be any mistakes.
I suggest you take time out to reflect.
You don't need to use [arrays] in C. Roll your own if you need that extra 'BASIC'ness to your lists. Don't be a rookie and complain about things over which you have total control. ROOKIE !! And if you can't do that, use C++, a computer language in which you will never be, master, only, student.
RValue references do not give any major performance benefits - it's the move operation that gives the performance benefit. RValue references can be emulated by templates in the current version of the language. RValue references is a notation for making move semantics available to the compiler. Move semantics are not magically supported. You still have to code the move constructor and the move assignment operator.
Moving data around is a dangerous practice. Auto_ptr was considered bad exactly because of this - you don't know where your data may end up to. Moving data means more destructive updating. Modern programming language theory is slowly moving away from destructive updating, as it is much easier to do better optimizations when things are not allowed to be destructively updated. I expect that there would be a lot of problems in production code from this, when non-const variables will be passed to functions that reset the variables to their initial state; it would be the auto_ptr fiasco all over again.
Actually, this is part of a bigger shift in the C++ development community. From now on, a new C++ core edition will be released each year, with names in the format "C++ ". C++ 2010 (or C10 for short) will also contain a major overhaul of the C++ rules, intended to make it so that user's guesses about how the language works will most likely be correct. Here are some of them:
- The long and short keywords are now #defined as static. This fixes issues with respect to variables using these keywords going out of scope before all functions using them have resolved. It also keeps them from being used more than once for the same variable.
- Some of the terminology is changed. "to declare" is replaced with "to put on the battlefield"; "to free" is replaced with "to send to the exile" (or "to exile" for short). This is to make the language less confusing for new users. Also, functions are no longer "called" but "evoked", bringing back some terminology from the early days of the franchise.
- Local variables will no longer be exiled when a block ends. This mechanic has frustrated many new users (as almost nobody can tell without looking it up where a block begins or ends) and thus the developers have removed it. They are aware that this breaks some peoples' coding styles but really think it improves the language.
- Local variables no longer use the stack. The developers felt that putting local variables on the stack could create unintuitive situations and thus moved them to the heap.
All in all C10 will be the best version of C++ ever. Prerelease events will be held shortly.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
I think this gets into where people abuse headers. I NEVER put code into header files (unless it's maybe a small macro which will get in-lined by the compiler for performance reasons). Headers get things like function and class definitions - which aren't code, they're just information for the compiler to use at compile time. Also, symbolic constants (e.g. #define RED 0xFF0000).
I've not done much with Templates (I've not done much C++ coding in the past few years since I took some classes on it in college), maybe you'd put a template into a header, but again, that's something for the compiler to use at compile time, not code, IIRC?
What else would you be putting in the header? How does that duplicate code? By writing a header file once and including it in other files, aren't you *reducing* duplication?
different people mention just yet one more feature that would make C++ compete with alternatives.
I feel that that feature is Reflection
(introspection) -- ability to find at runtime
for each class
methods names, arguments names and argument types to those methods, data type
and platform independent serialization (both are related).
This would give C++ ability to have Strong database access library (ORM),
session management for stateless operations (via serialization)
and therefore would allow creation of C++ web frameworks that have built-in ORM, session management, etc
languag
It's hopelessly outdated and crufty, but it will never go away because it's too big to die. Good thing that at least it's not evolving anytime soon, so people might start to look around for simpler, safer and more powerful languages to replace it. There are plenty.
RValue references do not give any major performance benefits - it's the move operation that gives the performance benefit. RValue references can be emulated by templates in the current version of the language. RValue references is a notation for making move semantics available to the compiler. Move semantics are not magically supported. You still have to code the move constructor and the move assignment operator.
I know about the rest of it (though obviously move constructor is enabled by rvalue references). But can you clarify the bit about "emulated by templates in the current version of the language"? I recall there being a few hacks, but wasn't they far from universal?
Moving data around is a dangerous practice. Auto_ptr was considered bad exactly because of this - you don't know where your data may end up to.
auto_ptr is dangerous not because it moves data, but because it does that in operations which have copy semantics for all other types - i.e. copy constructor, and operator=. In other words, it moved data regardless of whether it is safe or not. Rvalue references let one constrain move semantics such that it only gets applied when it is safe to do so.
I expect that there would be a lot of problems in production code from this, when non-const variables will be passed to functions that reset the variables to their initial state; it would be the auto_ptr fiasco all over again.
Non-const variables (and, in general, lvalues) don't bind to rvalue references, by design. So you won't get anything quietly moved from a variable, only from a temporary - that's why there's std::move added to allow you to explicitly request move-from-lvalue.
I'll even let you start over and not keep backwards compatibility with old code.
Then I'd start over and not keep compatibility with C. Maybe use a Smalltalk-like syntax and encourage reflection. Dynamic typing and binding by default, maybe even relegate static typing to optimization with assertions. ... ... ellipses ... more ellipses ...
I have switched to C++ exactly because overloaded operators allowed me to program transformation in parametric domain (think Fourier) in a natural way, like C = B*A.
And that's better than (set 'C (* B A)) why?
I've worked out the problem you guys (possibly girls too) all seem to have. You seem to think the purpose of the C++ committee is to, generally speaking, improve the C++ language. Given their conduct to date, I fail to see how you could arrive at such a conclusion. However, I will clarify the situation so that further confusion can be avoided.
The purpose of the C++ committee is to guarantee that C++ IN NO WAY interferes with the popularity of C.
Some of you will think I'm joking whereas the rest will know that I speak the truth. :(
My parrot changed sex today. That's not a joke. We always thought it was a male, and it also had the male colored beak. This morning... It had changed color entirely from blue to brown. It's a female now, and deeply fallen in love with an other parrot.
William Selden, Gertrude Tierney, Howard Bromberg, Howard Discount, Vernon Reeves and Jean E. Sammet.