On Thu, 2 Dec 2004 11:28:44 -0500, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
"David Abrahams" <dave@boost-consulting.com> wrote
Arkadiy Vertleyb wrote:
Well, it's not possible in general case, but for the purpose of typeof, a rough approximation may be enough. We can just assume that, if the type was not caught by all the specializations (generated by registration), then it *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 typedefs.
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...
Arkadiy
It may be that we will need separate implementation for the different STL-implementations. I have looked at the stl-implementations of VC6.5, VC7.1,GCC 3.2 and STLport 4.5.3.
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 the problem. But I agree, it seems impossible to create one unified solution to the problem. Peder
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost