Many thanks to Alex

Thanks Alex for the wonderfully written articles about some of the new features of C++ 11. Yes, my first response to C++ 11 was 'oh great more stuff for me to forget' since I'm old and cynical and the noggin feels like it is starting to 'leak' a bit.

However, after reading your articles and trying some code in MSVS 2013 I'm actually beginning to like some of the new features. Note I said 'some'. Some make the syntax worse than before but others are a welcome addition. Looks like 2013 doesn't support all of the new features so here is to hoping they fix that in future versions.

C++11 has truly revolutionized the language in many ways. Microsoft's support is still lacking, though, but you can see the progress in 2013 here: C++11/14 Core Language Features in VS 2013 and the Nov 2013 CTP - Visual C++ Team Blog - Site Home - MSDN Blogs
And for the upcoming 2014 here: C++11/14 Feature Tables For Visual Studio 14 CTP1 - Visual C++ Team Blog - Site Home - MSDN Blogs

I'm only learning it b/c I will likely encounter it at some point in the future either in maintenance or in a code review. :) I have to say the range based for loops are just...um...sexy...and are even better than C#'s super simple foreach. Lambdas...well....it was a nice try but they are ugly. I prefer C# lambdas. To be fair C# devs didn't have all of the history of C++ and syntactical issues to deal with when implementing lambdas in C#.

Well, I think we can all say that we can learn to live and fall in love with new syntax over time, as programmers ;)
I find C++'s lambdas much less confusing than C#'s, though. Perhaps because I am more used to C++ than C#.

I have been using both languages for a long time now so trust me when they update C# or .NET I have somewhat the same reaction. At the end of the day they are just tools and they both have parts I like and dislike.

What I really wish C++ would adopt is a C# LINQ equivalent syntax and support for reflection.

Since C++11 took so long to come out, how is it that C++14 is coming so much quicker?

Quote:

---

Since C++11 took so long to come out, how is it that C++14 is coming so much quicker?

---

O_o

I'd say a combination of politics and feature creep.

Many different groups had competing interest in getting their version of different proposals pushed to the standard. As you are surely aware, C++ is far from perfect. Different vendors developed incompatible fixes for some of the core language issues which of course means that different vendors wanted their version in the standard.

You can imagine the politics for "Who has the best fix?", but you also have compiler extensions, and some community members developed insanely complex extensions --often using "G++" as a foundation. Unfortunately, a lot of those extensions were developed in isolation resulting in many collisions--problematic when combined. How best to integrate vastly different extensions often required developing further extensions which resulted in yet more problems, and once all of those collision issues are fixes you still have to smooth out the wrinkles so that the features seem familiar and consistent with everything people were already writing.

You also have "Boost". The thing is, "Boost" is a great library; except that it totally isn't a library. Many dozens of different groups have worked on different libraries using the same or similar standard set by early "STL" implementations and the standard library as a foundation for moving forward. As "Boost" became a thing, "Boost" grew by absorbing many libraries. (I think recommended libraries to be distributed as part of "Boost" is still open to the public developers site.) "Boost" became massive. The C++ library is already very large, and many people wanted to include most all of "Boost" or similar in the future standard. "Boost" has a permissive license, but some vendors absolutely could not have just shipped "Boost", and even as a library you get the same sort of collision issues as above. Of course, a lost of people didn't want to include but a few scraps from "Boost". How much and where to add was just a ridiculously complex question.

Of course, politics and feature creep is also why the next standard has a shorted development cycle. The core changes in C++11 were contentious for a lot of reasons, but a lot of the core changes in C++14 are simply logical continuation of the C++11 features making them less problematic. You also have a standard committee who is more wary and tired of the political problems which arose due to the long wait so they intend a more rapid cycle simply to put the rubber seal, so to speak, on fixes and extensions as they evolve so that competing implementations have less time to become ingrained.

Soma

Quote:

---

Originally Posted by phantomotap

O_o

You also have "Boost". The thing is, "Boost" is a great library; except that it totally isn't a library. Many dozens of different groups have worked on different libraries using the same or similar standard set by early "STL" implementations and the standard library as a foundation for moving forward. As "Boost" became a thing, "Boost" grew by absorbing many libraries. (I think recommended libraries to be distributed as part of "Boost" is still open to the public developers site.) "Boost" became massive. The C++ library is already very large, and many people wanted to include most all of "Boost" or similar in the future standard. "Boost" has a permissive license, but some vendors absolutely could not have just shipped "Boost", and even as a library you get the same sort of collision issues as above. Of course, a lost of people didn't want to include but a few scraps from "Boost". How much and where to add was just a ridiculously complex question.

Of course, politics and feature creep is also why the next standard has a shorted development cycle. The core changes in C++11 were contentious for a lot of reasons, but a lot of the core changes in C++14 are simply logical continuation of the C++11 features making them less problematic. You also have a standard committee who is more wary and tired of the political problems which arose due to the long wait so they intend a more rapid cycle simply to put the rubber seal, so to speak, on fixes and extensions as they evolve so that competing implementations have less time to become ingrained.

Soma

---

I see. I did notice from doing internet searches that a lot of the new classes were concepts from boost. Thank you for the detailed explanation.

Do you think it would still be advantageous to learn boost? If that's not to general a question, I imagine it probably varies on a case by case.

Quote:

---

Do you think it would still be advantageous to learn boost? If that's not to general a question, I imagine it probably varies on a case by case.

---

O_o

The "Boost" library is, at heart, simply a collection of libraries vetted by a community released under a fairly permissive license. Ultimately, "Boost" is what it is by virtue of a "self-fulfilling prophecy". (In other words, it got popular because people saw it getting more popular thus saw fit to dedicate resources to extend the reach making it more sophisticated and portable which in turn increased the popularity.) Despite the press, a lot of other libraries exist that are equal to the same tasks having the same level of expertise behind the development.

With that in mind, I only have one bit of advice. When the C++11/14/future standard library offers the same or similar component to what "Boost" offers without requiring a core language extension, you should prefer to learn the standard. Again, you should prefer the standard library version if the new or a upcoming standard library offers a component which is usable without a core language language extensions. (For example, a nearly complete public domain "single header" version of the C++11 shared pointers exists which works fine with C++98 compilers.) The reason is simple: many shims/"polyfills"/whatever are available in a variety of libraries and licenses allowing you to rely on those standard components without specifically requiring "Boost" or C++11/whatever compilers.

Otherwise, you should pick and choose your libraries according to your interests. "Boost" is a great library, and you will not be put wrong to learn any of its components you find useful, but I could say the same for literally hundreds of others.

Soma

Quote:

---

Originally Posted by Alpo

Do you think it would still be advantageous to learn boost? If that's not to general a question, I imagine it probably varies on a case by case.

---

Personally, I would check to see if the functionality I need is already available in the standard library. If not, then I will search for existing libraries online, and one of the first places to look would be the Boost libraries.

Of course, this works when you have a particular problem to solve. If you're looking for a better way to do certain things that may not have crossed your mind before, then you could always read the descriptions of the various Boost libraries to see if any strike you as interesting.

Quote:

---

Personally, I would check to see if the functionality I need is already available in the standard library.

---

O_o

Ninja'd!

Got you by a few seconds.

[Edit]

Quote:

---

laserlight likes this.

---

I think this "like" is the only one I've got from you when I wasn't being silly.
[/Edit]

Soma

Quote:

---

Originally Posted by Alpo

Since C++11 took so long to come out, how is it that C++14 is coming so much quicker?

---

Also, interest in C++ spiked after C++11. As far I know, it kind of slumped as it dragged on. One of the biggest problems with the standard is that it's comprised of a group of volunteers. They don't always have time and meetings where things are actually decided are few are far between. After C++11, a lot more companies/people/volunteers became interested in helping out on C++. Also, with the new standards (C++14 and forward), the committee is doing a new approach. They are spinning out features into technical specifications, so as to not tie them to the standard, hence making it faster to roll the standard forward, incorporating those technical specifications deemed ready.

Quote:

---

Originally Posted by phantomotap

O_o
With that in mind, I only have one bit of advice. When the C++11/14/future standard library offers the same or similar component to what "Boost" offers without requiring a core language extension, you should prefer to learn the standard. Again, you should prefer the standard library version if the new or a upcoming standard library offers a component which is usable without a core language language extensions. (For example, a nearly complete public domain "single header" version of the C++11 shared pointers exists which works fine with C++98 compilers.) The reason is simple: many shims/"polyfills"/whatever are available in a variety of libraries and licenses allowing you to rely on those standard components without specifically requiring "Boost" or C++11/whatever compilers.

Otherwise, you should pick and choose your libraries according to your interests. "Boost" is a great library, and you will not be put wrong to learn any of its components you find useful, but I could say the same for literally hundreds of others.

Soma

---

That is in line with what I was thinking. I'll have to at least take a look through boost to see if I'm missing anything. Thanks Soma, LaserLight.