

The C++14 Standard: What You Need to Know - Tsiolkovsky
http://www.drdobbs.com/cpp/the-c14-standard/240169034

======
seccess
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.

~~~
freditup
Agreed - the popularity of implicit typing is surprising to me. It seems to
make code much less readable and comprehensible. In a good IDE I suppose it
doesn't really matter because type information could be provided
automatically, but code isn't always read in a good IDE.

~~~
kruczek
Which is much less readable:

map<unsigned int, map<int, vector<string>::iterator> >::iterator
getSomeIterator();

or:

auto getSomeIterator();

Function name and context usually is sufficient to know what SomeIterator
refers to, there is no need for horrible STL constructs to try to explain it.

~~~
72deluxe
The first is readable and I know what it is. Not as readable, but at least I
know what it is!

I believe you don't need the space between the > > any more, since C++11?

~~~
seabee
Readability is about how quickly you can figure out what's going on. There are
only a few bits of syntax you need to know what's going on in the first
example, but it requires mentally matching together the angle brackets
correctly, and it emphasises the type over the function name.

In most cases you can scan over the type ('map blah blah...iterator') but
that's not reading and in any case will quickly fail you with nested template
types, if you're unfortunate enough to have those.

~~~
millstone
Functions that return iterators are never called getSomeIterator(). Instead
they're called stuff like erase(), insert(), or even nonsense words like
crend().

And whether a function returns an iterator is not consistent _even within the
STL_ :

    
    
        auto loc = container.find("name");
    

What type is loc? If container is a std::map, then loc is an iterator. If
container is a std::string, then loc is a size_t.

If you had used the explicit iterator type, you would at least get an error
message immediately with the above line, instead of hoping your code does
something that size_t doesn't support.

------
tonysuper
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
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=l...](https://www.google.com/search?q=14+digit+calculator&source=lnms&tbm=isch)

~~~
Pxtl
I would've gone with spaces. Those are the official standard here in Canada as
a pragmatic compromise between anglos and francos that have opposing usage of
comma/dot.

So instead of 1,234.56789 (English) or 1.234,56789 (French) we do 1 234.56789
(international)

[0-9]+ [0-9]+ has no meaning in C++, so using space for magnitude decorations
would have worked.

~~~
detrino
Have you considered if this would fit with C++'s grammar?

~~~
Pxtl
Briefly, but I think there are like three people in the world that fully grok
C++ grammar, and I'm definitely not one of them. I just know that C++
generally has some kind of infix operator or delimiter between pairs of
immediate data or variables, I'm pretty sure it's currently just a compiler
error in every case.

~~~
nightcracker
Except this is not C++ grammar, this is simple lexical analysis. And
separating by spaces would work fine.

------
freditup
> _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
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
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
Right. Thanks for correcting me, I missed that.

------
MordodeMaru
You can also check JD Garcia's view here:

[http://blog.biicode.com/cpp14/](http://blog.biicode.com/cpp14/)

------
cschwan
"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.

~~~
monk_the_dog
Eric Neibler is working on bring a range library into the standard. His blog
is a good source of info on his approach:
[http://ericniebler.com/](http://ericniebler.com/)

~~~
cschwan
Thanks for the pointer!

------
mFixman
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
The idea is that eventually you can use them in meta-programming just like in
other languages that support attributes.

~~~
repsilat
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?

------
vanderZwan
> _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?

------
Pxl_Buzzard
> 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
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
Here's the GitHub link:
[https://github.com/cplusplus/draft](https://github.com/cplusplus/draft)

------
MichaelMoser123
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-wh...](http://stackoverflow.com/questions/6815685/move-semantics-
what-its-all-about)

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
This isn't new in C++14 though.

~~~
MichaelMoser123
lambda functions and the auto keyword aren't new either - in C++11 already.

~~~
capisce
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.

------
JoeAltmaier
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
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/Presentatio...](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)

~~~
ansgri
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.

~~~
pjmlp
C++11 and C++14 removed many of my complaints about the language (I use it on
and off since 1993). Still waiting for modules though.

The biggest problem are the pre-C++98 codebases or the ones full with C idioms
instead of modern C++.

Those aren't going away anytime soon.

~~~
Ragnarork
> The biggest problem are the pre-C++98 codebases or the ones full with C
> idioms instead of modern C++.

Thanks for pointing that out. THIS is the real problem of C++. Not the
language spec (though it can and has to be improved with time), but those
codebases, which incidentally make perfectly sane people go nuts about C++...
:)

------
dkhenry
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
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
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.

------
andrewflnr
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
Seems like some of these (including auto) can also work with C.

Anyone know if compilers will support that?

~~~
fafner
GCC 4.9 added __auto_type as an extension in C.

------
raverbashing
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.

~~~
Ragnarork
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
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)

