From: Peder Holt (peder.holt_at_[hidden])
Date: 2004-12-03 04:23:30
On Thu, 2 Dec 2004 16:54:15 -0500, Arkadiy Vertleyb
> "Peder Holt" <peder.holt_at_[hidden]> 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.
> > The iterators in dinkumware luckily have a common base class:
> > We can exploit this in order to make an implementation of
> > 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
> 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 :-(
> 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