Summary:
The author discusses how the use of generic programming in C++ can lead to conflicts with object-oriented design principles. He demonstrates how a technique known as type erasure can often be used to resolve these conflicts. An in-depth example is presented:
any_iterator, a type-safe, heterogeneous C++ iterator.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: November 27, 2007 7:35 AM by
Eivind
|
|
|
any_iterator use type-erase tech to erase the actal type such as vector::iterator or list::iterator; in that case, it is only a iterator to access the elements in the container.
but yet any_iterator expose the iterator more details such as the iterator_tag. For my option, I want to only access elements with the type user defined. If you want to tell the iterator tag type to the user, you can use the runtime tech such as through tag_type() function.
so for template class any_iterator, the CategoryOrTraversal template argument should not needed; and to the extreme, all the argument except the Value are not needed. code like below:
template< class Value> class any_iterator;
in this case, type-erase tech is used in its extreme.
|
|
|
|
|
> so for template class any_iterator, the
> CategoryOrTraversal template argument should not needed;
> and to the extreme, all the argument except the Value are
> not needed.
The point of these template arguments is to ensure that the any_iterator is a Standard-conforming iterator. Among other things, this ensures that the any_iterator works properly with generic algorithms of the kind found in the STL. If you really need to work with iterators that do not have these capabilities, my recommendation would be to avoid the term "iterator." I believe it's best to reserve the term "iterator" for Standard-conforming iterators.
|
|
|
|
|
> Ok, reply to myself:
>
> >They have chosen not to use the term "type erasure" at
> > all,
>
> I'm beginning to understand why some people are not happy
> with the term "type erasure." It does sound a bit like
> "making things typeless." Perhaps the person who posted
> the root message to this thread was a victim of this
> misunderstanding when he likened type erasure to using
> void*. (See, no matter what someone says, there is always
> some value in it.) Hm, what would be a better term? How
> about NIRP, for "non-intrusive runtime polymorphism" :o)
"Type normalization" or "Type canonicalization". The latter is probably better, though it is a mouthful. Using a common abbreviation for canonicalization, it would be "Type c14n", though that's only slightly better.
Eivind.
|
|