Boost logo

Boost :

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2006-12-05 11:26:31


Franck Stauffer ha escrito:

> On Dec 5, 2006, at 4:43 PM, Neal Becker wrote:
>
> > Good to bring this up. Note that we've discussed this before (and
> > I posted
> > sample code).
> >
> > I haven't seen your code yet, but you mention functors must derive
> > from some
> > base class. That's not desirable - and I doubt it's required.
> >
> > _______________________________________________
> > Unsubscribe & other changes: http://lists.boost.org/mailman/
> > listinfo.cgi/boost
>
> Hi,
>
> Thanks for your answer...
>
> To make that point clear, it is only required for static type
> checking of arguments and return types without having to use more
> than two template parameters.

If you only want to do static *checking* the cost may be unacceptable:
after all, if some type does not match it'll trigger an error when
instantiating your generic code --admittedly the error message will be
more cryptic than provided by a BOOST_STATIC_ASSERT,
but even so, cluttering the interface for static type checking reasons
seems too much.

> If you want to say it is not desirable
> for performance, I think deriving from std::unary_function costs
> nothing (since unary_function's only declare typedef's for return and
> argument types, there is not impact on calling the functor). The
> problem is that somehow I want the user to be explicit about those
> types.
>
> I am of course open to any propositions to avoid deriving from
> std::unary_function that does not require a large template argument
> list.

You can use some traits-based technique. As for the result type, you
can use the carefully thought out [boost|std::tr1]::result_of proposal:

http://boost.org/libs/utility/utility.htm#result_of

HTH,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk