Forgot your password?
typodupeerror
Programming Software Upgrades

C++14 Is Set In Stone 193

Posted by timothy
from the but-it's-a-soft-stone dept.
jones_supa (887896) writes "Apart from minor editorial tweaks, the ISO C++14 standard can be considered completed. Implementations are already shipping by major suppliers. C++14 is mostly an incremental update over C++11 with some new features like function return type deduction, variable templates, binary literals, generic lambdas, and so on. The official C++14 specification release will arrive later in the year, but for now Wikipedia serves as a good overview of the feature set."
This discussion has been archived. No new comments can be posted.

C++14 Is Set In Stone

Comments Filter:
  • Re:Stone (Score:3, Informative)

    by makq (3730933) on Tuesday August 19, 2014 @11:36AM (#47703733)
    Silistone!
  • Re:Stone (Score:5, Informative)

    by NotInHere (3654617) on Tuesday August 19, 2014 @11:47AM (#47703819)

    Actually, its set in {La,}Tex: https://github.com/cplusplus/d... [github.com]

  • Re:Still... (Score:1, Informative)

    by Anonymous Coward on Tuesday August 19, 2014 @11:48AM (#47703829)

    Those are proper C comments since C99, no need for C++

  • Re:Still... (Score:5, Informative)

    by tlhIngan (30335) <slashdot AT worf DOT net> on Tuesday August 19, 2014 @11:52AM (#47703853)

    ...using c. Although I do like to comment thusly, and so prefer a compiler that understands at least basic c++: // comment

    I like to stay as close to the metal as I can get. I'd use assembler, but many of my projects are cross platform, so c it is.

    End of Line terminated comments ("//") actually are in the C spec as part of C99. And while it did take GCC a little while for that to be accepted in C mode, most other commercial compilers accepted them just fine. (C++ is not completely compatible with C, mind you, unlike Obj-C which is fully C compatible. This can cause issues if you try to compile C code using a C++ compiler rather than a C/C++ compiler)

    Now, one interesting thing in C++14 is binary literals (using "0b" a la "0x" for hex). That seems handy, though it would be more appropriate to be in C than C++ as C generally needs that sort of specification. Though, annoyingly, they didn't seem to allow use of something like _ to break long literals up into human-readable groups. I mean, a 32-bit string of bits is already hard enough to visually see, allowing the use of something like "_" in the string to help arbitrarily break up and group long constants would be helpful. (Even in hex it would be useful when doing 64-bit values).

    E.g., would you rather try to see which bit is set in a string like "0b001011010011011101011100" or have it broken up like "0b0010_1101_0011_0111_0101_1100" or "0b00101101_00110111_01011100". If it's a bit field, you may even want "0b001011_010011011_01_0_111_0_0" if breaking it into fields has meaning.

    Such a small change to help readability...

  • Re:Stone (Score:2, Informative)

    by geekoid (135745) <dadinportlandNO@SPAMyahoo.com> on Tuesday August 19, 2014 @11:58AM (#47703895) Homepage Journal

    silicon isn't sand. It's found in sand and stone, among other places.

  • Re:Still... (Score:5, Informative)

    by Anonymous Coward on Tuesday August 19, 2014 @12:13PM (#47704049)

    Though, annoyingly, they didn't seem to allow use of something like _ to break long literals up into human-readable groups.

    Yes they did. It's not underscore, it's apostrophe. For example:
            auto a = 0b100'0001; // ASCII 'A'
            auto million = 1'000'000;

    See here:
            http://isocpp.org/wiki/faq/cpp14-language#digit-separators>http://isocpp.org/wiki/faq/cpp14-language#digit-separators

  • Re:Still... (Score:5, Informative)

    by Imagix (695350) on Tuesday August 19, 2014 @12:14PM (#47704059)
    Uh, yes they do. Don't rely on summaries to list all of the features of the language. From N3797: An integer literal is a sequence of digits that has no period or exponent part, with optional separating single quotes that are ignored when determining its value. Example: The number twelve can be written 12, 014, 0XC, or 0b1100. The literals 1048576, 1’048’576, 0X100000, 0x10’0000, and 0’004’000’000 all have the same value. — end example
  • by e r (2847683) on Tuesday August 19, 2014 @12:40PM (#47704305)
    Herb Sutter responded to this on his blog (Sutter's Mill): http://herbsutter.com/2013/08/... [herbsutter.com]
  • by Anonymous Coward on Tuesday August 19, 2014 @12:45PM (#47704327)

    There are several cases where auto is critical.

    For instance with lambdas, it is no longer even possible to write out the types:

    auto itr = boost::make_filter_iterator([](const Bar &bar) {return bar.foo;},vect.begin(),vect.end());

    The type of itr is boost::filter_iterator, but it cannot be written out because there is no way to enter to the type of the lambda.

    It also eliminates nasty hacks like you see in BGL:

    property_map::const_type pm = get(vertex_index,graph);

    The property_map specialization framework is nasty and complex and conveys no meaning to the caller beyond what 'get' already says. So instead of the nasty property_map we use 'auto' and decltype(get(vertex_index,declval()), which is just as informative to the reader.

    Another good use is to get rid of duplications:

    auto ptr = make_shared(..);

    Is better than the duplicative:

    std::shared_ptr ptr = make_shared(..);

    That isn't even touching how useful it is when working with template meta programming. There are many cases where building up a return type is incredibly complex, and not useful to the reader because the underlying type is obscured by template meta programming anyhow.

    The improvements to auto are mostly fine tuning. Eg return type deduction eliminates the nasty idiom that has developed:

    auto foo() -> decltype(the_return_function(...))
    {
            return the_return_function(...)
    }

    The duplication is very common when using auto for a return.

  • by kthreadd (1558445) on Tuesday August 19, 2014 @12:48PM (#47704365)

    Auto does not mean loose typing. It still has a type, you just don't have to write it but it will be there and will be enforced by the compiler.

  • by Stele (9443) on Tuesday August 19, 2014 @01:12PM (#47704575) Homepage

    auto definitely makes writing looping constructs with iterators shorter/easier, without additional typedefs, but by far the nicest use for it is in writing templates, where a specialization or type-dependent mapping my occur in the template using a helper function, and you don't necessarily know what the intermediate type might be. Sure, you could use some complicated typedefs, which may require additional traits classes, but auto handles it nicely.

  • by Xrikcus (207545) on Tuesday August 19, 2014 @01:34PM (#47704779)

    Lambdas are a primary place where auto is there precisely because C++ is a strong, statically typed language as far as possible. The alternative might be polymorphic lambdas, which would require dynamic typing. With auto the type you get, and can propagate through templates, is the type of that specific lambda. With polymorphism the type you'd get is the type of a lambda, from which you'd need to infer which lambda. Auto ensures that with a lambda, though the type is not easily known to the programmer, the type can be statically defined in the code and propagated accordingly.

  • Re:Oh god so what? (Score:5, Informative)

    by TheRaven64 (641858) on Tuesday August 19, 2014 @02:02PM (#47705041) Journal

    Integer overflow has absolutely nothing to do with security

    Integer overflow has been in the top five causes of CVEs for several years running. Buffer overflows, sadly, are still at the top.

  • by ravyne (858869) on Tuesday August 19, 2014 @04:10PM (#47706231)
    Auto has other benefits -- firstly, in nearly any case where you would use it, you use it not to avoid stating a type altogether, but to avoid repeating type information that is already stated explicitly or is immediately apparent from the initializing expression (e.g. int x = (int)some_float;) Secondly, in the case of generic code, auto makes it easier to just adapt types to different combinations of template type parameters when that's exactly what you want to do, the alternative has been to maintain these relationships yourself, through what is usually a non-trivial arithmetic of types (including their constness and reference types) and sometimes involving multiple levels of intermediately defined typedefs. Thirdly, some types in C++ actually cannot be stated explicitly (for example, the type of a closure generated from a lambda expression) and auto is the only option if you wish to store or reference one.

    In all cases, the value is strongly typed. The type of a value is set in stone the moment the program is compiled, although multi-types are supported through various library implementations (e.g. Boost::variant, I think is the name of one).
  • Re:Oh god so what? (Score:4, Informative)

    by lgw (121541) on Tuesday August 19, 2014 @04:32PM (#47706465) Journal

    So in the real world, you have to understand nearly all of it in order to be able to maintain other people's code or to work as a team.

    If you don't have coding standards and a firm code review process to enforce them, you have already lost.

    C++ has a lot of cruft to allow you to cleanly solve problems that 99% of coders will never encounter. I'd say that these days, if your not in some dark corner where you need at least 1 bizarre C++ feature, you should probably use a higher level language.

    As an example of what I mean - C++ lets you overload the 'new' operator. Why would you ever want to do that? There no reason to learn how that feature works until and unless you need it. But if you need to do "slab allocation" or otherwise change the memory allocation pattern away from "just malloc", suddenly overloading 'new' is an amazingly useful and clean way to do this. In C you have to replace malloc with some other call (or #define malloc notmalloc) and police it everywhere in your codebase, which gets ugly when you have 20 different objects each allocated from its own slab, and gets horrifically ugly when you discover that you need to do this a couple years into a project. In C++ you just overload 'new' on a class-by-class basis.

    C++ has many features like that - stuff that you'd almost never have any use for, but is wonderful when you find yourself in that dark corner. You just need to guard against that guy who just wants to play with some C++ cruft when it's not needed, just because it looks neat.

It is not for me to attempt to fathom the inscrutable workings of Providence. -- The Earl of Birkenhead

Working...