|
Boost : |
From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2006-12-06 07:03:19
Michael Fawcett <michael.fawcett <at> gmail.com> writes:
>
> On 12/5/06, Franck Stauffer <franck <at> lowcoders.net> wrote:
> >
> > 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 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.
>
> Why not just assume that the functor has typedefs for argument_type
> and return_type and document the details?
Why not define an extra traits class that defines those typedefs
instead of polluting time-critical classes with typedefs?
I always find it odd that STL algorithms require a rather large set of
typedefs to be defined _inside_ the container.
Why not std::size_type<T>::type instead of T::size_type?
Why not std::begin(std::vector<T> & v) instead of std::vector<T>::begin()
A generic library is much more reusable if no typedefs inside the class
are required and no special member function has to be provided
(Declaring war to all those wrappers)
And this I say not only for reusability, but also for performance:
real world compilers tend to optimize away empty or nearly empty
classes more easily than stuff that contains more than one element.
Markus
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk