Boost logo

Ublas :

Subject: Re: [ublas] Numeric traits for ublas bounded_vector and matrix
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2010-02-23 08:11:20

Rutger ter Borg <rutger <at>> writes:
> It's usually used when there is both a compile-time and a run-time version
> of the same function, to make it a bit easier to figure out the result type
> of the function call. I.e., it's a replacement for 'auto' in this case. Also
> see the result_of in boost.utility.

I have worked a little with the result_of in boost.utility as a replacement for
template<typename X>
auto func(X x) -> decltype(x + x){}

... but still don't understand the connection to the metafunction calls, though
I can appreciate the confusion of runtime/designtime names.

Assuming size<T> returns an mpl::int_ or fails for things like size<void_>
and has_static_size is a mpl::bool_:

seems so much more verbose than: bindings::size<T>::value

especially when nested in a bunch of mpl code where the return of size<T>
is an int_ which works as a nullary metafunction on its own,
so you can use it with a lazy if_. e.g.:

const static int N = eval_if<has_static_size<T>, size<T>, int_<0> >::value;

But looking at the alternative:
const static int N = eval_if<has_static_size<T>,
  result_of::size<T>::type, int_<0> >::value;

... the ::type on the result_of forces a template instantiation and hence
breaks the code if result_of::size<T> is not always available or doesn't have
a nested ::value (i.e. if size<T> returns a ptrdiff_t when dynamically allocated

Then you have to do something like (untested but you get the point):
const static int N = eval_if<has_static_size<T>,
  lambda<result_of::size<T>>, int_<0> >::value;

... anyways, I am not that good at metaprogramming but consider lazy
instantiation when designing the traits interface.