5 ms·

Where will Evolution lead C++17?

35 points by meetingcpp 12y ago

read 12y ago
To the same place it will lead C++. A dead end.
etimberg 12y ago
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.
Maken 12y ago
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?
- wyager 12y ago
  That does seem terrible. Right now those two things are, semantically, completely different.
  - saurik 12y ago
    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".
TillE 12y ago
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.
quotemstr 12y ago
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.
- nly 12y ago
  > 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.
steven2012 12y ago
Let me state for the record that Change is Good. C++ changing with the times is really what is keeping it alive as opposed to the other legacy type languages that have stagnated. 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.
- meetingcpp 12y ago
  2008? There never was a C++08... Last Standard was 2003 before C++11.
  - steven2012 12y ago
    You're right, sorry I got mixed up between 2003 and Visual Studio 2008 which is the IDE I used frequently back then.
    - ohyesyodo 12y ago
      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?
    - 12y ago
Animats 12y ago
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.
amelius 12y ago
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
- nly 12y ago
  > 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 ;)

35 points by meetingcpp 12y ago

read 12y ago

To the same place it will lead C++. A dead end.

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.

Maken 12y ago

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?

wyager 12y ago
That does seem terrible. Right now those two things are, semantically, completely different.
- saurik 12y ago
  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".

TillE 12y ago

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.

quotemstr 12y ago

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.

nly 12y ago
> 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.

steven2012 12y ago

Let me state for the record that Change is Good. C++ changing with the times is really what is keeping it alive as opposed to the other legacy type languages that have stagnated. 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.

meetingcpp 12y ago
2008? There never was a C++08... Last Standard was 2003 before C++11.
- steven2012 12y ago
  You're right, sorry I got mixed up between 2003 and Visual Studio 2008 which is the IDE I used frequently back then.
  - ohyesyodo 12y ago
    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?
  - 12y ago

Animats 12y ago

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.

amelius 12y ago

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

nly 12y ago
> 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 ;)