| |||||||||||||
Good grief.Good grief.Posted Mar 28, 2013 17:50 UTC (Thu) by oldtomas (guest, #72579)Parent article: A look at C++14, part 1
Is there an opposite of "syntactic sugar"? Syntactic salt or even syntactic vomicum?
What an ugly language.
(Log in to post comments)
Good grief. Posted Mar 28, 2013 18:31 UTC (Thu) by mpr22 (subscriber, #60784) [Link] I use "syntactic salt" for what I merely dislike, and "syntactic ipecac" for what I find downright emetic.
Good grief. Posted Mar 29, 2013 1:32 UTC (Fri) by robert_s (subscriber, #42402) [Link]
The worst habit c++ standards seem to have got into lately has been the
"Ok, new feature: what character haven't we used yet that won't be ambiguous in this context?"
attitude.
"Got it: |"
...
> const type| input. The '|' being a new type qualifier, for input types.
Wonderful.
Good grief. Posted Mar 29, 2013 5:01 UTC (Fri) by HelloWorld (guest, #56129) [Link]
The | is used in that example as it always was: as an overloadable binary operator. And the reason why it (as opposed to some other operator) was chosen is also clear, it's clearly inspired by Unix shell pipelines. So I don't really follow your reasoning here.
Good grief. Posted Mar 29, 2013 9:31 UTC (Fri) by oldtomas (guest, #72579) [Link] Actually I wasn't complaining about the (pipeline::from() ... ).run(&threadpool) business.
Actually (for me, at least: I know it's a matter of taste), it's the juxtaposition of this very idiomatic | sugar to that very C++ish (...).run(&foo) what conjures up images of Komodo dragons with lipstick on them. Shudder.
Good grief. Posted Mar 29, 2013 14:07 UTC (Fri) by tchernobog (guest, #73595) [Link]
But that final "run (threadpool)" is exactly the beauty of the whole thing. The pipeline can be stored and ran at a later time; it is an object which retains a closure, and it can be further composed, transformed, etc. before being executed.
This programming style has been adopted in a lot of different languages and situations. Ruby on Rails uses something akin to this with AREL SQL queries. Haskell uses monads and monad transformers everywhere; every program starts in the IO monad and is just the composition of action, that are not evaluated unless needed due to the lazy nature of the language.
This allows, as already explained, for massive parallelisation and memoization, enforcing a good design from the developer to allow for maximum benefit and least effort. Calling:
std::pipeline p = std::pipeline::from (input) | std::bind (sed, "...") | ... | ... ;
would be the other less object oriented option, but I'm sorry if I don't see the point.
Good grief. Posted Mar 29, 2013 11:20 UTC (Fri) by robert_s (subscriber, #42402) [Link]
If you read the article you'd see that my quote was from a different proposal, that of "Pass by const Reference or Value".
|
|||||||||||||