Re: [boost] [Fit] Review

On Friday, March 11, 2016 at 1:02:15 AM UTC-6, Vicente J. Botet Escriba wrote:

Le 11/03/2016 07:18, Edward Diener a écrit :

...

On 3/11/2016 12:10 AM, Paul Fultz II wrote:

...

...

...

We can define functions by simply composing other functions together and

we

...

don't need to write awkward syntax nor template boilerplate for it. For example, we can simply write `make_tuple` like this:

BOOST_FIT_STATIC_FUNCTION(make_tuple) = by(decay, constructstd::tuple());

What is the type of by(decay,constructstd::tuple()) ?

It is something like `by_adaptorstd::tuple>`.

...

I thought I would be able to write locally:

auto make_tuple(by(decay,constructstd::tuple()));

but evidently you are saying that does not work.

That is not what I am saying at all. It can work, the functions can be used locally, like in the first example. However, for `make_tuple` this is not useful at all. If `std::make_tuple` was assigned to a local variable then no one could ever call the function.

I don't understand this. I have a 'make_tuple' callable above and if I want to use it somewhere else I pass it to whatever functionality needs it. You, instead want things to be global so that they can be used by other functionality without passing anything around. Isn't this just an argument about programming style ? I don't mind if you like your programming style but I doubt I am the first or last programmer who prefers variables created and used when needed. In fact I have a very strong suspicion that "my" programming style is that of the majority of C++ programmers and that only a minority of programmers like global variables even if they can be global within a namespace scope. So what I am essentially saying is that while I understand you like your style and your macros for creating "global" callables, inferring that this is central to using your library, when it is not AFAICS, is going to lose you end-users as well as misrepresent your library. I see much more plusses to your library if the result of using your adapters, decorators, functions, and utilities can be instantiated anywhere and used in ways that any variable in C++ can be used. if however there are real technical limitations, as opposed to "I like this style because I it is easier for me to use with Fit", of using Fit functionality to create "local" objects I think you need to spell out what those limitations are. Eduard, I don't know if you are aware of the Eric's paper [1] about customization points. In this papers Eric presents the technique use by Fit to define global function objects. These global variables have no modifiable state and are just like functions, but are high order functions. Eric received a very good feedback from C++ committee and AFAIK the range-v3 library [2] and the Range TS [3] are based on this technique.

I believe that it will be better if Paul show what is behind those macros by writing what the user could do without. E.g. the static_const ODR helper lets the user just write

I think I should add a section on "Declaring functions" that discusses this. In the Quick Start guide or introduction, it would be better to describe it as a declaring a function(which can refer to the "Declaring functions" section) instead of using the term global variable as it can be interpreted differently.

|constexpr auto const & begin = boost::static_const<__detail::__begin_fn>;|

Paul goes one step far, by defining some macros that help to do that.

This is to help portability and initialization for all platforms.

Best, Vicente

[1] N4381 - Suggested Design for Customization Points http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4381.html [2] https://github.com/ericniebler/range-v3 [3] N4569 - Proposed Ranges TS working draft http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4569.pdf

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost