Where will Evolution lead C++17?(meetingcpp.com)
meetingcpp.com
Where will Evolution lead C++17?
http://meetingcpp.com/index.php/br/items/where-will-evolution-lead-cpp17.html
8 comments
2008? There never was a C++08...
Last Standard was 2003 before C++11.
Last Standard was 2003 before C++11.
You're right, sorry I got mixed up between 2003 and Visual Studio 2008 which is the IDE I used frequently back then.
I've been writing c++ on and off since Visual Studio 6. I would be glad to see it move faster. I don't have to learn all esoteric things - I can pick and use parts which I like, such as auto, for-each, smartptr, lambdas and so on. There was a version 2003 and then C++11. Almost a decade later. How can that possibly be too fast?
I thought maybe you're thinking of TR1 (2007). I think VS2008 was the first one with support for that. It was kind of a preview of what was to come in C++11 back when it was popularly called C++0x.
Named arguments would be lovely. It's quite exciting to C++ adopting all sorts of modern conveniences relatively quickly, after a decade or more of stagnation.
I like the unified call syntax proposals. The one that has the potential to go bad quickly is operator. which I forsee being used to create some painfully obfuscated code.
Imho the problem with C++ is that it has gained too much weight over the years. I think that other languages, for instance "Rust", will eventually fix everything that C++ is forced to do wrong (due to its legacy), and these new languages will become more and more attractive to use as a development language.
Some things I personally hope will be added to C++ and/or Rust:
- coroutines
- lightweight threads
- garbage collection (for high-level stuff)
- a natural form of metaprogramming (not the convoluted approach taken by the boost libraries), i.e., active libraries that generate code based on given parameters
- pure, lazy functional programming (language subset), e.g. for concurrent stuff
- pattern matching
Some things I personally hope will be added to C++ and/or Rust:
- coroutines
- lightweight threads
- garbage collection (for high-level stuff)
- a natural form of metaprogramming (not the convoluted approach taken by the boost libraries), i.e., active libraries that generate code based on given parameters
- pure, lazy functional programming (language subset), e.g. for concurrent stuff
- pattern matching
> the problem with C++ is that it has gained too much weight over the years.
> Some things I personally hope will be added to C++
... and therein lies the problem with language design ;)
> Some things I personally hope will be added to C++
... and therein lies the problem with language design ;)
The basic suggestion is to define x.f(y) and f(x,y) to be equivalent
Am I the only one who thinks this is terrible from a semantic point of view?
Am I the only one who thinks this is terrible from a semantic point of view?
That does seem terrible. Right now those two things are, semantically, completely different.
Except for operator overloading, where they are weirdly sometimes the same. Also, the semantics of Koenig (aka, "argument dependent") lookup really play into the matter, as they are effectively similar to member functions. As someone who has been writing C++ now since 1996, I will say that this change feels entirely natural and even "satisfying".
What I dislike about most of these proposals is that they make C++ even harder to parse. It's important that tools other than full compilers be able to make sense of program text.
> It's important that tools other than full compilers be able to make sense of program text.
Depends. Qt Creator now embeds Clang itself to do just that. Visual Studio is basically the same philosophically.
Depends. Qt Creator now embeds Clang itself to do just that. Visual Studio is basically the same philosophically.
To the same place it will lead C++. A dead end.
Another round from the C++ committee. More features, not more safety. That crowd just doesn't get it.
About a decade ago, I suggested to the C++ committee that their avoidance of dealing with the memory safety issues in C++ constituted material support of terrorism. They were sufficiently worried to delete that posting from their USENET feed. So, a decade later, C++ has as many buffer overflows as ever.
About a decade ago, I suggested to the C++ committee that their avoidance of dealing with the memory safety issues in C++ constituted material support of terrorism. They were sufficiently worried to delete that posting from their USENET feed. So, a decade later, C++ has as many buffer overflows as ever.
However, in my opinion C++ is changing too much, too quickly. I barely got the changes from 2008 down pat, and I look up and not only have I missed the 2011 changes, but also the 2014 changes to digest. It's going too far too fast and it feels like C++ steering committee is filled with ultra-experts that don't understand that the young kids aren't picking up C++ because Python, Java, Scala, etc are more digestible, and the older people like me who love C++ aren't able to keep up with all these changes because we aren't at the cutting edge and don't need most of this esoteric functionality they are adding.
It feels like a runaway train and if there's a few more iterations I'm going to have to give up trying to catch up because at that point it's easier to just spend my time becoming an expert in another language like Java or Scala. To mix another metaphor, it feels like the steering committee is outpacing it's supply line of users and in 2-3 more iterations, there will be such a wide swath of functionslity that it will be a complete mess because there will be too much fragmentation of the language over a relatively short time period.