On Thu, 9 Dec 2004 10:05:24 -0500, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
"Peder Holt" <peder.holt@gmail.com> 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