Boost logo

Boost :

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-12-21 21:07:37

"Andy Little" <andy_at_[hidden]> wrote

> "Arkadiy Vertleyb" wrote ...
> > I will try to implement such registrations for mpl::vector[n], as an
> > example. However, I think it's ultimately up to the library authors do
> > decide whether or not to make their libraries typeof-enabled (I would be
> > happy to provide any help on the subject).
> Types are an implementation detail in mpl , so as I understand it, even if
I as
> a user ,currently register the actual types of the result, then there is
> guarantee that they will remain the same in the next version of the
> which makes theoretically for high maintenance unless the library author
> with it instead. I guess its not to bad in practise, but means my quantity
> library is relying on artefacts of the implementation if I use mpl, and I
> really like that :-(

This is one problem. Another problem is that, if somebody else also
registers MPL types (which is quite likely due to its popularity), any
attempt to use your libs together will result in compile errors due to
double MPL registration.

That's why I think only library authors should register their types. In
case it's not possible (STL, for example) this is done by the typeof library

As a (temporary?) workaround, I can suggest you to define your own sequences
by deriving them from mpl::vector, register them, and ask your users to use
them instead of mpl::vector to supply type sequences to your templates. I
am thinking of using this approach with RTL.

> BTW... I guess it might be glaringly obvious, but it might be worth
> in the documentation that when the inbuilt error output fails regarding
lack of
> type registration( When pages and pages of template parameters appear) ,
> using typeid(T).name() will provide useful information on the make-up of a
> particular type, an alternative aid to finding the particular types that
> been registered. Maybe its too obvious too mention but I forgot about it
> recently. After I started using this approach it dramatically speeded up
> debugging.

So that you can catch all of them at once instead of one-by-one, as the
error messages arrive. Sounds reasonable.


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