On Thu, Apr 3, 2008 at 1:53 AM, shunsuke <pstade.mb@gmail.com> wrote:
Giovanni Piero Deretta wrote:
You expect something like this?:
static_result_of<T_curry2(F)>::type c = BOOST_EGG_CURRY2({}); // static
Can't you use boost::result_of here? (or return_of)
As I mentioned, result_of needs to know whether or not an argument is lvalue or rvalue. result_of is standardized, so that I don't like to violate the law.
I still do not get it though. Could you show me exactly where you think the problem is? boost::result_of<F(T)>::type will return the type of the result of 'F()(T());' right? Once you know the type, and if you are sure that the type is an aggregate, doing 'boost::result_of<F(T)>::type c = {};' should always be legal. What I'm missing?
Also, as Eric stated in Proto doc, result_of compiles slow.
Ok. Is your static_result_of faster? And if so, couldn't you just port your improvements to the basic result_of? (or there are differences that allow you to take shortcuts?).
It seems a good idea to introduce static_result_of(Do you know a better name?). All the macros can be moved to static_result_of document section, and all the result_of_xxx<> can be removed.
Ah, now I see the shortcut, of course, you put the function name directly in the xxx part! Anyways, yes, I think it would be worthwhile to rearrange the documentation this way. Also you do not need to remove all the result_of_xxx functions ,but just document all of them together with static_result_of (simply state that for every function X provided by egg, there is a result_of_ ## X that does the same of static_result_of<X()>, or whatever the semantics are).
Also, do you have a plan for allowing complex statically initialized expressions in header files without ODR violations?
Though BOOST_EGG_CONST does nothing for now, it has the potential to work around the ODR violation. But I hesitate to say "Any function definition requires a macro!".
Only if you want to put them in an header file. Just to clarify, what I do is this: template<typename Aggregate> struct instance_of { static Aggregate instance; }; template<typename Aggregate> Aggregate instance_of::instance = {}; Then I use it like this: // in an header const fold_t& fold = instance_of<fold_t>::instance; I usual hide the last line in a macro: INSTANCE_OF(fold_t, fold); Can EGG_CONST do something like this?
Anyway, I want to follow the Boost.Proto way.
boost::result_of<T_curry2(F const &)>::type c = curry2(f); // dynamic
or egg::return_of if you want recursive evaluation.
I'm not sure return_of is portable under msvc. That trivial example( http://tinyurl.com/yuumdv ) actually doesn't compile. :-(
Ah, ok. I also had problems with gcc.3.3 not digesting complex function type expressions. May be this syntax would be better: return_of<function_name, Arg1, Arg2, Arg3>::type and you can compose it like this: return_of<function1, return_of<function2, Arg1_1>, Arg2_1>::type This is more mpl friendly (result_of is a pain to use with mpl).
stateless_result_of<T_curry2(F)>::type c = BOOST_EGG_STATELESS(); // for stateless one.
Why not:
expression<T_curry2(F)> c = { /*just this please :) */ }; // note the missing ::type
It seems impossible to remove ::type, because `expression` can't use inheritance so that it can be a POD.
I do not think that podness is a problem, is just that it seems that the brace initializer can't be used with inheritance. But may be if the wrapped function object *really* stateless, you need no inheritance. You could just instantiate it directly in operator().
Well, 8.5.1 -14- states that "When an aggregate with static storage duration...". I think that if "an aggregate" means also "subaggregate", `{}` is not enough. Anyway, I should wait for Eric's answer.
yep.
BTW, expression<T_curry2(F)>::type c = {{}}; is feasible.
That would be very fine with me. But do you really need the double braces? -- gpd