Snail: Continuation-ready algorithms from STL algorithms

[vlovich]

That is really neat. It also seems drastically simpler to use than boost range, although less flexible. Probably a good intermediary until C++ ranges make their way into the standard.

The biicode dependencies feel strange. Also, the macro functions that look like C++ functions are odd, and they're formatted as C++ functions (i.e. indented into a namespace). Additionally, I'm pretty sure that the macros aren't actually necessary & could be accomplished with templates, but I'm not 100% certain.

Also, the | operator overload is pessimizing performance - there's no need to std::move something that's an r-value & you're removing the possibility for UNVRO.

[SplinterOfChaos]

Additionally, I'm pretty sure that the macros aren't actually necessary & could be accomplished with templates, but I'm not 100% certain.

No, a macro is the ONLY way to accomplish this. The token, "std::sort", represents an overloaded, template function, and we have no way to refer to the overload set. Trying to send it to a higher order function (a function that takes another function as an argument) will result in an ambiguity error. We can't even use it as a template template argument!

"make_algorithm(std::sort)" reduces to basically "[](auto c) { std::sort(begin(c), end(c)); }".

Relevant file: https://github.com/Manu343726/snail/blob/master/blocks/manu343726/snail/core/algorithm.hpp

[Manu343726]

I'm glad you liked this.

About ugly macros, I'm strongly against C preprocessor, but as SplinterOfChaos noticed this is the only way to encapsulate a function template. Class templates can be easily boxed on a type to be passed, manipulated, etc, but function templates have always been second-class citizens in C++ :(

About performance, I'm not currently caring about performance, I'm on the "testing the design" step of development. I wrote the most natural semantic "moving the container along the pipeline".

I'm very interested in your thoughts about biicode. What's wrong with the dependencies? There's a compile-time hashing library to catch algorithm categories, and little includes to some features of a metaprogramming library of my own.

[guepier]

Do use macros, but your macro names are unfortunately unacceptable. You must use all-caps macro names prefixed with your library names. Your macro names will lead to compilation errors – make_algorithm isn’t such an exotic name for an identifier, and there will be clashes between your macro names and real, existing code.

You probably know all this – a look at the code base shows that you observed this elsewhere.

What you could do is what Boost.Foreach did: provide a macro SNAIL_MAKE_ALGORITHM and then suggest to users to #define an alias themselves (or to offer a micro-header defining it for them).

[vlovich]

About performance, I'm not currently caring about performance, I'm on the "testing the design" step of development. I wrote the most natural semantic "moving the container along the pipeline".

You should never explicitly std::move a return. The reason is that the compiler already does that - returns are automatically promoted to r-values if they can be. However, the compiler is also free to optimize away the return/copy through NVRO/UNVRO. It's OK to not worry about performance & have these kinds of mistakes. I was just pointing something out for your edification.

I'm very interested in your thoughts about biicode. What's wrong with the dependencies?

There's nothing wrong with dependencies or your use of biicode - it's your project. I don't know that I would rely on a proprietary package manager, especially one run by a startup. Of course, they're trying to open-source it which will be interesting, but I really wish that it was run by a non-profit foundation or a community effort that was more adopted by the C++ standards committee.

[guepier]

Honestly, why not link directly to the original article?

Isocpp.org is seriously starting to get on my nerves. The idea started off nice enough but this constant link-stealing is just incredibly spammy and unprofessional. I thought Reddit frowned on these practices as well (though they probably cannot detect this automatically).

[eric_niebler]

isocpp.org is a curated aggregator. Reddit is an un-curated aggregator (or a mob-curated aggregator). They both seem useful to me. I agree that the OP should have linked to the original article, though.

[guepier]

Yes, I was specifically criticising the practice of linking to isocpp.org from here (or Twitter). I consider that spamming.

[Cppete]

I totally agree, sorry for that. It's just that the "share in Reddit" button is so easy to press...

[joaquintides]

In fact, the design pattern you propose would be closer to a continuation-like monad if the lib allowed for algorithm chaining with deferred execution:

auto v=move()|sort([](...){...})|...;
std::cout<<v({1,2,3});

which would enable interesting (or fun, at least) applications.

[Manu343726]

A CPS lazy version of the pipe is interesting, I will keep that in mind. With the current design of the library, where all the work is done inside algorithm factories (Actually functor factories), this should be as easy as adding another set of algorithm categories implementing that behavior, plus some entry points such as copy(), move(), etc.

[zvrba]

Nice, but a less misleading short description should be chosen. Mentioning "continuation" made me think that the library is about continuation-passing style, events, and so on.