From: Peder Holt (peder.holt_at_[hidden])
Date: 2004-12-10 02:32:48
On Thu, 9 Dec 2004 10:05:24 -0500, Arkadiy Vertleyb
> "Peder Holt" <peder.holt_at_[hidden]> wrote
> > The main reason for creating something like this would be to allow
> > registration of the dinkumware iterators, which are defined as nested
> > classes (unlike the iterators of other stl-implementations which are
> > normal template classes already supported by the TYPEOF library)
> > BOOST_TYPEOF_REGISTER_TEMPLATE_NESTED should only be used in this
> > context, and not promoted outside of the TYPEOF library.
> > This functionality could also be implemented in the same scope as the
> > stl registration code. This would prevent the TYPEOF library from
> > being polluted, but would allow automatic registration of iterators
> > for all platforms.
> Actually this method is only good with overloading -- doesn't work with
> partial template specialization. So, for the conformant implementation, we
> would have to implement some additional mechanism in the main template...
> So I am not sure we would be really able to "prevent the TYPEOF library from
> being polluted".
Hmm. This is starting to look really ugly.
I'll have one more go before abandoning this.
We cannot place support for template nested class deduction directly
into the typeof library:
1. It would break the elegance of the source
2. It exploits a compiler bug
3. It is only applicable for a single compiler series.
I think I have found a way to separate the code from the library,
given the restrictions above.
Assuming that all the source will be placed in a
compiler/stl-implementation specific folder:
1. Define the generic version of encode_type_impl (So far it has only
been forward declared.
2. Create a template function encode_type_fn.
3. Use encode_type_fn to forward type deduction from encode_type_impl
(Default implementation causes compile time failure with the proper
4. Overload encode_type_fn for each of the nested classes.
The problem with this approach, is obviously that a function can only
represent a single integral value at compile time, while we need a
vector of them. The only way I know of to transfer a vector of
integral values compile time across a function, is to use the compile
time constants vector.
Well, I guess it is back to square one. At least we tried.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk