| |||||||||||||
A look at C++14, part 1A look at C++14, part 1Posted Mar 28, 2013 16:14 UTC (Thu) by tchernobog (guest, #73595)In reply to: A look at C++14, part 1 by rriggs Parent article: A look at C++14, part 1
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| ()".
(Log in to post comments)
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...
|
|||||||||||||