C++14 Is Set In Stone 193
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."
Stone (Score:5, Funny)
Wouldn't it more useful for it to be set in silicone?
Re: (Score:3, Informative)
C++14 Is Set In Stone? (Score:3)
Now, to drop it off a bridge, into the East River!
Still... (Score:4, Interesting)
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.
Re:Still... (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
A basic 'Hello World' program can not crash, and everything that has no input can't be made crash from the outside to a buffer overflow. 'Hello World' programs fall into that category.
I doubt you know all bugs of all JVMs that could a particular program of me make crash, if you only have acces to it from the outside, and would even go so far, you can not do it if you have console access.
And for that matter: it is hard enough to crash/abuse a C program if you can not debug/analize it.
Re:Still... (Score:5, Informative)
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: (Score:3)
Re:Still... (Score:5, Informative)
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
Re:Still... (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
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...
If you're really interested in readability you would probably define those bits, like:
#define HIGHSTUFF (0b001011 << 17)
#define NOTSOHIGHSTUFF (0b010011011 << 8)
and then or them together.
Alternatively you could define a macro for your bit field, like:
#include
#define bitfield(a,b,c,d) 0x##a##b##c##d
int main() {
printf("%x", bitfield(f,f,f,f));
}
Re: (Score:2)
> Now, one interesting thing in C++14 is binary literals (using "0b" a la "0x" for hex).
Hey, it only took ~40 years for a C based language to add binary literals! (It will only take another 40 to standardize pragmas such as struct packing.)
Using 0b is dumb. They should of used a letter that isn't in hex, say 0z1101.
Using '_' would of been nice but the C++ community doesn't really have a fucking clue about solving real-world problems. Witness ...
Herb Sutter looking into adding Cario 2D into C++
"http://de
Re: (Score:2)
Using 0b is dumb. They should of used a letter that isn't in hex, say 0z1101.
There's nothing dumb about it at all. First of all, the prefix 0b cannot be confused with a hex digit because you need the prefix 0x to get hex.
Secondly, if you're concerned about b looking like a hex digit, well, there's your problem. Lowercase hex digits are the devil's work. Always write hex digits using uppercase letters, as $DEITY intended.
Finally, what the hell is the z supposed to stand for in 0z?
Re: (Score:2, Funny)
Finally, what the hell is the z supposed to stand for in 0z?
He's probably a German speaker. Binary is Zeugenschutzprogramm in German.
Re: (Score:2)
Unknown. Pure madness lies that way so maybe the committee has come to its senses ...
One can always hope/pray/etc...
Re: (Score:2)
Re: (Score:2)
If you haven't seen this, you'll probably appreciate / enjoy this:
Smallest "Hello World" ELF: 142 bytes [timelessname.com]
Programs are so bloated today.
Re: (Score:3)
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...
What on Earth are you talking about?? Using C++ comments in C was a GCC extension that made it into C99.
Re: (Score:2)
Year, it is really annoying that 'computers' don't really contain metal any,ore now as all important parts are made from semi conductors, I feel your pain :-/
Re: (Score:3)
Re: (Score:2)
VC++2013 added a bunch more stuff from C99, aside from the library. On the language side, it's mixing declarations with code (C89 mode was strict and would bark at any variable not at the beginning of the function), _Bool, compound literals, and designated initializers.
The main things still missing are "restrict", _Complex and VLAs. However, the official target is now C11 rather than C99, and C11 made VLAs an optional feature of the language, because of lackluster support and use.
Re: (Score:2)
Re: (Score:2)
This is not entirely true - they have added a bunch of C11 features in VS 2013.
Re: (Score:2)
Ha. Funny. Thank you, didn't know that.
Re: (Score:2)
And also the bool type, and the ability to declare variables after the beginning of a function.
Re:Still... (Score:5, Interesting)
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.
Re:Still... (Score:5, Funny)
From the "re-inventing C++" department... :)
Re: (Score:3)
Re: (Score:2)
Support for your position (Score:5, Funny)
Intend to stay abreast of the spec, do you?
Re:Support for your position (Score:5, Funny)
You boob. Take your puns and go.
Re: (Score:2, Funny)
Re:Support for your position (Score:4, Funny)
Re:Support for your position (Score:4, Funny)
Did they make any changes in mammary allocation?
Re: (Score:3)
Yes, but it corrupted the malloc areola.
Re: (Score:2)
*silicon
Re: (Score:2)
Wouldn't it more useful for it to be set in silicone?
Assuming you mean silicon, then; no - Setting things in stone is better than writing them in the sand.
Re: (Score:2, Informative)
silicon isn't sand. It's found in sand and stone, among other places.
Re:Stone (Score:5, Informative)
Actually, its set in {La,}Tex: https://github.com/cplusplus/d... [github.com]
Re: (Score:2)
Sounds a bit wobbly. Maybe silicon instead?
Silicone? (Score:2)
I think you mean Sillicon
silicone:
Any of a class of synthetic materials that are polymers with a chemical structure based on chains of alternate silicon and oxygen atoms, with organic groups attached to the silicon atoms. Such compounds are typically resistant to chemical attack and insensitive to temperature changes and are used to make rubber, plastics, polishes, and lubricants.
Re: (Score:2)
Edit: Cant seem to spell Silicon properly. lol
Why do we need Auto? (Score:3)
Looking at C++14 I see a lot of expansion of the support of the auto type. I have not found a scenario where I perer auto, so I'm curious about such a large focus on it.
Re:Why do we need Auto? (Score:4, Informative)
Re: (Score:3, Interesting)
I used to think that, until I realized:
auto handler = boost::bind(&Class::write_callback, this, boost::ref(timer), boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred);
boost::asio::async_write(device, buffer, handler);
Iterators another good one:
typedef void (*FunctionPtr)();
std::map<std::string, FunctionPtr> knownCommands;
std::string command = "example";
std::map<std::string, FunctionPtr>::it
Re: (Score:3, Informative)
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
Re: (Score:2)
This does not address your question specifically, but C++14 fixes some glaring holes in C++11. Well, one hole for damn sure. They clean forgot to put std::make_unique in C++11, even though std::unique_ptr was there. The hole was obvious to anyone who saw std::make_shared and then went to try and look up its obvious complement.
It was also high time and way beyond high time they added binary constants. Frustrating as hell they STILL found it too hard to support binary formatting in iostreams, though. Evidentl
Re:Why do we need Auto? (Score:4, Informative)
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.
Re: (Score:2)
I use auto a lot. auto (or equivalent syntax) are used a lot in functional programming languages. Mostly in short functions where I do not really care what the proper typename is. It is clear how the variable behaves and that is I care about it. Often, I know I get some kind of iterator, but the actual type might not be easy to find. In particular, it might depend on a template parameter. So I guess I could add plenty of typedefs to get an easy to write type. But what is the point really?
Re:Why do we need Auto? (Score:5, Informative)
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.
Re: (Score:3, Informative)
Re:Why do we need Auto? (Score:5, Informative)
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: (Score:3)
C++ isn't strongly typed
Yeah it is.
Specifically reinterpret_cast. It's almost as unsafe, if not as unsafe, as good old C style casting.
Its exactly as unsafe. The difference is that it cannot happen by accident. You are telling the compiler, in very explicit terms that you WANT the reinterpret_cast behavior.
And strongly typed means you can't change the type.
Casting doesn't change the type of the thing being cast. It just lets you treat the thing being cast as if it were a different type. typeof(x) never cha
Where are my designated initializers? (Score:4, Insightful)
It's just pathetic that so many years down the road the committee can't get its act together to provide this much loved C99 feature at least for POD. This is a major issue, if not the major issue) with porting C code. The word wanking comes to mind. Here, GCC guys really need to take the lead but it's starting to feel like GCC guys are actually holding back on it. It's not like the coding is a challenge.
Re: (Score:2)
You want the committee to focus on practical problems?! LOL. You are more delusional then them! :-)
Recently they wanted to add a 2D graphics API to the language! Yeah, let's re-implement OpenGL ES.
http://developers.slashdot.org... [slashdot.org]
This is your typical design-by-committee of a "Solution looking for a Problem". God forbid we actually have _standardized_ pragmas like we do for OpenMP.
The committee has only one motivation:
"Job security by obscurity."
C++ has a become a total cluster-fuck of over-engine
Re: (Score:2)
Recently they wanted to add a 2D graphics API to the language! Yeah, let's re-implement OpenGL ES. http://developers.slashdot.org... [slashdot.org]
Zee wot? Cairo is nothing like OpenGL ES.
Re: (Score:2)
HEAR, HEAR!!! [Pounds fist on table repeatedly]. I have been dying for this since gcc added the nonstandard extension and then C99, seems a lifetime ago, codified it in the C standard. What the HELL, guys. With all the wang-yanking ivory tower crap they did implement in C++11 and 14, much of it very hard work to master using, let alone implementing, is there any way in hell you can blame us for calling you out on the immature assholery of not simply copying this dead-simple feature from C99?
This should have
Re: (Score:2)
Maybe it's not part of C++ because this kind of initialization is trivial to do, and more readable, with helper classes and constructors. Just a theory - I wasn't even aware of designated initializers.
What I find pathetic is all of the C programmers who still think C++ is slow, bloated, or impossible to understand.
Re: (Score:2)
Maybe it's not part of C++ because this kind of initialization is trivial to do...
It is a safe bet that you have never ported a C99 program of any significance to C++.
rodata vs. data section (Score:2)
this kind of initialization [performed with C99 designated initializers] is trivial to do, and more readable, with helper classes and constructors
A designated initializer for static data can initialize data in a read-only section. "Helper classes and constructors" mutate an object, which inflates the size of your program's read-write section.
Re: (Score:2)
Good point!
Re: (Score:2)
Of course, using .rodata has always been a Quality Of Implementation issue in both C and C++.
Then perhaps Tough Love's point is that an acceptable quality of implementation is achievable with less complexity with C99's way than with C++11's way. A language is only as good as its best free implementation.*
Copying everything to RAM is not an observable side effect, formally.
This is true given plenty of memory on the target machine, such as a modern desktop PC, but it becomes observable in a smaller machine. If your program uses more RAM, then the amount of work done per unit of std::time() decreases as it starts to dip into swap, or it catches an exception of type st
Re: (Score:2)
C++ is (usually) fast, bloated and almost impossible to fully understand.
What about (Score:2)
concepts?
Re: (Score:2)
Indeed! Where are concepts! These is the number 1 addition to C++ most of us need! I am sure that they were not added for a good reasons. But programming template is currently a nightmare because of the duck typing of the meta programming system.
Dear standardization committee, we NEED a solution to the template compile time debugging problem.
Re: (Score:2)
Syntactic support for generic programming would be the single best addition to C++ to breathe new life into the language and get a whole generation of developers who've written it off interested in it. Generic programming is as paradigm shifting as OOP. It just kills me that it's so t
C++ set in stone (Score:4, Funny)
now we just need to throw the stone in the Marina Trench.
Re: (Score:3)
Back to the future (Score:5, Funny)
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.
I wonder if... (Score:2)
Re: (Score:2)
I see a lot of people complaining about the complexity of the language. But it seems that no one dares to give any example. For my part (I had a 3-days introduction to C++, everything else was learnt by practicing) I don't find it really enormous. Aside from the auto (because type deduction = E.V.I.L., use typedef's if you don't want to spend your time typing std::someType::some_const_iterator), I fail to see what change is mandatory in the language structure. What you wrote few years ago is still correct a
Re: (Score:2)
use typedef's if you don't want to spend your time typing std::someType::some_const_iterator)
Why not just #define
Re:Oh god so what? (Score:4, Insightful)
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.
Re:Oh god so what? (Score:4, Informative)
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.
Re: (Score:2)
Re: (Score:2)
Well, you'd just need a chuckugly type declaration for it. The new ability to use auto in declaring the parameters to the lambda expression itself - that's one I don't see how you'd do without auto, as it's effectively templating in a place where you can't syntactically declare the template.
Re: (Score:2)
Re: (Score:2)
You can definitely over-do auto typing to the point where a human can't figure out the types involved, but that's just a team coding standards thing. For sure, auto is better than any type spec that doesn't fit on a single line in the editor. Obviously class v struct is a historical relic, but I like it. I use class and struct for different things - all members private in the former, vs all public in the latter. I also like the convention that struct is the right keyword to declare an interface, since C
Re: (Score:2)
Every lambda is of its own unique type. Even if you have two lambdas with the same capture-list and parameters, they're still of different types.
Re: (Score:2)
Re:Oh god so what? (Score:4, Insightful)
> Integer overflow has absolutely nothing to do with security.
Yes it does. I take it you don't write much crypto code?
Re:Oh god so what? (Score:5, Informative)
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.
Re: (Score:2)
It's a crying shame that C and C++ still haven't added safe arithmetic as part of the standard library (or in case of C, maybe even as part of the language, for the lack of operator overloading). Back when I first saw "checked" in C#, I wondered what this was supposed to be about, but I have since learned the wisdom of having it in the language.
Re:Oh god so what? (Score:5, Insightful)
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.
Re: (Score:2)
Read it again. There was no hate for COBOL there, just a recognition of the hate others express.
Re: (Score:3)
With one thing you are spot on: C++ has a massive feature set. Even Bjarne says that he has trouble mastering the full feature set at any given moment.
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.
Then again, modern C++ [msdn.com] allows you to also write many things much more elegantly and safely than before.
Re:Oh god so what? (Score:5, Interesting)
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.
Re: (Score:3)
Re:Oh god so what? (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
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.
You can not even identify one without resorting to factual mistakes. I'm running every day lots of programs written in C++. A simple search on a linux distro reveal thousands of packages in C++. Is that maintained by those "single to double digits" amount of people in the world? Sure.
Re: (Score:2)
Before you go alleging "factual mistakes" over subjective matters, please try to pay attention. Ponder the difference between master and fair to decent practitioner.
Re: (Score:2)
Thats incorrect. Look at the Obfuscated C Code Contest. You can write TOTALLY unmaintainable code in ANY reasonably powerful general purpose language. Such features are necessary to write good software, though of course, anything can be abused.
Re: (Score:2)
If you don't use obscure features of C++ just for fun, you won't have that problem. Most of the obscure features in C++ exist to solve a very specific sort of problem. If your job is to solve that problem, you already understand what the relevant C++ feature does - to you it's not obscure, it's quite handy and much cleaner to have in the language than to write an test yourself.
No one needs to master all the obscure crap, because there's no single software product than needs it all - but all of it is neede
Re: (Score:2)
C++ is C with classes. Templates didn't even come around until about after 1990.
Sheesh.
Re: (Score:2)
The problem (as if there's only one!) is that the c++ committee members only have one thing in common: They hate C!
No, they all like C++, that's the one thing in common.
So you get a mix of people trying to bolt their favorite features from cobol, haskell, java, etc onto C. You know, to improve it.
You're an idiot and you've never clearly never followed the C++ standards committee process. Basically you're bitter because...
Maybe they should just stick to their failed language and leave the rest of us alone? .
Dispose pattern (Score:2)
What kind of automatic garbage collection do you want? The tracing garbage collection [wikipedia.org] seen in Java and Python is fine for memory, but most programs access resources other than memory. Java and Python* don't guarantee that finalizers will ever be called. This means a program relying on automatic garbage collection leaks resources unless the programmer is disciplined enough to apply the dispose pattern [wikipedia.org] consistently. True, Java and Python provide syntactic sugar for the dispose pattern within a single block o