Re: [boost] boost::dynamic_array
----Original Message---- From: Boris [mailto:boris@gtemail.net] Sent: 04 October 2005 13:18 To: boost@lists.boost.org Subject: Re: [boost] boost::dynamic_array
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). -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434
"Martin Bonner" <martin.bonner@pitechnology.com>, news:E562FCEE3A42D61192880002A5FB433302D7AFB5@kite.pigroup.co.uk...
----Original Message---- From: Boris [mailto:boris@gtemail.net] Sent: 04 October 2005 13:18 To: boost@lists.boost.org Subject: Re: [boost] boost::dynamic_array
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? Anyway I developed my fixed-size array meanwhile. Boost doesn't seem to be much interested which is perfectly okay of course. If anyone else is interested however or needs a runtime version of a fixed-size array just ask me. Boris
On 10/4/05 2:07 PM, "Boris" <boris@gtemail.net> wrote:
"Martin Bonner" <martin.bonner@pitechnology.com>, news:E562FCEE3A42D61192880002A5FB433302D7AFB5@kite.pigroup.co.uk...
----Original Message---- From: Boris [mailto:boris@gtemail.net] 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
participants (3)
-
Boris -
Daryle Walker -
Martin Bonner