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

http://www.drdobbs.com/cpp/the-c14-standard/240169034

by Tsiolkovsky • 12 years ago

193 134 12 years ago

drdobbs.com

MordodeMaru• 12 years ago

You can also check JD Garcia's view here:

http://blog.biicode.com/cpp14/

raverbashing3• 12 years 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• 12 years 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• 12 years 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.

progman4• 12 years 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.

pjmlp9• 12 years ago

Unfortunately Ada got relegated for niche areas where safety is of highest importance.

System programming languages need OS vendors support to thrive.

pjmlp9• 12 years 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.

mwcampbell2• 12 years 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?

Ragnarork6• 12 years 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).

raverbashing3• 12 years 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• 12 years 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• 12 years 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.

jasode3• 12 years 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=l...

ufo2• 12 years 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.

Pxtl3• 12 years ago

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.

JoeAltmaier4• 12 years 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.

Ragnarork6• 12 years 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/Presentatio...

JoeAltmaier4• 12 years 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.

ansgri• 12 years 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.

millstone3• 12 years ago

I disagree very strongly with the argument presented there - in fact, I think it provides enough rope to hang itself.

It says:

1. With deduction you always get right type

2. Deduction guarantees no implicit conversion will happen

From this we can conclude that "the right type" never involves an implicit conversion. This is false: see vector<bool>::operator[], or consider the fact that auto allows you to make a variable of a type you cannot name explicitly (i.e. is private), which is surely not "the right type!"

freditup2• 12 years 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.

ubercore2• 12 years 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.

pyrois4• 12 years 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).

pyrois4• 12 years 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".

seccess2• 12 years 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.

seren2• 12 years ago

Now, for the fun part, imagine you have to integrate a third-party cpp library, with an API like "auto fooBar()".

dragonwriter2• 12 years 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++.

Someone2• 12 years 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/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-retur...:

    Of course, this requires the function body to be visible.

freditup2• 12 years ago

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.

Ragnarork6• 12 years ago

In fact, with an IDE, this argument is moot. You can have the type anyway.

Then, we do use template parameters already, for which we usually don't know the type. I can't see why we'd bitch about 'auto' and not about the template parameters.

It's just the same thing: coding against interfaces and not implementations.

kruczek2• 12 years ago

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.

Guvante• 12 years ago

Remember this is primarily for non-public facing or complex objects. If you are looking at someones API on github it should not be using auto for return types.

pyrois4• 12 years ago

I think in any sane library, public API functions will have declared return types. It's only for small helper functions inside a source file that will be autoed. I agree that misuse of auto is going to be terrible, though.

dangerlibrary• 12 years ago

That's a reasonable position, but the popularity of languages without any type declarations at all suggests that there are many people who don't mind. (python, ruby, etc.)

JoeAltmaier4• 12 years ago

And 'auto' isn't the same as no type declaration. Auto still enforces type consistency, so its not that foreign to existing C++ expectations.

panzagl• 12 years ago

Yeah, we'll end up with some type of Hungarian notation for function naming. A lot of 'Modern C++' seems to be taking over what is really the job of an IDE, just because the original C++ syntax was so verbose.

raverbashing3• 12 years ago

Edit: see child comments to see why this is a bad idea, at least with native types. Maybe typeid() is better

You have a point there

what you could do is:

return (int)x;

return (YourClass)value;

(then the header and implementation are auto but you still know what the code is talking about

(Or just put the type there as usual)

Ragnarork6• 12 years ago

Except you may have a conversion and you don't know it.

kruczek2• 12 years ago

Same can be said about using 'auto' for variable type declarations. It all comes down to "use, but don't abuse" (as most things in C++) - it can improve readability, if used moderately; and it is up to the programmer to judge where to use it.

sampo• 12 years ago

The compiler knows the inferred types anyway. And several other languages have tools to query these types.

Maybe such a tool for C++ will also appear?

pjmlp9• 12 years ago

C++ IDEs already offer such feature.

Pxtl3• 12 years ago

Type inference has been a fantastic blessing for me in C#, so I'll never complain about having to type locals... by extension, implicitly-typed privates seems to make sense. But the public interface of a class? That just feels one step too far.

MichaelGG• 12 years ago

What if it's a private interface, like a local function? Or a public interface with limited consumers? The language should allow you to write your code the way you want.

Requiring pointless verbosity on some hope that somehow that'll help bad programmers write better code seems like an odd conclusion.

jibsen• 12 years ago

What happens if a header file declares a function to return auto, does the compiler have to wait until link time to find out what the type is?

missblit• 12 years ago

No, types are completely determined before link time.

An auto return type means the type is inferred from the type of the expression that the function returns, so it's known from that.

ludamad• 12 years ago

Note that this can be used for static functions, I don't think anyone would find it in an API documentation. The real reason I see for this is reducing voodoo in template libraries, eg forwarding a call T::something() for a generic type 'T'.

plorkyeran3• 12 years ago

The primary use-case of auto returns is for templated functions where the return type depends on the thing passed in. For example, in C++11 you have to write things like the following:

    template<typename Range>
    auto begin(Range& r) -> decltype(r.begin()) {
        return r.begin();
    }

The return type can't be specified by the function[0], and you have to copy and paste the body of the function into the decltype() clause to tell the compiler that the return type is whatever the thing it's wrapping returns. When you have some long and complicated expression rather than just r.begin() in the body, this duplication becomes a major issue.

[0] In this specific case you could require that Range have an iterator typedef and return that, but that approach does not generalize.

jobu2• 12 years ago

C++ templates used to be the most unreadable code this side of Perl, but with auto and a little documentation you can figure out what's happening fairly easily. Templates (and auto) are typically used when dealing with core libraries and should be documented better than average code anyway.

If someone starts using auto for every variable or returning it from every method, then they need a stern talking-to.

PoL0• 12 years ago

Just gather the result in an auto (auto&, const auto&,...) variable et voilà

cschwan3• 12 years 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.

humanrebar2• 12 years 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.

cschwan3• 12 years ago

How would concepts simplify this?

jevinskie• 12 years ago

Ranges are coming: https://github.com/ericniebler/range-v3/blob/master/doc/D412...

monk_the_dog• 12 years ago

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/

cschwan3• 12 years ago

Thanks for the pointer!

mFixman• 12 years 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.

pjmlp9• 12 years ago

The idea is that eventually you can use them in meta-programming just like in other languages that support attributes.

repsilat2• 12 years 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?

dkhenry2• 12 years 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• 12 years 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.

dkhenry2• 12 years 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• 12 years 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?

plorkyeran3• 12 years 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• 12 years ago

Here's the GitHub link: https://github.com/cplusplus/draft

andrewflnr• 12 years 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• 12 years ago

Seems like some of these (including auto) can also work with C.

Anyone know if compilers will support that?

fafner• 12 years ago

GCC 4.9 added __auto_type as an extension in C.

MichaelMoser1232• 12 years 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-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• 12 years ago

This isn't new in C++14 though.

MichaelMoser1232• 12 years ago

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

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

Related Stories