|
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
no
> guarantee that they will remain the same in the next version of the
library,
> which makes theoretically for high maintenance unless the library author
deals
> 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
dont
> 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
itself.
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
mentioning
> in the documentation that when the inbuilt error output fails regarding
lack of
> type registration( When pages and pages of template parameters appear) ,
that
> 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
havent
> been registered. Maybe its too obvious too mention but I forgot about it
> recently. After I started using this approach it dramatically speeded up
my
> debugging.
So that you can catch all of them at once instead of one-by-one, as the
error messages arrive. Sounds reasonable.
Regards,
Arkadiy
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk