12 ms·

The C++14 Standard: What You Need to Know

193 points by Tsiolkovsky 12y ago

MordodeMaru 12y ago
You can also check JD Garcia's view here: http://blog.biicode.com/cpp14/ http://blog.biicode.com/cpp14/
raverbashing 12y ago
The best thing that has happened in the last years is not having to depend on C++ anymore Good changes, but too little, too late. Of course, we still depend on it, but for an ever smaller set of use cases. Do what you have to do and "get out of there" as fast as you can to your favourite language.
- 4ad 12y ago
  Agreed. Many bad trends emerged in the industry in the last decade, but today I am happy I can afford not to write C++ anymore. And yes, I did say afford there.
  - general_failure 12y ago
    Excellent wording. My employer cannot afford my team to write c++ either. It takes way too long to yeah each person the language features. C++ is awesome for seasoned developers but it tak s years to get there. Cannot wait for rust.
    - progman 12y ago
      > Cannot wait for rust. Yes, Rust looks VERY promising.
- progman 12y ago
  The examples remind me again why I turned away from C++ some years ago. In the first years of C++ it was real joy to write software in it but now the syntax seems to be much more useful for obfuscation rather than maintainability. Funny: When C++ began Ada 95 looked like a giant animal. Now Ada 2012 looks small and efficient in comparison although it is more powerful than Ada 95.
  - pjmlp 12y ago
    Unfortunately Ada got relegated for niche areas where safety is of highest importance. System programming languages need OS vendors support to thrive.
    - progman 12y ago
      Ada is a general purpose programming language, including systems programming. http://www.ada2012.org http://www.ada2012.org Support is provided by AdaCore for instance: http://www.adacore.com http://www.adacore.com
      - pjmlp 12y ago
        I do know a little bit about Ada, thanks. The point being systems programming languages die if not sponsored by the OS vendors, because they have to fight for mindshare among the so called business languages. In Ada's case, the high cost of development systems, rise of UNIX use in the enterprise, decline of Pascal based languages. All contributed to it being used in its field of origin (avionics) and systems where security and human life are of utmost importance. In Europe there was a rise of Ada projects due to lack of security in the usual C and C++, but these are always specialized projects, like train systems control and such. Not the typical Show HN applications. I would like to see Ada being more used in the industry, but sadly it won't happen.
        progman 12y ago
        > In Ada's case, the high cost of development systems Not necessarily. http://www.adacore.com/press/gnat-gpl-for-bare-board-arm/ http://www.adacore.com/press/gnat-gpl-for-bare-board-arm/ Look also for the book "Building Parallel, Embedded, and Real-Time Applications with Ada" by McCormick, Singhoff and Hugues. Some prominent embedded engineers wonder why Ada is not used much more: http://www.embedded.com/electronics-blogs/break-points/4008214/Why-aren-t-developers-interested-in-Ada- http://www.embedded.com/electronics-blogs/break-points/40082... > Rise of UNIX use in the enterprise Ada is available for Windows, Linux, OSX and ARM. GNAT/GCC is part of many Linux distros (usually Ada95). You can also download Ada2012 and Ada2014 compilers and tools from Adacore's website. > Decline of Pascal based languages. Ada looks a bit like Pascal but the language is far superior. In my opinion Ada's syntax makes software easier to maintain than C/Java like syntax. Even after years I have no problem to read into Ada code. C++ code can be difficult to read just after a short time. I think the real reason of Ada's decline is that it requires a lot of discipline of the developer. The same kind of discipline is required in Haskell. You cannot just sit down and code. You have to think a lot about your design before you hit the first key. Most developers don't like this, they want quick (and dirty) solutions, and they get it with C and C++.
- pjmlp 12y ago
  > Do what you have to do and "get out of there" as fast as you can to your favourite language. Which happens to be C++, until OS vendors support another one on their SDKs. So until Ada, Rust, D, Swift, .NET Native or something else get such a position, C++ it is.
  - mwcampbell 12y ago
    For what types of applications do you think it's actually important to use the native language of the OS? After all, non-native languages can have bindings for the OS APIs. In your opinion, what are the drawbacks of mostly avoiding C++ and using one's favorite language, as the GP said?
    - pyrois 12y ago
      If you're developing a fairly complex library for things such as image processing, machine learning, numerics, linear algebra, etc., then I think that C/C++ is the way to go. Most languages have some sort of FFI to interact with C, many are even designed explicitly to work with C (such as Cython). C++ is in a similar situation (though compiler support on esoteric processors such as DSPs is still not quite there yet), and it's fairly easy to get a C-compatible API. If you write your library in Perl, guess what, only people writing Perl will use it. If you write it in Java, well, maybe the Scala folk will wrap it up, or the Jython folk, but you won't get any people writing in Ruby to use it. If you write it in C++, you can provide efficient bindings to any of those languages. For an example, look at FFmpeg or ImageMagick. They are libraries that just _won't die_, no matter how hard people have tried. My god, ImageMagick was written in 1987, and it now has Haskell bindings[0]! The only way to get that sort of longevity (and old code is good code, after all [1]) is to write in language that will outlast the ups and downs of the language or framework du jour, and C and C++ have proven to have that staying power. Yeah, they're terrible; I hate them. But there is a reason to use them. [0] http://hackage.haskell.org/package/imagemagick http://hackage.haskell.org/package/imagemagick [1] http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
    - pjmlp 12y ago
      - Not able to use the OS vendor tooling which only support the official languages - Another layer to debug (FFI) - Possible loss of performance when crossing the FFI barrier - Loss of productivity, because that cool API isn't available and so one has to write it - Writing drivers, daemons/services, OS plugins, ... One of the reasons I moved from Turbo Pascal to C++, when I started coding on Windows 3.0, was being fed up to write binding libraries by myself. Although I really enjoyed Turbo Pascal back then.
- Ragnarork 12y ago
  This is still a matter of opinion. My favorite language is still C++. This is of course personal preference, but also mostly because I realized (and it seems to me that some people haven't, just go around and ask what is C/C++, and people will tell you it's one language...) that C++ is not just anymore "C with classes", and the fact there is C-ish, or even just bad C++ code out in the wild doesn't make the language bad in itself (it can still be less appropriate/completely irrelevant for some applications, which is fine).
  - raverbashing 12y ago
    True, with STL and the recent changes the "C with classes" thing gets more distant. But sorry, I don't miss the includes, the huge class hierarchies, the template madness, etc C++ is good if you stick to a strict code standard and don't let people "go crazy" with it. But the thing is that good languages end up limiting the amount of "bad code" that naturally emerges. (Java does it through lack of flexibility and enforcement, I prefer the Python and Go way)
vanderZwan 12y ago
> With the addition of generic lambdas, I can define a single lambda with generic parameters. Although the syntax doesn't include the keyword template, this is still clearly a further extension of C++ generic programming So what are the nuances when comparing this approach to using a template to create a generic function? Aside from stylistic differences, would using one over the other affect compile time or runtime performance in any (meaningful) way?
tonysuper 12y ago
Am I the only person who finds the digit separator syntax ugly and a bit unnecessary? I love the rest of the changes, but that just doesn't sit right with me.
- jasode 12y ago
  It just makes it easier to read the magnitude of a number and get that extra visual reassurance that it's correct. It's not easy to (quickly) tell the difference between 1 billion and 100 million unless you count zeros (1000000000 vs 100000000). On the other hand it's very easy to discern 1'000'000'000 vs 100'000'000. The standard can't use commas as a separator because using commas vs periods to demarcate components is locale specific. Apostrophes look like a reasonable compromise because lots of calculators already use apostrophes to separate digits: https://www.google.com/search?q=14+digit+calculator&source=lnms&tbm=isch https://www.google.com/search?q=14+digit+calculator&source=l...
  - ufo 12y ago
    The bigger reason why you can't use commas is because commas are already an operator in c++. 1,2 is an expression that evaluates to 2. Dunno why they didn't use underscores though.
    - jasode 12y ago
      The "already an operator" can be a factor in the design reasoning but if they really really wanted to, they could have made the comma syntax for digit separators by modifying the parsing grammar: e.g. a special prefix and/or contextual parsing. For example, the "->" was already an operator for pointer indirection but it was reused for lambda definitions. The "[]" was already used for array subscript indexes but was reused for lambda captures.
      - chappar 12y ago
        You can't do that for ",", because it will break the existing code. For example, int x = 0; x = 1,2; is perfectly valid pre c++11 code. This will assign 1 to x. Now if you make "," as digit separator, it will assign 12 to x
JoeAltmaier 12y ago
I think 'auto' may become a brain-drain like const-ness already is. You try to use it in one place - and it ripples throughout your base classes and libraries. It may be useful in some narrow set of situations (templates? lambdas?) but beyond that it remains to be seen.
- Ragnarork 12y ago
  You should look at "Back to the Basics! Essentials of Modern C++ Style" talk from Herb Sutter at CppCon 2014[1]. You'd have a great insight on why 'auto' isn't just some kind of "convenience" keyword and why it matters. [1] https://github.com/CppCon/CppCon2014/blob/master/Presentations/Back%20to%20the%20Basics!%20Essentials%20of%20Modern%20C%2B%2B%20Style%20-%20Herb%20Sutter%20-%20CppCon%202014/Back%20to%20the%20Basics!%20Essentials%20of%20Modern%20C%2B%2B%20Style%20-%20Herb%20Sutter%20-%20CppCon%202014.pdf https://github.com/CppCon/CppCon2014/blob/master/Presentatio...
  - JoeAltmaier 12y ago
    Oh I see it can matter. But it may become intractable. Using 'const' matters, but few achieve it - even std library methods rarely use it for immutable arguments, so if I try to use const I end up casting to non-const to call down.
    - vinkelhake 12y ago
      > even std library methods rarely use it for immutable arguments Can you give some examples of methods in the standard library that should use const, but doesn't?
  - ansgri 12y ago
    Thanks for the link! Now I know what to tell my students next time. C++ is the language of choice for recognition systems development anyway, and with C++14 it's actually starting to become beautiful.
    - 12y ago
freditup 12y ago
> For example, if a function has multiple return paths, they need to have the same type. > ... > [Code sample that returns -1 or record->id] > Instead of using an integral type to identify the person in the record object, maybe I have a new GUID type. Making that change to the record object will cause a series of cascading changes in things like the return types of functions. But if my function uses automatic return type deduction, the compiler will silently make the change for me. Yet when this happens, his example function can now return -1 or a GUID, so compilation should fail, no? Haven't worked with C++ in awhile so I might just be missing something on this, but seems like a contradiction to me.
- ubercore 12y ago
  No, the return type can change as long as all return paths return the same value for the same function call. So you can't, in the same execution, return two different types, but two different executions can vary their return type as long as its consistent.
  - pyrois 12y ago
    The point is that -1 is not a GUID, though, so in the sample function, if record::id changes to a GUID, the find_id function is now trying to return -1 (an integer) and ii->id (a GUID).
    - ubercore 12y ago
      Right. Thanks for correcting me, I missed that.
- deleted 12y ago
  [deleted]
- pyrois 12y ago
  I'm not sure if implicit conversions are applied to type deductions. It could be that GUID has a constructor that takes in an integer, which would mean that if the function were declared with a return type of "GUID", returning -1 would be fine. I don't know if the same applies to functions with "auto" as the return type, but the example with the int and the double suggests not. So, this is a long-winded way of saying "yes, I think it's a bug".
seccess 12y ago
Using 'auto' for return types seems just awful to me. In the context of a collaborative project, I don't want to have to dig through the implementation of someone else's function just to figure out what type it returns. Having an explicit return type is a form of self-documenting code.
- seren 12y ago
  Now, for the fun part, imagine you have to integrate a third-party cpp library, with an API like "auto fooBar()".
  - dragonwriter 12y ago
    Sure, auto probably shouldn't be used on a function that's part of the exposed API of a library, rather than something internal to the unit of code it is part of. Its kind of weird to see people complaining about a C++ feature because its not appropriate to use indiscriminately and requires some discipline -- that's historically been pretty much the whole of C/C++.
    - seren 12y ago
      My comment was mostly tongue-in-cheek, it will be misused in some time and place, but is not a serious issue.
  - Someone 12y ago
    A third party can do that but if it doesn't also provide the source for fooBar, you won't be able to call it, making it fairly useless. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n363...: Of course, using such a function in an expression when only a forward declaration has been seen is ill-formed: auto f(); // return type is unknown int i = f(); // error, return type of f is unknown And https://isocpp.org/wiki/faq/cpp14-language#generalized-return https://isocpp.org/wiki/faq/cpp14-language#generalized-retur...: Of course, this requires the function body to be visible.
- 12y ago
cschwan 12y ago
"Relaxed requirements for constexpr" is an item that I wish would have gone into C++11. Once have you multiple code paths and need to loop over variables constexpr functions get really unreadable. One thing the C++ standard library IMO needs is a range library, e.g. something like Boost Range. I often would like to use the "range-for" but when I am not looping over all the elements of a container its useless in that case.
- humanrebar 12y ago
  constexpr was already difficult to implement (much more difficult than originally thought). As far as I understand, the committee wanted to be conservative in scope in case a limited constexpr could serve the needed use cases without being an limitless source of compiler complexity and bugs. I agree about the range library, but it will be difficult to impossible to implement in the standard library without concepts. 2020 could be the year of range algorithms.
  - cschwan 12y ago
    How would concepts simplify this?
    - humanrebar 12y ago
      Using unqualified templates, the compiler can't distinguish between template<typename RANGE, typename PRED> void sort(RANGE, PRED); and template<typename ITERATOR> void sort(ITERATOR start, ITERATOR stop); Since we already have the iterator algorithm defined, there is no room for a range algorithm name 'sort' with two template-deduced parameters. There are workarounds using enable_if, but they're hairy and involve basically recreating concepts at the standard library level. Herb Sutter: "I’m hopeful that the standard library will get range-based overloads of all standard algorithms that are enable_if’d to avoid the problem or can use concepts if those make it into a future standard." http://herbsutter.com/2011/10/07/why-no-container-based-algorithms/ http://herbsutter.com/2011/10/07/why-no-container-based-algo... Why concepts then? The concepts version would look like: template<Range, Comparator> void sort(Range & r, Comparator const & c); ...and the compiler would be able to tell that iterators wouldn't work with this algorithm.
mFixman 12y ago
I'm not a fan of having attribute tokens like [[deprecated]] written between brackets instead of using the keyword normally like a regular attribute. It smells awfully like C99's _Bool and _Complex, which were created to support legacy code but ended up being an ugly headache.
- pjmlp 12y ago
  The idea is that eventually you can use them in meta-programming just like in other languages that support attributes.
  - repsilat 12y ago
    Can we expect to be able to write our own attributes (to be ignored by tools that don't understand what they mean), or will we get compiler errors/warnings there?
dkhenry 12y ago
So now I need an emacs package that can parse my c++ and can replace all instances of the auto keyword with their actual types. That way I can develop quickly using auto but I can keep the code maintainable by having full type signatures.
- cheepin 12y ago
  As mentioned in another comment, the use of 'auto' isn't just to shorten an unwieldy type name. > The primary use-case of auto returns is for templated functions where the return type depends on the thing passed in.
  - dkhenry 12y ago
    Normally I feel the c++ standards committee has great ideas, however this is not one of them. If you want templated lambdas then you should use templates.
Pxl_Buzzard 12y ago
> At this point you can get a free copy of the draft proposal here. Unfortunately, when the final standard is published, ISO will have it paywalled. Since when was a language spec put behind a paywall? I can't comprehend the reasoning behind this, given that open source compilers exist for C++. How much is it to view the spec? Why do they need to charge at all?
- plorkyeran 12y ago
  ISO has always charged for its standards, which made more sense when they were distributed on paper. It's especially goofy for C++ as the (latex) source code for the final version of the standard is on Github now, so the only thing that's paywalled is the "official" pdf version.
  - agwa 12y ago
    Here's the GitHub link: https://github.com/cplusplus/draft https://github.com/cplusplus/draft
andrewflnr 12y ago
Template variables are really interesting. I had a similar idea years ago, as a bit of "wouldn't it be cool if..." speculation, but never expected to see it in C++.
ars 12y ago
Seems like some of these (including auto) can also work with C. Anyone know if compilers will support that?
- fafner 12y ago
  GCC 4.9 added __auto_type as an extension in C.
MichaelMoser123 12y ago
the article does not mention rvalues and move semantics (i think it's one of the bigest features). here is an explanation http://stackoverflow.com/questions/6815685/move-semantics-what-its-all-about http://stackoverflow.com/questions/6815685/move-semantics-wh... it is supposed to save extra copies like here string a("a"); string b("b"); string c = a + b; // creates temporary object that is copied into C by value - the temporary is just a 'full copy'; so that for the temporary it needs an extra allocation and strcpy and free. the fix is to add the following to the string class string(string &&r) { ... } string &operator=(string &&r) { ... } so the operator with the && receives and 'rvalue' reference - which is a special reference to just this temprorary and the implementation of this is supposed to swap the data of the temporary with that of the this object; the temporary is then discarded.
- zeroonetwothree 12y ago
  This isn't new in C++14 though.
  - MichaelMoser123 12y ago
    lambda functions and the auto keyword aren't new either - in C++11 already.
    - ternaryoperator 12y ago
      auto keyword was in C++11, but as this article points out, it does a whole lot more in C++14.
    - capisce 12y ago
      Yes, but the use of auto to auto-deduce the return type is new in C++14, as well as the use of auto as a return type for lambdas to produce generic lambdas - generic functions without having to use template syntax.

193 points by Tsiolkovsky 12y ago

You can also check JD Garcia's view here: http://blog.biicode.com/cpp14/ http://blog.biicode.com/cpp14/

The best thing that has happened in the last years is not having to depend on C++ anymore Good changes, but too little, too late. Of course, we still depend on it, but for an ever smaller set of use cases. Do what you have to do and "get out of there" as fast as you can to your favourite language.

4ad 12y ago
Agreed. Many bad trends emerged in the industry in the last decade, but today I am happy I can afford not to write C++ anymore. And yes, I did say afford there.
- general_failure 12y ago
  Excellent wording. My employer cannot afford my team to write c++ either. It takes way too long to yeah each person the language features. C++ is awesome for seasoned developers but it tak s years to get there. Cannot wait for rust.
  - progman 12y ago
    > Cannot wait for rust. Yes, Rust looks VERY promising.
progman 12y ago
The examples remind me again why I turned away from C++ some years ago. In the first years of C++ it was real joy to write software in it but now the syntax seems to be much more useful for obfuscation rather than maintainability. Funny: When C++ began Ada 95 looked like a giant animal. Now Ada 2012 looks small and efficient in comparison although it is more powerful than Ada 95.
- pjmlp 12y ago
  Unfortunately Ada got relegated for niche areas where safety is of highest importance. System programming languages need OS vendors support to thrive.
  - progman 12y ago
    Ada is a general purpose programming language, including systems programming. http://www.ada2012.org http://www.ada2012.org Support is provided by AdaCore for instance: http://www.adacore.com http://www.adacore.com
    - pjmlp 12y ago
      I do know a little bit about Ada, thanks. The point being systems programming languages die if not sponsored by the OS vendors, because they have to fight for mindshare among the so called business languages. In Ada's case, the high cost of development systems, rise of UNIX use in the enterprise, decline of Pascal based languages. All contributed to it being used in its field of origin (avionics) and systems where security and human life are of utmost importance. In Europe there was a rise of Ada projects due to lack of security in the usual C and C++, but these are always specialized projects, like train systems control and such. Not the typical Show HN applications. I would like to see Ada being more used in the industry, but sadly it won't happen.
      - progman 12y ago
        > In Ada's case, the high cost of development systems Not necessarily. http://www.adacore.com/press/gnat-gpl-for-bare-board-arm/ http://www.adacore.com/press/gnat-gpl-for-bare-board-arm/ Look also for the book "Building Parallel, Embedded, and Real-Time Applications with Ada" by McCormick, Singhoff and Hugues. Some prominent embedded engineers wonder why Ada is not used much more: http://www.embedded.com/electronics-blogs/break-points/4008214/Why-aren-t-developers-interested-in-Ada- http://www.embedded.com/electronics-blogs/break-points/40082... > Rise of UNIX use in the enterprise Ada is available for Windows, Linux, OSX and ARM. GNAT/GCC is part of many Linux distros (usually Ada95). You can also download Ada2012 and Ada2014 compilers and tools from Adacore's website. > Decline of Pascal based languages. Ada looks a bit like Pascal but the language is far superior. In my opinion Ada's syntax makes software easier to maintain than C/Java like syntax. Even after years I have no problem to read into Ada code. C++ code can be difficult to read just after a short time. I think the real reason of Ada's decline is that it requires a lot of discipline of the developer. The same kind of discipline is required in Haskell. You cannot just sit down and code. You have to think a lot about your design before you hit the first key. Most developers don't like this, they want quick (and dirty) solutions, and they get it with C and C++.
pjmlp 12y ago
> Do what you have to do and "get out of there" as fast as you can to your favourite language. Which happens to be C++, until OS vendors support another one on their SDKs. So until Ada, Rust, D, Swift, .NET Native or something else get such a position, C++ it is.
- mwcampbell 12y ago
  For what types of applications do you think it's actually important to use the native language of the OS? After all, non-native languages can have bindings for the OS APIs. In your opinion, what are the drawbacks of mostly avoiding C++ and using one's favorite language, as the GP said?
  - pyrois 12y ago
    If you're developing a fairly complex library for things such as image processing, machine learning, numerics, linear algebra, etc., then I think that C/C++ is the way to go. Most languages have some sort of FFI to interact with C, many are even designed explicitly to work with C (such as Cython). C++ is in a similar situation (though compiler support on esoteric processors such as DSPs is still not quite there yet), and it's fairly easy to get a C-compatible API. If you write your library in Perl, guess what, only people writing Perl will use it. If you write it in Java, well, maybe the Scala folk will wrap it up, or the Jython folk, but you won't get any people writing in Ruby to use it. If you write it in C++, you can provide efficient bindings to any of those languages. For an example, look at FFmpeg or ImageMagick. They are libraries that just _won't die_, no matter how hard people have tried. My god, ImageMagick was written in 1987, and it now has Haskell bindings[0]! The only way to get that sort of longevity (and old code is good code, after all [1]) is to write in language that will outlast the ups and downs of the language or framework du jour, and C and C++ have proven to have that staying power. Yeah, they're terrible; I hate them. But there is a reason to use them. [0] http://hackage.haskell.org/package/imagemagick http://hackage.haskell.org/package/imagemagick [1] http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
  - pjmlp 12y ago
    - Not able to use the OS vendor tooling which only support the official languages - Another layer to debug (FFI) - Possible loss of performance when crossing the FFI barrier - Loss of productivity, because that cool API isn't available and so one has to write it - Writing drivers, daemons/services, OS plugins, ... One of the reasons I moved from Turbo Pascal to C++, when I started coding on Windows 3.0, was being fed up to write binding libraries by myself. Although I really enjoyed Turbo Pascal back then.
Ragnarork 12y ago
This is still a matter of opinion. My favorite language is still C++. This is of course personal preference, but also mostly because I realized (and it seems to me that some people haven't, just go around and ask what is C/C++, and people will tell you it's one language...) that C++ is not just anymore "C with classes", and the fact there is C-ish, or even just bad C++ code out in the wild doesn't make the language bad in itself (it can still be less appropriate/completely irrelevant for some applications, which is fine).
- raverbashing 12y ago
  True, with STL and the recent changes the "C with classes" thing gets more distant. But sorry, I don't miss the includes, the huge class hierarchies, the template madness, etc C++ is good if you stick to a strict code standard and don't let people "go crazy" with it. But the thing is that good languages end up limiting the amount of "bad code" that naturally emerges. (Java does it through lack of flexibility and enforcement, I prefer the Python and Go way)

vanderZwan 12y ago

> With the addition of generic lambdas, I can define a single lambda with generic parameters. Although the syntax doesn't include the keyword template, this is still clearly a further extension of C++ generic programming So what are the nuances when comparing this approach to using a template to create a generic function? Aside from stylistic differences, would using one over the other affect compile time or runtime performance in any (meaningful) way?

tonysuper 12y ago

Am I the only person who finds the digit separator syntax ugly and a bit unnecessary? I love the rest of the changes, but that just doesn't sit right with me.

jasode 12y ago
It just makes it easier to read the magnitude of a number and get that extra visual reassurance that it's correct. It's not easy to (quickly) tell the difference between 1 billion and 100 million unless you count zeros (1000000000 vs 100000000). On the other hand it's very easy to discern 1'000'000'000 vs 100'000'000. The standard can't use commas as a separator because using commas vs periods to demarcate components is locale specific. Apostrophes look like a reasonable compromise because lots of calculators already use apostrophes to separate digits: https://www.google.com/search?q=14+digit+calculator&source=lnms&tbm=isch https://www.google.com/search?q=14+digit+calculator&source=l...
- ufo 12y ago
  The bigger reason why you can't use commas is because commas are already an operator in c++. 1,2 is an expression that evaluates to 2. Dunno why they didn't use underscores though.
  - jasode 12y ago
    The "already an operator" can be a factor in the design reasoning but if they really really wanted to, they could have made the comma syntax for digit separators by modifying the parsing grammar: e.g. a special prefix and/or contextual parsing. For example, the "->" was already an operator for pointer indirection but it was reused for lambda definitions. The "[]" was already used for array subscript indexes but was reused for lambda captures.
    - chappar 12y ago
      You can't do that for ",", because it will break the existing code. For example, int x = 0; x = 1,2; is perfectly valid pre c++11 code. This will assign 1 to x. Now if you make "," as digit separator, it will assign 12 to x

JoeAltmaier 12y ago

I think 'auto' may become a brain-drain like const-ness already is. You try to use it in one place - and it ripples throughout your base classes and libraries. It may be useful in some narrow set of situations (templates? lambdas?) but beyond that it remains to be seen.

Ragnarork 12y ago
You should look at "Back to the Basics! Essentials of Modern C++ Style" talk from Herb Sutter at CppCon 2014[1]. You'd have a great insight on why 'auto' isn't just some kind of "convenience" keyword and why it matters. [1] https://github.com/CppCon/CppCon2014/blob/master/Presentations/Back%20to%20the%20Basics!%20Essentials%20of%20Modern%20C%2B%2B%20Style%20-%20Herb%20Sutter%20-%20CppCon%202014/Back%20to%20the%20Basics!%20Essentials%20of%20Modern%20C%2B%2B%20Style%20-%20Herb%20Sutter%20-%20CppCon%202014.pdf https://github.com/CppCon/CppCon2014/blob/master/Presentatio...
- JoeAltmaier 12y ago
  Oh I see it can matter. But it may become intractable. Using 'const' matters, but few achieve it - even std library methods rarely use it for immutable arguments, so if I try to use const I end up casting to non-const to call down.
  - vinkelhake 12y ago
    > even std library methods rarely use it for immutable arguments Can you give some examples of methods in the standard library that should use const, but doesn't?
- ansgri 12y ago
  Thanks for the link! Now I know what to tell my students next time. C++ is the language of choice for recognition systems development anyway, and with C++14 it's actually starting to become beautiful.
  - 12y ago

freditup 12y ago

> For example, if a function has multiple return paths, they need to have the same type. > ... > [Code sample that returns -1 or record->id] > Instead of using an integral type to identify the person in the record object, maybe I have a new GUID type. Making that change to the record object will cause a series of cascading changes in things like the return types of functions. But if my function uses automatic return type deduction, the compiler will silently make the change for me. Yet when this happens, his example function can now return -1 or a GUID, so compilation should fail, no? Haven't worked with C++ in awhile so I might just be missing something on this, but seems like a contradiction to me.

ubercore 12y ago
No, the return type can change as long as all return paths return the same value for the same function call. So you can't, in the same execution, return two different types, but two different executions can vary their return type as long as its consistent.
- pyrois 12y ago
  The point is that -1 is not a GUID, though, so in the sample function, if record::id changes to a GUID, the find_id function is now trying to return -1 (an integer) and ii->id (a GUID).
  - ubercore 12y ago
    Right. Thanks for correcting me, I missed that.
deleted 12y ago
[deleted]
pyrois 12y ago
I'm not sure if implicit conversions are applied to type deductions. It could be that GUID has a constructor that takes in an integer, which would mean that if the function were declared with a return type of "GUID", returning -1 would be fine. I don't know if the same applies to functions with "auto" as the return type, but the example with the int and the double suggests not. So, this is a long-winded way of saying "yes, I think it's a bug".

seccess 12y ago

Using 'auto' for return types seems just awful to me. In the context of a collaborative project, I don't want to have to dig through the implementation of someone else's function just to figure out what type it returns. Having an explicit return type is a form of self-documenting code.

seren 12y ago
Now, for the fun part, imagine you have to integrate a third-party cpp library, with an API like "auto fooBar()".
- dragonwriter 12y ago
  Sure, auto probably shouldn't be used on a function that's part of the exposed API of a library, rather than something internal to the unit of code it is part of. Its kind of weird to see people complaining about a C++ feature because its not appropriate to use indiscriminately and requires some discipline -- that's historically been pretty much the whole of C/C++.
  - seren 12y ago
    My comment was mostly tongue-in-cheek, it will be misused in some time and place, but is not a serious issue.
- Someone 12y ago
  A third party can do that but if it doesn't also provide the source for fooBar, you won't be able to call it, making it fairly useless. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n363...: Of course, using such a function in an expression when only a forward declaration has been seen is ill-formed: auto f(); // return type is unknown int i = f(); // error, return type of f is unknown And https://isocpp.org/wiki/faq/cpp14-language#generalized-return https://isocpp.org/wiki/faq/cpp14-language#generalized-retur...: Of course, this requires the function body to be visible.
12y ago

cschwan 12y ago

"Relaxed requirements for constexpr" is an item that I wish would have gone into C++11. Once have you multiple code paths and need to loop over variables constexpr functions get really unreadable. One thing the C++ standard library IMO needs is a range library, e.g. something like Boost Range. I often would like to use the "range-for" but when I am not looping over all the elements of a container its useless in that case.

humanrebar 12y ago
constexpr was already difficult to implement (much more difficult than originally thought). As far as I understand, the committee wanted to be conservative in scope in case a limited constexpr could serve the needed use cases without being an limitless source of compiler complexity and bugs. I agree about the range library, but it will be difficult to impossible to implement in the standard library without concepts. 2020 could be the year of range algorithms.
- cschwan 12y ago
  How would concepts simplify this?
  - humanrebar 12y ago
    Using unqualified templates, the compiler can't distinguish between template<typename RANGE, typename PRED> void sort(RANGE, PRED); and template<typename ITERATOR> void sort(ITERATOR start, ITERATOR stop); Since we already have the iterator algorithm defined, there is no room for a range algorithm name 'sort' with two template-deduced parameters. There are workarounds using enable_if, but they're hairy and involve basically recreating concepts at the standard library level. Herb Sutter: "I’m hopeful that the standard library will get range-based overloads of all standard algorithms that are enable_if’d to avoid the problem or can use concepts if those make it into a future standard." http://herbsutter.com/2011/10/07/why-no-container-based-algorithms/ http://herbsutter.com/2011/10/07/why-no-container-based-algo... Why concepts then? The concepts version would look like: template<Range, Comparator> void sort(Range & r, Comparator const & c); ...and the compiler would be able to tell that iterators wouldn't work with this algorithm.

mFixman 12y ago

I'm not a fan of having attribute tokens like [[deprecated]] written between brackets instead of using the keyword normally like a regular attribute. It smells awfully like C99's _Bool and _Complex, which were created to support legacy code but ended up being an ugly headache.

pjmlp 12y ago
The idea is that eventually you can use them in meta-programming just like in other languages that support attributes.
- repsilat 12y ago
  Can we expect to be able to write our own attributes (to be ignored by tools that don't understand what they mean), or will we get compiler errors/warnings there?

dkhenry 12y ago

So now I need an emacs package that can parse my c++ and can replace all instances of the auto keyword with their actual types. That way I can develop quickly using auto but I can keep the code maintainable by having full type signatures.

cheepin 12y ago
As mentioned in another comment, the use of 'auto' isn't just to shorten an unwieldy type name. > The primary use-case of auto returns is for templated functions where the return type depends on the thing passed in.
- dkhenry 12y ago
  Normally I feel the c++ standards committee has great ideas, however this is not one of them. If you want templated lambdas then you should use templates.

Pxl_Buzzard 12y ago

> At this point you can get a free copy of the draft proposal here. Unfortunately, when the final standard is published, ISO will have it paywalled. Since when was a language spec put behind a paywall? I can't comprehend the reasoning behind this, given that open source compilers exist for C++. How much is it to view the spec? Why do they need to charge at all?

plorkyeran 12y ago
ISO has always charged for its standards, which made more sense when they were distributed on paper. It's especially goofy for C++ as the (latex) source code for the final version of the standard is on Github now, so the only thing that's paywalled is the "official" pdf version.
- agwa 12y ago
  Here's the GitHub link: https://github.com/cplusplus/draft https://github.com/cplusplus/draft

andrewflnr 12y ago

Template variables are really interesting. I had a similar idea years ago, as a bit of "wouldn't it be cool if..." speculation, but never expected to see it in C++.

ars 12y ago

Seems like some of these (including auto) can also work with C. Anyone know if compilers will support that?

fafner 12y ago
GCC 4.9 added __auto_type as an extension in C.

MichaelMoser123 12y ago

the article does not mention rvalues and move semantics (i think it's one of the bigest features). here is an explanation http://stackoverflow.com/questions/6815685/move-semantics-what-its-all-about http://stackoverflow.com/questions/6815685/move-semantics-wh... it is supposed to save extra copies like here string a("a"); string b("b"); string c = a + b; // creates temporary object that is copied into C by value - the temporary is just a 'full copy'; so that for the temporary it needs an extra allocation and strcpy and free. the fix is to add the following to the string class string(string &&r) { ... } string &operator=(string &&r) { ... } so the operator with the && receives and 'rvalue' reference - which is a special reference to just this temprorary and the implementation of this is supposed to swap the data of the temporary with that of the this object; the temporary is then discarded.

zeroonetwothree 12y ago
This isn't new in C++14 though.
- MichaelMoser123 12y ago
  lambda functions and the auto keyword aren't new either - in C++11 already.
  - ternaryoperator 12y ago
    auto keyword was in C++11, but as this article points out, it does a whole lot more in C++14.
  - capisce 12y ago
    Yes, but the use of auto to auto-deduce the return type is new in C++14, as well as the use of auto as a return type for lambdas to produce generic lambdas - generic functions without having to use template syntax.