[LC++]STL Iterators and integers

[Grzegorz Mazur]

Hi,

On Fri, 10 Aug 2001, Mark Phillips wrote:

[snip]

> The only reason you would convert member functions over to virtual is
> if you wished to derive a new class from this base class for which
> some of the member functions needed to be reinterpreted.  Making them
> virtual would guard against base class pointer problems.  One simple
> example off the top of my head is the following.
> 
> Suppose you want to define an "offset vector" class.  Ie it is a vector
> of integers, but has an "offset" value associated with it.  The value
> of the "offset vector" at position i, is equal to the value stored in
> an associated STL vector at position i, plus the offset value.
> 
> class offsetVectorTy: public vector<int> {
> private:
>   int offsetPrv;
> public:
>   int offset() const {return offsetPrv;}
>   void setOffset(int offsetArg) {offsetPrv=offsetArg;}
>   int operator[](int i) const {return vector<int>::operator[](i)+offset();}
>   offsetVectorTy(): vector<int>() {}
> }
> 
> By inheriting from vector<int>, it is very easy to set up what we
> want.  offsetVectorTy _is_ a vector, so it has all the behaviour
> and properties of vector<int>, except those which we have 

No, you are wrong. This is no longer a vector, and it wouldn't be so easy
to make it behave as a vector.

> redefined.  It's advantages:
> 
> 1. It is very easy to set up.
> 
> 2. With the possible exception of base class pointer problems, it
> is exactly what we want.
> 
> 3. We can use STL algorithms on it.

As I've already wrote, the STL algorithms work on iterators, not
containers. So to achieve such effect in STL, you define a special kind of
iterator, which transforms somehow values obtained from the underlying
iterator. This way you can achieve the same effect without run-time
polymorphism.

> 4. For large vectors, we can very quickly and easily change the
> offset value, so it is an efficient implementation.

It can't be efficient all the member functions virtual.

[snip]

> 2. Write a wrapper class for vector, call it "baseVectorTy"
> for example, and make everything virtual.  Then with your
> general algorithm, let it take a pointer to baseVectorTy
> as its parameter.

And you always pay the price of polymorphism? No, thanks.

> 3. Rewrite the c++ standard so that the "virtual" keyword
> is "clever", so that it only adds the virtual runtime overheads
> when they are needed.  (And implement compliant compilers.)  This
> way, the STL could define things as virtual without worrying about
> efficiency.  (For that matter, get rid of the virtual keyword
> all together.)  From what I have read, this option is not done
> because it would be very tricky to write compilers which do this.
> (But not impossible it would seem.)

To me it seems impossible and I can't imagine how could it work. Could you
send any reference?

Regards,
--
Grzesiek