| |||||||||||||
A look at C++14, part 1A look at C++14, part 1Posted Mar 28, 2013 14:28 UTC (Thu) by rriggs (subscriber, #11598)Parent article: A look at C++14, part 1
It's a little early for April Fool's jokes, isn't it? There's no way you'll ever be able to do something that cool with C++.
If you tell me that the compiler diagnostic on any pipeline error is required to be 20 pages of template instantiations, and that it is impossible for code editors to determine the meaning of such a line before the heat death of the universe, then I might believe you.
(Log in to post comments)
A look at C++14, part 1 Posted Mar 28, 2013 16:06 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
I wonder if someone just got jealous from the Haskell libraries such as enumerator, iterator, and pipe. Though they're even more generic (backwards flow and query/response for some). Of course the types in Haskell are scary, so C++ would be even worse. Maybe Boost will do it now...
A look at C++14, part 1 Posted Mar 28, 2013 16:14 UTC (Thu) by tchernobog (guest, #73595) [Link]
Well, it isn't rocket science. You would just need to override operator| () for a std::pipeline class, and add a run () function. Binding the first argument to a function is already in place, look at std::bind and std::function from header <functional>.
It is just a simple monad, with "run" being the execution function for the actions bound through "operator| ()".
A look at C++14, part 1 Posted Mar 28, 2013 20:05 UTC (Thu) by ledow (guest, #11753) [Link]
Rocket science, to a rocket scientist, looks just as simple.
Personally, even the explanation of the "non-rocket-science" is enough to put me off. Seriously, read it back to yourself.
Not saying that it's not simple, or not something you could learn, or even not something that could turn into subconscious mental boilerplate, but damn... programming languages are a language to enable communication with the computer - not to become an isolated language of their own that you have to be an expert to speak with any fluency.
A look at C++14, part 1 Posted Mar 28, 2013 21:39 UTC (Thu) by tchernobog (guest, #73595) [Link]
Nobody forces you to use the whole C++ language (or C++ at all, for that matters; C is there for you, as hundreds of other languages).
But for those of us who understand it, and want to use it, I can't see the damage of having this pipeline thing in the STL. To me, it's a very simple and nifty concept, and I would get a solid implementation of that done in a couple of hours, from scratch. If you don't like it, it's just syntactic sugar over stuff you could do anyway in another, more verbose, way. Or rolling out your own solution; testing is up to you, then.
After all, even Java has a lot of parts that most college students will never touch. RMI, for instance, and the related naming services. But if you need it, it's there (and it's *incredibly* useful for a nice set of problems). Same applies to most languages out there.
I don't see why languages and their associated standard libraries should keep from evolving. To make life easier for some grumpy programmers stuck in the '80?
We develop more complex systems in 2013 than thirty years ago, and static verification is something a lot of us need in the realm of software engineering, so we build the abstractions that enable us to spend a bit more in coding, and much less in QA (which, incidentally, is where real software development costs go).
The matter would be to explain what a monad is to university students, for instance, not holding back progress. Omniscience isn't required to use a language; C++ has many useful subsets for the issue at hand.
A look at C++14, part 1 Posted Mar 29, 2013 2:02 UTC (Fri) by geofft (subscriber, #59789) [Link]
Rocket science is complicated, but plenty of non-rocket-scientists fly airplanes.
The question isn't how hard the language is to implement -- it's how hard the language is to use. This looks straightforward to use, in my eyes.
A look at C++14, part 1 Posted Mar 29, 2013 9:18 UTC (Fri) by Wol (guest, #4433) [Link]
Rocket SCIENCE is easy. Rocket *technology* is hard.
Rocket science is a tube closed at one end, with a supply of two fuels which (spontaneously?) burn when mixed. THAT'S IT!
Rocket technology, on the other hand, is concerned with making sure you don't get too much fuel too quick (explosion) or too slow (rocket doesn't fly), and the controls to make it fly in the right direction, and launch safely etc etc etc.
Rocket SCIENCE is EASY!
Cheers,
A look at C++14, part 1 Posted Mar 29, 2013 10:29 UTC (Fri) by mpr22 (subscriber, #60784) [Link] Don't even need two fuels; one can build a liquid-fuel rocket motor that runs by the catalytic decomposition of hydrogen peroxide or hydrazine.
A look at C++14, part 1 Posted Mar 28, 2013 22:35 UTC (Thu) by nix (subscriber, #2304) [Link]
I wrote something similar for C about ten years ago. It is extremely useful, in all sorts of unexpected places. (Just like Unix pipelines are.)
A look at C++14, part 1 Posted Mar 28, 2013 23:47 UTC (Thu) by tpo (subscriber, #25713) [Link] Pipelines start to be really exciting, when they auto-parallelize their individual stages. If you have that, you can start doing CSP style programming, which spares you a lot of the pain shared state concurrent programming would cause you. Does your implementation provide nice syntax (via a macro?) and do autoparallelization? I'd would love to see that code... :-) *t
A look at C++14, part 1 Posted Mar 29, 2013 15:43 UTC (Fri) by nix (subscriber, #2304) [Link]
It didn't provide particularly nice syntax: it just provided a way to chain functions onto the stdin, stdout and stderr (optionally combined) of fork()/exec()ed subprocesses, so it looked like execl() with extra arguments jammed on the start to signify the stdin / stdout / stderr functions (if any: if none, /dev/null got attached to that fd instead). No pretty pipelining unless you invoked the function again in the stdout or stderr functions. But, obviously, the thing was parallelized: it was just pipes under the surface, after all.
This proposal is definitely better than what I hacked up. :)
A look at C++14, part 1 Posted Mar 29, 2013 18:49 UTC (Fri) by guillemj (subscriber, #49706) [Link]
Also for C, there's <http://libpipeline.nongnu.org/>.
A look at C++14, part 1 Posted Mar 31, 2013 14:08 UTC (Sun) by nix (subscriber, #2304) [Link]
That's a nice API. I'll definitely be using that, although its being GPLv3 (not even GPLv2+) greatly restricts the set of projects that can benefit from it...
A look at C++14, part 1 Posted Mar 28, 2013 17:22 UTC (Thu) by hummassa (subscriber, #307) [Link]
This is actually possible today, with C++11...
A look at C++14, part 1 Posted Mar 28, 2013 23:38 UTC (Thu) by tpo (subscriber, #25713) [Link]
* pointer ?
A look at C++14, part 1 Posted Mar 29, 2013 5:26 UTC (Fri) by rriggs (subscriber, #11598) [Link]
It might not be obvious from the tone of my post, but I was being rather facetious. I love C++. But like most C++ programmers, there is a bit of a love/hate thing going on. I love that C++11 rocks. I hate that I cannot yet write C++11 on RHEL. The "experimental" nature of the shipping C++11 compilers and the ABI incompatibility with C++98 libraries on Linux make it a bit of a problem for long-term stability.
Tell me again why GCC had to take on all the ABI breakage with the new standard?
A look at C++14, part 1 Posted Mar 29, 2013 14:09 UTC (Fri) by foom (subscriber, #14868) [Link]
Well, it's actually not broken much, yet. The std::string and std::list classes are still not C++11 conformant right now, and fixing that will certainly cause ABI issues.
Since the change to std::list in C++11 mode was reverted (it was incompatible in 4.7.0 and 4.7.1, reverted in 4.7.2), I've been using C++11 code against C++98 libraries without a problem.
A look at C++14, part 1 Posted Mar 28, 2013 17:59 UTC (Thu) by nelson777 (guest, #90117) [Link]
Ok people got frustrated.
You got 2 options: admit that you are less capable than an average C++ programmer or understand that C++ is a language made by humans for humans and not for some divine creature that has this special powers that makes him understand C++. I hope you choose the 2nd option. In case you choose it, remember 2 things: you ARE capable of understanding it and using it, if you just have some persistence and not give up in the first frustrations. The effort is rewarding. The power C++ gives to the programmer is second to none. If you need some begginer material I`ll be glad to point the directions to you.
A look at C++14, part 1 Posted Mar 29, 2013 1:08 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> It's a little early for April Fool's jokes, isn't it? There's no way you'll ever be able to do something that cool with C++.
> > If you tell me that the compiler diagnostic on any pipeline error is required to be 20 pages of template instantiations, and that it is impossible for code editors to determine the meaning of such a line before the heat death of the universe, then I might believe you.
There's literally *nothing* even remotely complicated going on here. APIs similar to that one can be done even in severely restricted languages like Java (modulo some syntactic details, that is).
A look at C++14, part 1 Posted Mar 29, 2013 19:23 UTC (Fri) by danieldk (guest, #27876) [Link]
In fact, Java 8 has streams, which are fairly similar:
http://cr.openjdk.java.net/~briangoetz/lambda/collections...
Of course, conduits/pipes/... in Haskell are still more elegant ;).
|
|||||||||||||