Boost logo

Boost :

From: Daryle Walker (darylew_at_[hidden])
Date: 2005-10-24 17:27:09

On 10/4/05 2:07 PM, "Boris" <boris_at_[hidden]> wrote:

> "Martin Bonner" <martin.bonner_at_[hidden]>,
>> ----Original Message----
>> From: Boris [mailto:boris_at_[hidden]]
>> Sent: 04 October 2005 13:18
>>> The reason why I don't want to use std::vector in the project I work on is
>>> that I need a two-dimensional array. Two-dimensional means that the array
>>> stores not only the length but also width and height. Additionally its
>>> elements can be accessed with operator()(size_t column, size_t row). Now I
>>> could derive my two-dimensional array from std::vector but that doesn't make
>>> much sense because how should the dimensions change when someone calls
>>> push_back()? A fixed-size array whose size can be set a runtime would be an
>>> ideal candidate to derive my two-dimensional array from. For all arrays with
>>> more than one dimension std::vector isn't probably an ideal parent class.
>> So don't /derive/ from std::vector, /contain/ a std::vector instead (and
>> forward the appropriate calls to it).
>> It's really not very difficult (particularly as you don't need to both with
>> eg any of the 'insert' overloads).
> It's not very difficult but not what I expect to be good practice of code
> reuse. Why do the extra effort and forward all calls if you could simply
> derive?

Because deriving is appropriate only if the child class's interface is an
extension of the original class's interface. It can't be used if the new
class will have a restricted or different interface. (That's the same
reason a circle class can't be derived from an ellipse class.) You want
your new class to remove the size-mutable operations of vector (and I would
suggest removing the 1-D element access), making it unsuitable for a
derivation tactic.

Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com

Boost list run by bdawes at, gregod at, cpdaniel at, john at