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_adaptor
std::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 |constexpr auto const & begin = boost::static_const<__detail::__begin_fn>;| Paul goes one step far, by defining some macros that help to do that. 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