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]>,
> news:E562FCEE3A42D61192880002A5FB433302D7AFB5_at_kite.pigroup.co.uk...
>> ----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?
[TRUNCATE]

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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk