C++Talk.NET

manfred · Guest

hi all,

in our project we are using a certain class (it's an
ACE_Array<someType>) in a lot of places. The following two
requirements apply:
(A) In addition to the standard array interface we use some special
insertion and lookup 'algorithms'.
(B) we have a number of 3rd-party subsystems that operate on
ACE_Array<someType> objects which are passed by reference.

I'm trying to wrap up this code and came up with three design
alternatives, none of them very convincing:

(1) public derivation: create a new class that publicly derives from
ACE_Array<someType> and adds the special algorithms as member
functions. This is problematic since the base class has a non-virtual
destructor. apart from this limitation I think it would be the right
choice, even though the base has no virtual functions at all.

(2) use free functions for the special insertion/lookup, passing the
array objects as arguments. I (and other implementers) find this
rather un-intuitive, since insertion and lookup are operations acting
on arrays and 'member' functions would seem 'natural' here.

(3) use aggregation: create a new class that aggregates an
ACE_Array<someType>; then write simple forwarders for all (or most)
array functions, plus the additional insertion and lookup methods:

class myArrayClass {
public:
// duplicate needed array functions here and forward
// add special insertion and lookup methods
private:
ACE_Array<someType> theArray;
};

I'm currently thinking about option (3) which seems safe; however, I
cannot pass such a class to a function that expects an
ACE_Array<someType>. My question now is: would it be reasonable to add
a user-defined conversion
operator ACE_Array<someType>& () { return theArray; } // good?
that returns a reference to the aggregated member? Surely this would
give up encapsulation of the member variable, but I guess that's just
what i need here...

thanks,

-manfred

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Antonio Maiorano · Guest

Hi Manfred,

My personal advice is the following:

1) Don't subclass the array. Apart from the fact it does not have a virtual
destructor, typically you are supposed derive a class to "change" its
behavior - since there are no virtual functions, you will only be "adding"
behavior, and this to me is not a valid enough reason to go with this.

2) Writing a wrapper class is not a terrible solution, since as you said, it
is more convenient to programmers and readers of the code because you will
be calling InsertSpecial() (for example) directly on the class instance.
Adding your type-conversion will solve the problem of passing it to
functions that expect the aggregate array type; however, it does not solve
the problem of calling those methods on the aggregate type without a
typecast. Your code will look like this:

MyArrayWrapper arr(ACE_Array<int>()); // Create wrapper over ACE_Array
instance

arr.InsertSpecial(5); // Call our own special insertion method (nice and
convenient)

static_cast<ACE_Array&>(arr).Insert(6); // Call ACE_Array method, not so
convenient :(

3) In the end, go for the free functions. This is not as inconvenient as you
think. Think about the STL algorithms, for instance, which contain many free
functions that work on containers. This is a simpler and more flexible
solution, in my honest opinion.

Hope this helps you out!

Tony

"manfred" <mzinner (AT) snafu (DOT) de> wrote

Lars Tetzlaff · Guest

hi

manfred wrote:

....

Aaron Bentley · Guest

Lars Tetzlaff wrote:

manfred · Guest

On 26 Oct 2003 01:06:05 -0400, Aaron Bentley
<aaron.bentley (AT) utoronto (DOT) ca> wrote:

Lars Tetzlaff · Guest

Aaron Bentley wrote:

Aaron Bentley · Guest

Lars Tetzlaff wrote:

Aaron Bentley · Guest

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

manfred wrote: