From: Peder Holt (peder.holt_at_[hidden])
Date: 2004-12-02 16:25:37
On Thu, 2 Dec 2004 11:28:44 -0500, Arkadiy Vertleyb
> "David Abrahams" <dave_at_[hidden]> wrote
> > Arkadiy Vertleyb wrote:
> > > Well, it's not possible in general case, but for the purpose of typeof,
> > > rough approximation may be enough. We can just assume that, if the type
> > > not caught by all the specializations (generated by registration), then
> > > *might be* one of the standard iterators. We can use SFINAE, examining
> > > value_type, distance_type, etc., to increase the probability of that
> > > assumption.
> > As long as you don't mind access violations when one of those typedefs
> > happens to be present, but private.
> I didn't think about it, and I didn't realise SFINAE can't handle private
> However recall that this applies only to types not registered in a normal
> way. So, for these types only, we would get an error:
> can't access private typedef Foo::value_type
> instead of
> encode_type is not defined for the type Foo
> Not very nice, but arguably not an unreasonable price to pay for the ability
> to register standard iterators on the typeof library level...
> Unfortunately the problem doesn't seem to get solved anyway...
It may be that we will need separate implementation for the different
I have looked at the stl-implementations of VC6.5, VC7.1,GCC 3.2 and
>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.
GCC 3.2 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: 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
But I agree, it seems impossible to create one unified solution to the problem.
> 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