Re: [boost] Re: Re: typeof integrated

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
<vertleyb_at_[hidden]> wrote:
> 
> 
> "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:
boost/typeof/stl/dinkumware_vc/

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
error messages)

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.

Peder

> Arkadiy
> 
> _______________________________________________
> 
> 
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>