Slashdot Mirror
C++14 Is Set In Stone
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."
Wouldn't it more useful for it to be set in silicone?
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
Intend to stay abreast of the spec, do you?
I've fallen off your lawn, and I can't get up.
Various black hats appreciate your dedication to C.
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...
COBOL is an excellent language for hat it was designed for. I can only assume your hate comes from ignorance.
It seems to me, your hate would be better directed at poor engineering and software engineering standards then the tools.
The Kruger Dunning explains most post on
Any individual can choose a usable subset of a complex system. The problem is that each individual chooses a different subset.
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.
I've been writing C++ since around 1990, when the idea of an STL was being bounced desperately around by Musser and Stepanov. Back then, C++ was a genuinely simple enough language to implement in - nobody pretended that it was anything more than a C compiler preprocessor, which is mostly what it still is, with a little bit of runtime support, but there's just so much of it.
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: // ASCII 'A'
auto a = 0b100'0001;
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
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
No. When I use structures as objects (which is often), they almost always contain a pointer to a block of general methods appropriate to that structure, as well as containing any methods unique to the object, all of which are called through the object/structure, so it would be unusual, at least, to be testing the object type in order to choose an object-specific procedure to call. However, I do mark each object type with a specific ID and serial as they are created, along with a tag indicating what procedure created them, as these things facilitate some very useful memory management and diagnostic mechanisms.
I am aware of qsort. But I have my own multi-method sort library that I use. Most of them locate the comparison mechanisms they are to use through the procedures specified by the objects they are asked to sort. Likewise list management, memory management, certain types of drawing primitives and image processing primitives, image handling mechanisms, associative storage, basically anything I have run into that I thought likely I would need more than once. I am positively locked into the idea that if I write it, I can fix it, and the number of bugs and problems that fall into the "maybe they'll fix the library someday" class are greatly reduced. I'm a little less picky if I have the source code to a capability I didn't actually write and can supply my own version if and as needed. A good example of something like that is SQLite. Actually having the source code and compiling it in reduces my inherent paranoia to a somewhat duller roar.
I've fallen off your lawn, and I can't get up.
Herb Sutter responded to this on his blog (Sutter's Mill): http://herbsutter.com/2013/08/...
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.
But here's the catch: you're not supposed to know it all. C++ is like a large store where you go and "shop" just the features you need. You can keep it super simple and write C-style code and just use classes as the only C++ feature, if you want to.
That is fine if you are a team of one, and you never read code written by others.
Err, the implication is that you can also write C++ that is not guaranteed to be maintainable by anybody short of a complete master, which even Bjarne says he is not. I think it is fair to estimate that the number of complete C++ masters in the world is in the single to double digits; no more. It may be you can identify another programming language for which that holds true. I don't think I can.
Other successful computer languages do not have that problem. Any competent C programmer can maintain any C code, and the same for python and Java. Perl is arguable; the problem is not complexity but opaqueness.
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.
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.
I am TheRaven on Soylent News
with some new features like function return type deduction,
Hey, K&R C had function return type deduction back in the 70's .
...of course it always guessed "int", but IT HAD IT.
From the "re-inventing C++" department... :)