On Thu, 2 Dec 2004 16:54:15 -0500, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
"Peder Holt" <peder.holt@gmail.com> wrote
From what I have seen so far, the only real problem are the implementations that define the iterator class inside the container, such as dinkumware.
Correct. It is just happens to be used by MSVC...
GCC 3.2
which is used for testing only, since it supports typeof natively...
and STLport typedefs global iterator types. In this case, we need only register these iterator types.
Correct.
The iterators in dinkumware luckily have a common base class: std::iterator<> We can exploit this in order to make an implementation of is_stl_iterator<> When it comes to the allocator type, it is used only in generating template arguments to the iterator class. Here we can create a dummy allocator type that defines the correct typedefs, and we have solved the problem.
Can you ellaborate on the "dummy allocator" idea -- I am not sure I understand it.
Forget it :( I was missing a major point. Using a dummy allocator will only help deduce the iterators base class. Since the iterator class itself is defined inside the container, it will be dependent on all the template arguments of the container. My suggestion will only solve the problem for default arguments of the allocator and predicative, and not at all for maps. It is of cource possible to allow the user to register allocators, and thereby creating template specializations that will cover these, but the problem with predicatives and keys for maps still remain.
But I agree, it seems impossible to create one unified solution to the problem.
Correct, even if all the STLs in the world used global iterator templates, they would use different ones, since it's not in the standard :-(
Arkadiy
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost