The newest release of C++ has been characterized by Bjarne Stroustrup as "the completion of the work that became C++11". Mark Nelson discusses some new features in C++14, including the use of the auto keyword as the return type of a function, auto as the data type for lambda function parameters, and "capturing" external variables by reference for use within a lambda function. Nelson also mentions some minor, fit-and-finish features including the deprecated attribute, and digit separators for long integer literals, which will be familiar to programmers in languages such as Java and Perl.
An intro to C++11 lambda functions is here.
Nelson was the author of one of the first books on STL (and still one of the best, though it is out of print; worth trying to snag a copy IMO).
(Score: 3, Informative) by dublet on Wednesday September 24 2014, @06:03PM
I'm really quite ambivalent about the 'auto' keyword. On the one hand it's so convenient to not have to type really long things like "std::map<std::string, std::vector<int>>::iterator i" but the implicit conversions are really quite troubling in my mind. I've seen enough legacy code where a subtle type change can result in a major bug but implicit conversions don't make this obvious. Yet every time I can see myself typing it because it's so much shorter.
"If anyone needs me, I'm in the angry dome. [dublet.org]"
(Score: 3, Interesting) by TGV on Wednesday September 24 2014, @06:24PM
Personally, I don't mind longish types. There's always typedef. I do like to refactor-by-compiler-error, as a friend of mine dubs it: if I want to change some substantial bit of functionality, I change names and types in the API, and follow the compiler errors. auto is not your friend in those cases, as dublet points out. But modern C++ code looks like something from the nightmares of a keyboard designer. Some code is littered with stuff like this "typename std::decay::type retval = std::forward(d)". I guess C# does have it's advantages.
(Score: 2) by frojack on Wednesday September 24 2014, @06:39PM
Ah the old "compile till its programmed" technique, usually followed by the "test-till-its-designed" stage.
[lawn-mode] I remember when we were lucky to get one compile per day on our three trays of Hollerith cards. Any attempt to sneak in an extra compile would invariably result in an operator floor sorting your deck. Floor sorts could be prevented for 3 months by delivering a paper box containing two inches of random printout covering a six pack of operators favorite brew.
[/lawn-mode]
No, you are mistaken. I've always had this sig.
(Score: 2) by TGV on Wednesday September 24 2014, @08:26PM
No, not compile till it runs: refactoring by making the current code that is involved semantically wrong. Suppose you suddenly need to make sure that the argument for function a() is the output of function b(). Then you can change the type of b to some new type. Instances of a(b(...)) will pass unhindered, but just passing an argument to a() will lead to a compiler error. Actually, this is a case where auto comes in handy. Dammit.
(Score: 2) by frojack on Wednesday September 24 2014, @09:08PM
Yes, I quite understand and do the same thing.
I thought it was clear my post was in jest. I'll be sure to include a smiley next time.
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @06:39AM
Ah, such a whippersnapper. I remember having to use butterflies.
(Score: 1) by tkd-physics on Wednesday September 24 2014, @08:12PM
The general consensus (Sutter, Meyers, etc) is that auto should be used everywhere except where A) you want an explicit type (e.g. it's a cast operation), B) it gives the wrong type (initializer lists, proxy objects), or C) it's confusing to the reader.
I don't think auto can give rise to implicit casts, that's kind of the point. You need to not use auto when you want an explicit cast. Using auto can help prevent subtle type change bugs, because there's no type change.
The only subtle bug I can think of is constructing a proxy-type object when you didn't want to, and 99.9% of the time, this leads to compile-time errors.
(Score: 3, Interesting) by Teckla on Thursday September 25 2014, @02:50PM
The general consensus (Sutter, Meyers, etc) is that auto should be used everywhere except where A) you want an explicit type (e.g. it's a cast operation), B) it gives the wrong type (initializer lists, proxy objects), or C) it's confusing to the reader.
I think developers will start running into (C) a lot.
When you are reading, maintaining, and enhancing code, it's nice to know right there and then what the type is. "auto foo = bar();" is frequently going to force developers to stop what they're doing and go look up the foo() function to see what it returns. A good IDE can help, too, but even asking your IDE what foo() returns is a distraction. It's better to have the type right there and then, even if it's extra typing.
(Score: 3, Funny) by E_NOENT on Wednesday September 24 2014, @06:34PM
Oblig.
http://i.imgur.com/WdkCT6P.png [imgur.com]
I'm not in the business... I *am* the business.
(Score: 2) by Subsentient on Wednesday September 24 2014, @07:11PM
I like to say that nobody can know C++, because it's too big. So they made it bigger. Great.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 2, Interesting) by tkd-physics on Wednesday September 24 2014, @08:21PM
It gets bigger because the standards committee regards backwards compatibility as a major feature. If you want code written 20 years ago to compile and run, you can't make the language smaller.
What they have done is make the part of the language you actually use smaller and simpler by introducing new constructs. You can still use goto (it's still in the language) but you don't. The size of the language grows by necessity, the size of the language you really need to understand shrinks. No problem there.
I know most of the language, but them I'm an expert. You don't have to be an expert to use the language effectively. Several intro-to-programming textbooks have been written using C++ (Stroustrup, Koenig, Glassborow, maybe others).
"Bigger problem"? I say smaller problem.
(Score: 1) by SunTzuWarmaster on Wednesday September 24 2014, @09:35PM
While I agree with you in principle, I disagree in practice.
While the language of new use has gotten smaller, the language of total use has gotten larger. One of the primary features of C++ is the backward compatibility, which means that code from 20 years ago is still around. I like to joke that nearly 100% of the code I've written professionally is still in use.
There are people who are debugging 20+ year old code, and must have knowledge of archaic language features in order to do so (I know I've seen a goto!). While the "old hands" benefit from the new language features, it establishes a higher barrier to entry for new C++ programmers, who become progressively more likely to select a different language (python, java) to solve the programming problems of their day.
Note: I still think its for the best.
(Score: 2) by Teckla on Thursday September 25 2014, @02:54PM
The size of the language grows by necessity, the size of the language you really need to understand shrinks. No problem there.
This is only true if (1) you never read, maintain, enhance, or debug "old" code, and (2) if your company has very, very disciplined developers and coding standards well thought out and strictly enforced.
In the real world, (1) and (2) are almost never true. C++ is a disaster.
(Score: 2) by istartedi on Wednesday September 24 2014, @11:27PM
I was going to joke that they could solve this problem by adding regex to it, but apparently they already did [stackoverflow.com]
Appended to the end of comments you post. Max: 120 chars.
(Score: 2) by darkfeline on Wednesday September 24 2014, @07:28PM
Does anyone have any tips on where to start learning C++? I'm used to languages like C, Python, or Go, where the entire language spec can be easily and quickly read and understood, whereas C++, as far as I've heard, is just a massive conglomerate of disjoint features, and good luck figuring out any magic behavior!
Join the SDF Public Access UNIX System today!
(Score: 1) by Shimitar on Wednesday September 24 2014, @07:38PM
The original c++ is nice albeit the std library is a clusterfuck of unreadable but very usefull stuff...
After a bit they started making c++ just a mess.
Coding is an art. No, java is not coding. Yes, i am biased, i know, sorry if this bothers you.
(Score: 2) by PizzaRollPlinkett on Wednesday September 24 2014, @07:46PM
I started learning it in 1993, and still haven't figured it out. I think it's hopeless.
(E-mail me if you want a pizza roll!)
(Score: 2, Funny) by turgid on Wednesday September 24 2014, @07:52PM
Have a look at this old chestnut [yosefk.com] before you invest any time.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 1) by tkd-physics on Wednesday September 24 2014, @08:35PM
Yeah, people bring that site up for every C++ related article. It was thoroughly debunked as trollbait years ago. For a relevant usenet discussion, see https://groups.google.com/forum/#!searchin/comp.lang.c$2B$2B.moderated/Frequently$20Questioned$20Answers/comp.lang.c++.moderated/hw0VxX6DH8U/LK72V279aFgJ [google.com]
(Score: 1) by turgid on Wednesday September 24 2014, @08:48PM
Trollbait?
I think it's a very insightful piece of polemic. It's very useful.
C++ has become a bit of a religion. It's followers seem to look down on the non-believers with condescending pity and I avoid the C++ community (and the language when possible) because their discussions always seem to end in absurdity.
Life's too short for C++. I know enough to get by. All the old timers I meet, some very intelligent and highly-accomplished Software Engineers who've written compilers for various languages, hacked on the kernels of various unices since the 16-bit days and written real-time multithreaded code on tiny embedded systems are all critical of C++. They are willing to admit that it has some good features, and some even use C++ when they think it appropriate (but often that's only because some pointy-hair decreed it).
The general consensus on C++ is that it's too big, solves many of the wrong problems, introduces far too many subtle opportunities to create new kinds of bugs, the syntax is absurd, the libraries are daft, it's slow (and difficult) to compile, it "hides" the wrong things and exposes needless complexity and - worst of all - it makes a subtly broken attempt at backwards compatibility with C. And don't get me started on linking C++ libraries with code written in other languages.
In the real world, anything important gets written in portable ANSI C or a proper high-level language (i.e. not C++).
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Wednesday September 24 2014, @09:57PM
Life's too short for C++, but somehow it's long enough to sit there waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, waiting, and waiting some more for some goddamn slow-as-all-hell Java or Ruby app to do its thing? I don't think so! Give me software written in C++, or don't even bother! I don't have time to waste on slow Java or Ruby crap.
(Score: 1, Interesting) by Anonymous Coward on Thursday September 25 2014, @06:55AM
That's my opinion of *COMPILING* C++, especially on newer compilers.
For all their talk about performance, both clang and g++ seem to get slower with every new revision, no matter what optimizations you do or don't compile the compiler with.
Give me gcc-2.95.3 and C++98 code and I'd be modestly happy with compile speed. Not to say I like either g++ or libstdc++-v2, but goddamn, everything since 3+ has had at least 2-3 ABI breakages per major revision, plus has seemly doubled in compile time. (I exaggerate, but only slightly. If it's not compile time, it's memory requirements, making it basically impossible to compile anything above a trivial modern C++ app on an older system. Go see how many modern *C* programs you can't compile. Short of a 64 meg or less system, you can probably pull off most of them!)
Additionally it seems like the errata of compiler bugs is getting ever longer, and by the time any of the language standards is getting close to mature, bugfree, performance, etc, they've dumped us with a new standard leading to a bunch of new broken features and subtle quirks in the interactions of old ones.
Anybody else feel similiarly?
(Score: 0) by Anonymous Coward on Wednesday September 24 2014, @10:11PM
You must live in a different real world than me. I do image processing (i.e. lots of data to pump around, memory layout extremely important) and 99% of the code I see is some mixture of C and C++ varying between pure C, C-ish C++ and pure C++. I have not yet found another language where I can do what I need to do (except maybe write the high level stuff in some more high level language and fall back to C++ for the data-crunching).
I tried java (using large amounts of memory in java is asking for trouble), c# (not portable enough, mon and large amounts of memory don't go well either), pascal (haha), even some FORTRAN (blazingly fast in some cases, but even C++ is elegant by comparison), Python (nowhere fast enough, hopeless with multithreading), ruby (couldn't get the hang of it, needed to put lots of stuff in C for speed).
So pretty please tell me this magical language which is so much better than C++ that everybody uses it. I'd *love* to use a language with less warts but just as fast/efficient.
(Score: 2) by mtrycz on Thursday September 25 2014, @12:18PM
I have an idea. We start a fork of C++ that has sanity built-in. Usefull, modern features, without the cruft of backwards compatibility (hence C--).
How about it?
In capitalist America, ads view YOU!
(Score: 2) by c0lo on Thursday September 25 2014, @01:17PM
If you want sanity in C++, you need to drop:
- templates
- left side assgns, references to objects and maybe the const modifier for objects
You finish with "C with dynamically allocated classes" or "ObjectiveC with maybe other syntax".
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 1) by hendrikboom on Wednesday October 01 2014, @02:33AM
There's already a language called C--. It's an object-code language, lower-level than LLVM.
(Score: 2, Informative) by tkd-physics on Wednesday September 24 2014, @08:28PM
I quite like Accelerated C++: Practical Programming by Example By Andrew Koenig and Barbara E. Moo. It's a short, readable, and surprisingly complete. AFAIK it was the first to start from a "modern" C++ point of view, by introducing std::vector and std::string first, and leaving gruesome details about char* until later.
You could also look at two books from Stroustrup:
"Programming: Principles and Practice Using C++" and "A Tour of C++". I think the first is an introductory programming text, the second is a look at the language for people who already know how to program but don't know the language.
Ignore the trolls who complain that it's too complicated to use. It's not perfect, but then no other language is either.
(Score: 1) by turgid on Wednesday September 24 2014, @08:54PM
Ignore the trolls who complain that it's too complicated to use. It's not perfect, but then no other language is either.
You'll be a far more productive person by producing a larger number of more useful and less buggy programs if you stay away from C++.
In order to get any good at C++ you will have to invest your entire life. All that time could be better spent honing your C skills and learning some much more modern high-level languages.
Unless you want a career in C++ programming...
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Wednesday September 24 2014, @09:27PM
You're a bit of a cock, really, aren't you?
(Score: 2) by turgid on Wednesday September 24 2014, @09:35PM
Whenever the Central Scrutinizer appears, he must be challenged. Today he is manifest in tkd-physics,
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Wednesday September 24 2014, @10:11PM
pascal++
(Score: 0) by Anonymous Coward on Wednesday September 24 2014, @10:41PM
The standard introductory book for experienced programmers (2+ years, preferably in a strongly typed language such as Java/C#/Pascal/Fortran) is C++ Primer by Stan Lippman, now in its 4th edition.
Scott Meyer's "Effective C++", which is also revised every few years to incorporate new language features, is one of several good books for intermediate C++ programmers.
Some people have said good things about Bruce Eckel's "Thinking in C++", which has the advantage of being available online as a PDF, with the author's blessing. I haven't read Eckel's book, though. Another good online resource is Marshall Cline's C++ FAQ (not the "FAQ" posted in this thread by detractors of the language).
(Score: 0) by Anonymous Coward on Wednesday September 24 2014, @11:43PM
strongly typed language such as Java/C#/Pascal/Fortran
You mean statically typed languages?
http://en.wikipedia.org/wiki/Strong_and_weak_typing [wikipedia.org]
Strongly typed languages also include Ruby and Python.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @01:18AM
usefully strongly typed language
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @01:45AM
usefully strongly typed language
Ruby is more strongly typed than C++. You can't do this with Python,
int foo = 0x110010;
short second_byte = *(reinterpret_cast<short*>(&foo) + 1); // second_byte now 0x11
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @02:34AM
Ruby and Python are not useful system programming languages; C++ is, although C is more commonly used for kernel mode programming.
(Score: 2) by Teckla on Thursday September 25 2014, @02:57PM
I'm used to languages like C, Python, or Go, where the entire language spec can be easily and quickly read and understood ...
I must disagree that the C standard can be "easily and quickly read and understood".
C has something like 200+ or 250+ undefined and implementation defined behaviors alone. Do you have them all memorized?
I didn't think so.