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.
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.
I've fallen off your lawn, and I can't get up.
Intend to stay abreast of the spec, do you?
I've fallen off your lawn, and I can't get up.
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 and you don't have to use these new features to work...
So what is it?
use typedef's if you don't want to spend your time typing std::someType::some_const_iterator)
Why not just #define
"His name was James Damore."
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
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++ allows you to also write many things much more elegantly and safely than before.
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.
Read it again. There was no hate for COBOL there, just a recognition of the hate others express.
I liked a lot of the C++11 features. Lambdas, move semantics, std::mutex, and consistent initializers are all cool things.
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.
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.
When all you have is a hammer, every problem starts to look like a thumb.
Most of the people who complain about C++ are busy maintaining legacy C++ codebases, typically written before even C++98, making all of the worst possible decisions, ignoring best practices, etc. C is harder to make visibly screwed up, which is why people think it's better, even though it's really just that C makes it easier to write subtly broken code. For example, every obvious way to deal with integer overflow will break on particular sets of compiler optimizations, because C sticks it's fingers in it's ear and says "LALALALALA INTEGERS DON'T OVERFLOW LALALALALA I'M ELIDING YOUR SECURITY-CRITICAL OVERFLOW CHECKS LALALALALA".
C++ is C with classes. Templates didn't even come around until about after 1990.
Sheesh.
The Kruger Dunning explains most post on
// comments are in the c99 standard.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
You do understand that integer overflow is not buffer overflow, right? Integer overflow has absolutely nothing to do with security.
How would you assign a lambda to a variable without auto?
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.
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. Maybe they should just stick to their failed language and leave the rest of us alone?
The second problem (as if there were only two!) is that they don't update the language to reflect what people what people are doing with it, they update the language to reflect what they think people should do with it. That means adding features that no compiler can implement (like exported templates) or feature nobody can or should use (like std::vector<bool> or cout/cin). I think they've started getting a little bit better in this regard, adopting better parts of boost rather than just making shit up. And clang++ implements draft proposals and provides feedback. Of course they're still full of dumb ivory tower ideas like adopting cairo.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
> Integer overflow has absolutely nothing to do with security.
Yes it does. I take it you don't write much crypto code?
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
...but I am glad they are here!
(yes gcc has them already...)
4wdloop
concepts?
Doom 3 was written like that.
Yeah, that's a good point.
now we just need to throw the stone in the Marina Trench.
factor 966971: 966971
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
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? ...you are actually a genuine failuer. By the way, branding one of the most successful computer languages of the present day and all time as a "failure" does indeed make you look ignorant and bitter.
The second problem (as if there were only two!) is that they don't update the language to reflect what people what people are doing with it,
It's a balancing act. No one likes to use nonstandard features. They then add reatures which make writing the type of code that people actually write easier. So they do add features that reflect what people are doing with it.
That means adding features that no compiler can implement (like exported templates) or feature nobody can or should use (like std::vector or cout/cin)
My god, you're taking a few missteps from 16 years ago as why the committee today is bad? Is that the best you can do seriously?
And the only reason they put exported templates in is becuase of all the users clamouring for it.
Of course they're still full of dumb ivory tower ideas like adopting cairo.
Bsaically I've come to the conclusion that anyone using the phrase "ivory tower" is an angry, bitter, twisted person. Most likely both opinionated and stupid, but angry because no one will listen to their whitterings.
SJW n. One who posts facts.
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.
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.
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.
What kind of automatic garbage collection do you want? The tracing garbage collection 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 consistently. True, Java and Python provide syntactic sugar for the dispose pattern within a single block of code. But when an object's lifetime exceeds one block of code, such as when an object holds a reference to another object, the programmer's conceptual overhead of the dispose pattern is at least as large as manual object lifetime management in C++.
* CPython calls the __del__ method on anything not held cyclically because its reference semantics resemble C++'s std::shared_ptr, but other Python implementations can and do behave differently.
Before you go alleging "factual mistakes" over subjective matters, please try to pay attention. Ponder the difference between master and fair to decent practitioner.
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.
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.
Socialism: a lie told by totalitarians and believed by fools.
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.
Socialism: a lie told by totalitarians and believed by fools.
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 needed by someone, somewhere.
And if you're being deliberately obscure, well, others have mentioned the C obfuscation contest. No language is maintainable without at least some basic effort to reject needlessly obfuscated code through code reviews.
Socialism: a lie told by totalitarians and believed by fools.
For me auto makes the code more readable and maintainable while retaining strong type safety; the type is retained and enforced, it's just determined by the compiler. Having both class and struct on the other hand always struck me as a pointless idea. Having no explicit return type default to int but no explicit argument default to void - also silly. But auto being re-purposed I'm OK with.
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.
(stolen from DaBum) I am dyslexia of borg - your ass will be laminated.
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++ has no 'interface' keyword.
Socialism: a lie told by totalitarians and believed by fools.
Now, to drop it off a bridge, into the East River!
"Flyin' in just a sweet place,
Never been known to fail..."
...C++14 decays to N++14 as well.
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.
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.
You can definitely over-do auto typing to the point where a human can't figure out the types involved
Thing is, in most cases the human doesn't particularly care about the types involved. Provided that variables are named descriptively, I can look at a piece of code and figure out what it does, without having to determine whether "files" is a vector, a list or a deque, and whether the elements are raw, shared or unique pointers.
If you really can't live without it, there's always libgc.
This is an insufficient solution because std::function has a (small) bit of overhead compared to a raw function call. So it is not quite as efficient as simply using auto.
"If you don't have coding standards and a firm code review process to enforce them, you have already lost."
Haha. Processes are only as good as the people who implement them. Good code is the result of effort, not policy, and I've seen plenty of "lost" that came out of thorough coding standards and firm code review processes. Nothing overcomes crappy programmers.
"Any competent C programmer can maintain any C code..."
In my experience, this is far from true. Depends on the definition of "competent", but then that's true for C++ as well.
Processes are only as good as the people who implement them
Naturally. Your code is as good as the code review process, which is to say, as good as your people and how much they care.
Socialism: a lie told by totalitarians and believed by fools.
Sure, in simple code. But when you have crap like a list of labmdas that take a map and return a vector, or somesuch, because what you're doing is just like that, full type descriptions really help.
But that's rare, and I'd agree with you most of the time.
Socialism: a lie told by totalitarians and believed by fools.
C++ IDEs have also gotten much better, as well. In Visual Studio these days, you can hover over an identifier, and it'll tell you its actual type, regardless of how many levels of auto there are between it and the actual named type. And it works reliably on anything that is valid C++, no matter the complexity.
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.
I'm not sure that's true. I feel quite certain I can write Java or C code that others will have trouble maintaining (in fact, I already have)
"First they came for the slanderers and i said nothing."
I mean like supporting writing of shared objects without having to deal with inconsistent mangling approaches between compilers, having to resort to manually-maintained export files? Or having to use the exact same version of the compiler between the library and the code using it? Being able to expose functions throwing exceptions through a library (gasp! who wants to do that?) or to reliabily use an std container through the library interface?
Without all this, you can't write C++ code spliting the logic into multiple binaries in a platform-independant way...
This is the main reason why all libraries are still written in C, or at least expose interfaces in C.
Clang has some builtins that allow you to get the carry bit, so you can cheaply write code that branches on carry. We (mostly CERT, I helped a bit) had a proposal for inclusion in C11 that would have added qualifiers on integers explicitly defining their overflow behaviour as trapping or wrapping, along with a model that let this be implemented cheaply (e.g. allowing a set of side-effect-free code to propagate temporary results and only trap if one of them along the way overflowed). Sadly, it didn't make it into the standard.
I am TheRaven on Soylent News
I must confess I'm not a C++ master (more like a beginner). :)
But I have written code in many languages:
Assembly (x86, x64, AVR, ARM)
asp, asp.net
Basic (think Commodore 64)
Batch script
C
C++
C#
Clipper (anyone)
D
Delphi
Java
Javascript
Lua
Matlab
Pascal
Perl
Php
Python
Shell script
VB script
Verilog
VHDL
I have not yet used but I'm interested in F# and Go. (async and concurrent programming among other things)
I think C++ lacks certain features, native data types, and (a feel of) simplicity that other modern languages have.
For example I like Pascal style strings much more where you can determine it's length in O{1} time among other things (return, concate, resize). (same for arrays, where in C you have to pass length separately, and hope you won't cause buffer/stack overflow)
Template meta-programming is a great, sometimes magical tool
(which you can dig your grave with if you are not careful -- debugging, maintaining, understanding, editor intellisense).
I do not expect anyone to start programming in assembly, I wouldn't. Though there are High Level Assemblers out there, (the lack of) portability is a major disadvantage of it.
But I have not yet worked on a processor that had not supported carry flag, and I do not know any way to access it from native C code. (Lets say shifting a 1024 bit integer, adding, subtracting them....) Checking for integer overflow is also a pain in the ass (pre check/post check. And I have not found any way writing my code that would get the compiler to produce the right assembly.) Also on processors I worked on multiplying 2 registers results in a register pair because that't how multiplication works and extends the range of possible results (and this is why there is a carry flag used during addition), but C is blissfully or painfully ignorant of this (depending where you are looking it from) and this is usually where code readability starts going down the toilet when you are precasting integers and alike. (When you need to multiply two 32 bit int (and maybe then divide it so the result is still 32 bit), but you cast it to int 64 pre multiplication, will it result full 64 bit multiplication (software multiplication on 32 bit processor)?)
But I guess code efficiency does not matter and that is why we have longer response times now on GHz processors, than we had on 486... (and of course because of bling)
Reading code examples about why you need auto in the comments makes me cry. WTF is boost::asio::placeholders::bytes_transferred!? (It was a rhetorical question, don't answer it:)
This is what the improved readable code looks like?
So C is not close enough to hardware to understand it and generate efficient code, and not high level enough to abstract and understand things that humans would like to use naturally. We have to think in bits and clocks to write some broken codes.
I'm an embedded developer so I'm stuck with C (and C++) for now.
Good luck with your typedefs:
template<typename Range>
double mean(const Range& range)
{
double sum = 0.0; int count = 0;
for(auto& v : range) {
sum += v;
++count;
}
return sum/count;
}
Any competent C programmer can maintain any C code
OpenSSL is written in C. I am a competent C programmer. I don't think I could maintain that code base. The Open BSD people are probably more competent C programmers than me and they felt they couldn't maintain the code base without first ripping most of it out.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
It didn't make it for C++14, right? My understanding is that C++17 is where the "big things" are supposed to be happening - are you now aiming for that?
Cool - I haven't used VS for C++ since they grew up and added C99 support - I really should try it out.
Socialism: a lie told by totalitarians and believed by fools.
C99 support there is still more like 50% (no VLAs, no "restrict", and no complex/imaginary).
You were implying that using a subset of C++ features is not practical because you could "write C++ that is not guaranteed to be maintainable by anybody short of a complete master", which is absurd, because only a complete master could write that kind of unmaintainable code. Well, according to your logic and your subjectivity, there are only a small amount of people capable of that feat. And the fact that there are lots of C++ programs and libraries out there that are maintainable proves it.
We proposed it to WG14, not WG21. It's pretty trivial to add wrapping and trapping integer templates in C++.
I am TheRaven on Soylent News