Boost logo

Boost :

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-04-03 08:21:30

On Thu, Apr 3, 2008 at 1:53 AM, shunsuke <pstade.mb_at_[hidden]> 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?


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( ) 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.


> BTW,
> expression<T_curry2(F)>::type c = {{}};
> is feasible.

That would be very fine with me. But do you really need the double braces?


Boost list run by bdawes at, gregod at, cpdaniel at, john at