More Features Of C++14 Are Covered

[phoronix]

Phoronix: More Features Of C++14 Are Covered

C++14 is the next update to the C++ programming language. While only considered a minor update over C++11, it will bring with it several new features...

http://www.phoronix.com/vr.php?view=MTM0MDM

[hoohoo]

I think C++ is in danger of becoming Visual Basic: language level support for everything and the kitchen sink.

C, and to a great degree C++, is a great language because it defines exactly what is needed to write programs & libraries. The language spec does not clutter things up with every damned API or application that some programmer on the committee has a hankering for.

Leave the non-language stuff in libraries to be provided by people who offer services!

Example: wtf business does a MapReduce API have being in the C++14 spec? MapReduce is an algorithm that can be implemented in C++ - but also in Python, Ruby, PHP, Intercal!

[curaga]

You do have to make a distinction between language-level and standard library. What you mentioned would go to the STL, which you're free not to use. Similar to the huge standard library Java ships with.

[archibald]

What you mentioned would go to the STL, which you're free not to use.

Could you explain that comment? I've not heard about the STL not being free to use.

[vcunat]

Could you explain that comment? I've not heard about the STL not being free to use.

That's not what was written. There's a big difference between "being free not to use" and "not being free to use" :-)

[droste]

Could you explain that comment? I've not heard about the STL not being free to use.

You misunderstood him. He was saying that you don't have to use it. You can choose whether you want to use it or not.

[hoohoo]

You do have to make a distinction between language-level and standard library. What you mentioned would go to the STL, which you're free not to use. Similar to the huge standard library Java ships with.

Fair enough, STL.

Still I think some things don't belong in there, MapReduce again being a good example. People I know who use it build virtual infrastructure on AWS or Google's thing, and do big map reductions, or they do it on academic compute clusters. In every case the dependency of the algorithm's implementation on the h/w platform is quite strong. C++ 'std library' (what, say, GNU used to call libstdc++) or the STL do not normally take account of the platform except in the low level library code: the variability of platforms where big data algorithms are run would I think make a standard implementation difficult, even pointless.

Maybe I'm being a curmudgeon. Still I think 'standardizing' parallelism systems, async operations, and so on, will lead to ossification because either OS makers will write to satisfy C++'s requirement or hardware designers will do it. In either case the implication that there is a 'correct' way to do things will tend to discourage experimentation and innovation.

Language specifications should specify language (syntax, behaviour of operators and such), not verbiage (structure of programs or libraries or OS interfaces).

Anyways, that's my $0.02.

[curaga]

I agree that the STL is already too bloated, and adding several random generators to it is not helping.

I disagree about the parallelism though - it's great that something finally makes it to a standard, forcing it to be supported everywhere. Right now you have to pick something, binding you to a platform/compiler.

I don't particularly care about being required to use GCC or only getting proper parallelism on linux; windows users of my software can deal with being single-threaded; for VS users, here's a nickel, go get yourself a real compiler.
This doesn't mean I don't welcome a standard for parallelism; I think it's great. Having full support everywhere beats the status quo by a lot.

[hoohoo]

... for VS users, here's a nickel, go get yourself a real compiler. ...

LOL.

Nice IDE too bad about the compiler.