Which design in better?

[Nitesh]

Objects of type X are basic building blocks of my application and
there are a few functions which return XHandle (typedef X** XHandle).
The task at hand needs to use a couple of these functions and then
iterate over X objects.
Because its done frequently and it separates iteration from task-at-
hand'logic we decided to create iterator.

Assuming the availability of functions GetXHandleSize( XHandle) and
DisposeXHandle( XHandle) there are two alternatives.

<b>Option1:</bUsing simple inheritance
class XHandleIterator {
public:
XHandleIterator (void) : mHandle(0L), mCount(0) {}
~XHandleIterato r() { if (mHandle != 0L) DisposeXHandle( mHandle); }

bool Done(void) { return mCount 0; }
// Pre-increment operator
XHandleIterator & operator++(void ) { --mCount; return *this; } // Am
iterating over backwards
// Post-increment operator..
// De-referencing operator
X& operator *(void) { return (*mHandle)[mCount-1]; }
protected:
XHandle mHandle;
int mCount;
};

class XHandleIterator One : public XHandleIterator {
public:
XHandleIterator One(SomeType obj) {
// Creates XHandle someway. Assigns to mHandle and mCount
}
};

class XHandleIterator Two : public XHandleIterator {
XHandleIterator Two(SomeType obj) {
// Creates XHandle in another way. Assigns to mHandle and mCount
}
};

<b>Option2:</bPolicy based design
template<typena me HandleCreator>
class XHandleIterator {
public:
XHandleIterator (SomeType obj) : mHandle(0L), mCount(0)
{
HandleCreator:: Create(obj, &mHandle);
mCount = GetXHandleSize( mHandle)/sizeof(X);
}
~XHandleIterato r() { if (mHandle != 0L) DisposeXHandle( mHandle); }
bool Done(void) { return mCount 0; }
// Pre-increment operator
XHandleIterator & operator++(void ) { --mCount; return *this; }
// Post-increment operator...
// De-referencing operator
X& operator *(void) { return (*mHandle)[mCount-1]; }
private:
XHandle mHandle;
int mCount;
};

struct XHandleCreator1 {
static void Create(SomeType obj, XHandle *handle) {
// Creates XHandle someway. Assigns to handle
}
};

struct XHandleCreator2 {
static void Create(SomeType obj, XHandle *handle) {
// Creates XHandle in another way. Assigns to handle
}
};

typedef XHandleIterator <XHandleCreator 1XHandleIterato rOne;
typedef XHandleIterator <XHandleCreator 2XHandleIterato rTwo;

I am confused over which is the right way to do in this case with all
stipulations stated at the top. The main thing I like about 2nd one is
that mHandle and mCount are private.
Please comment on which of the above alternative is better?

Thanks
Nitesh

[Sam]

Nitesh writes:

Objects of type X are basic building blocks of my application and
there are a few functions which return XHandle (typedef X** XHandle).

A pointer to a pointer?

The task at hand needs to use a couple of these functions and then
iterate over X objects.
Because its done frequently and it separates iteration from task-at-
hand'logic we decided to create iterator.

Can you explain, precisely, why you've decided to reinvent the wheel, why
none of the STL containers and iterators do not meet your needs, and what
does your handmade iterator class does that none of the STL iterators do.

std::vector, std::list, std::set, std::map, and a few other STL containers,
all give you perfectly usable iterator objects. Any particular reasons why
none of them meet your needs?

Assuming the availability of functions GetXHandleSize( XHandle) and
DisposeXHandle( XHandle) there are two alternatives.

<b>Option1:</bUsing simple inheritance

Both of your options are difficult to follow. Pick an STL container that
meets your needs, and use the iterator definition that it gives you.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAki zMXkACgkQx9p3GY HlUOKo+ACfSvjC0 BkzZB0lAlUG52z3 S46m
6G0Anjl/3p5AHFB9v0fIUxd jIHBOAjNv
=+5yw
-----END PGP SIGNATURE-----

[Nitesh]

On Aug 26, 3:26*am, Sam <[e-mail]:

Nitesh writes:

Objects of type X are basic building blocks of my application and
there are a few functions which return XHandle (typedef X** XHandle).

A pointer to a pointer?

The task at hand needs to use a couple of these functions and then
iterate over X objects.
Because its done frequently and it separates iteration from task-at-
hand'logic we decided to create iterator.

Can you explain, precisely, why you've decided to reinvent the wheel, why
none of the STL containers and iterators do not meet your needs, and what
does your handmade iterator class does that none of the STL iterators do.

std::vector, std::list, std::set, std::map, and a few other STL containers,
all give you perfectly usable iterator objects. Any particular reasons why
none of them meet your needs?

Assuming the availability of functions GetXHandleSize( XHandle) and
DisposeXHandle( XHandle) there are two alternatives.

<b>Option1:</bUsing simple inheritance

Both of your options are difficult to follow. Pick an STL container that
meets your needs, and use the iterator definition that it gives you.

*application_pg p-signature_part
< 1KViewDownload

Its a legacy app. And I am making use of existing functions which
return me Handle to objects of type X. i.e. I have a pointer to an
array pointer and indexing that array is enough to obtain an array
element, So this option was chosen instead of first creating an STL
container from the handle.

Do you still suggest to first copy the handle elements to an STL
container (copy is not constly because its just pointer to X) and then
use STL iterators.

The iterator was made simple just to focus on the problem of confusion
over choosing between alternate approaches. i.e. You have to write
your own iterator. So the problem can be restated as:
You have to write the iterator, but the collection over which it
iterates is obtained in different ways. In that case whats the better
way? Using simple inheritance and letting derived classes obtain the
collection OR using HandleCreation policy? Or any other way?

Thanks
Nitesh

[Paavo Helde]

Nitesh <ni************ @gmail.comkirju tas:

Objects of type X are basic building blocks of my application and
there are a few functions which return XHandle (typedef X** XHandle).
The task at hand needs to use a couple of these functions and then
iterate over X objects.
Because its done frequently and it separates iteration from task-at-
hand'logic we decided to create iterator.

Assuming the availability of functions GetXHandleSize( XHandle) and
DisposeXHandle( XHandle) there are two alternatives.

<b>Option1:</bUsing simple inheritance
class XHandleIterator {
public:
XHandleIterator (void) : mHandle(0L), mCount(0) {}
~XHandleIterato r() { if (mHandle != 0L) DisposeXHandle( mHandle); }

bool Done(void) { return mCount 0; }
// Pre-increment operator
XHandleIterator & operator++(void ) { --mCount; return *this; } // Am
iterating over backwards
// Post-increment operator..
// De-referencing operator
X& operator *(void) { return (*mHandle)[mCount-1]; }
protected:
XHandle mHandle;
int mCount;
};

class XHandleIterator One : public XHandleIterator {
public:
XHandleIterator One(SomeType obj) {
// Creates XHandle someway. Assigns to mHandle and mCount
}
};

class XHandleIterator Two : public XHandleIterator {
XHandleIterator Two(SomeType obj) {
// Creates XHandle in another way. Assigns to mHandle and mCount
}
};

<b>Option2:</bPolicy based design
template<typena me HandleCreator>
class XHandleIterator {
public:
XHandleIterator (SomeType obj) : mHandle(0L), mCount(0)
{
HandleCreator:: Create(obj, &mHandle);
mCount = GetXHandleSize( mHandle)/sizeof(X);
}
~XHandleIterato r() { if (mHandle != 0L) DisposeXHandle( mHandle); }
bool Done(void) { return mCount 0; }
// Pre-increment operator
XHandleIterator & operator++(void ) { --mCount; return *this; }
// Post-increment operator...
// De-referencing operator
X& operator *(void) { return (*mHandle)[mCount-1]; }
private:
XHandle mHandle;
int mCount;
};

struct XHandleCreator1 {
static void Create(SomeType obj, XHandle *handle) {
// Creates XHandle someway. Assigns to handle
}
};

struct XHandleCreator2 {
static void Create(SomeType obj, XHandle *handle) {
// Creates XHandle in another way. Assigns to handle
}
};

typedef XHandleIterator <XHandleCreator 1XHandleIterato rOne;
typedef XHandleIterator <XHandleCreator 2XHandleIterato rTwo;

I am confused over which is the right way to do in this case with all
stipulations stated at the top. The main thing I like about 2nd one is
that mHandle and mCount are private.
Please comment on which of the above alternative is better?

Thanks
Nitesh

It appears you want the iterator to perform two tasks: iterate over the
array, and dispose the array when done. It would be cleaner to keep these
tasks separate IMO. To follow the STL pattern there should be a
"container" class, from where the iterators can be obtained by begin()
and end() member functions. The fact that the data is actually living
elsewhere does not have any significance. The "container" object will
call Dispose in its destructor.

The usage would go like this:

XContainer my_xvector = ObtainXHandleIn WhatEverWay();

for(XContainer: :iterator p = my_xvector.begi n();
p != my_xvector.end( ); ++p) {

X& xref = *p;
// Do whatever with X

}

I see no need for inheritance or policy-based templates here, based on
the info you provided. The container object should just have a
constructor and/or an assignment operator taking XHandle as a parameter,
regardless of in which way the handle was obtained. Mixing up this class
with different ways to obtain the handle would just convolute the design.
If really needed, one could provide a separate "factory" class for taking
care of obtaining the handle in different ways.

hth
Paavo

[Nitesh]

On Aug 26, 11:02*am, Paavo Helde <[e-mail] rote:

Nitesh <niteshchord... @gmail.comkirju tas:

Objects of type X are basic building blocks of my application and
there are a few functions which return XHandle (typedef X** XHandle).
The task at hand needs to use a couple of these functions and then
iterate over X objects.
Because its done frequently and it separates iteration from task-at-
hand'logic we decided to create iterator.

Assuming the availability of functions GetXHandleSize( XHandle) and
DisposeXHandle( XHandle) there are two alternatives.

<b>Option1:</bUsing simple inheritance
class XHandleIterator {
public:
*XHandleIterato r(void) : mHandle(0L), mCount(0) {}
*~XHandleIterat or() { if (mHandle != 0L) DisposeXHandle( mHandle); }

*bool Done(void) { return mCount 0; }
*// Pre-increment operator
*XHandleIterato r& operator++(void ) { --mCount; return *this; } // Am
iterating over backwards
*// Post-increment operator..
*// De-referencing operator
*X& operator *(void) { return (*mHandle)[mCount-1]; }
protected:
*XHandle mHandle;
*int mCount;
};

class XHandleIterator One : public XHandleIterator {
public:
*XHandleIterato rOne(SomeType obj) {
*// Creates XHandle someway. Assigns to mHandle and mCount
}
};

class XHandleIterator Two : public XHandleIterator {
*XHandleIterato rTwo(SomeType obj) {
*// Creates XHandle in another way. Assigns to mHandle and mCount
*}
};

<b>Option2:</bPolicy based design
template<typena me HandleCreator>
class XHandleIterator {
public:
*XHandleIterato r (SomeType obj) : mHandle(0L), mCount(0)
*{
* HandleCreator:: Create(obj, &mHandle);
* mCount = GetXHandleSize( mHandle)/sizeof(X);
*}
*~XHandleIterat or() { if (mHandle != 0L) DisposeXHandle( mHandle); }
*bool Done(void) { return mCount 0; }
* // Pre-increment operator
*XHandleIterato r& operator++(void ) { --mCount; return *this; }
*// Post-increment operator...
*// De-referencing operator
*X& operator *(void) { return (*mHandle)[mCount-1]; }
private:
*XHandle mHandle;
*int mCount;
};

struct XHandleCreator1 {
* * *static void Create(SomeType obj, XHandle *handle) {
* * * * *// Creates XHandle someway. Assigns to handle
* * *}
};

struct XHandleCreator2 {
* * *static void Create(SomeType obj, XHandle *handle) {
* * * * *// Creates XHandle in another way. Assigns to handle
* * *}
};

typedef XHandleIterator <XHandleCreator 1XHandleIterato rOne;
typedef XHandleIterator <XHandleCreator 2XHandleIterato rTwo;

I am confused over which is the right way to do in this case with all
stipulations stated at the top. The main thing I like about 2nd one is
that mHandle and mCount are private.
Please comment on which of the above alternative is better?

Thanks
Nitesh

It appears you want the iterator to perform two tasks: iterate over the
array, and dispose the array when done. It would be cleaner to keep these
tasks separate IMO. To follow the STL pattern there should be a
"container" class, from where the iterators can be obtained by begin()
and end() member functions. The fact that the data is actually living
elsewhere does not have any significance. The "container" object will
call Dispose in its destructor.

The usage would go like this:

XContainer my_xvector = ObtainXHandleIn WhatEverWay();

for(XContainer: :iterator p = my_xvector.begi n();
* * * * p != my_xvector.end( ); ++p) {

* * * * X& xref = *p;
* * * * // Do whatever with X

}

I see no need for inheritance or policy-based templates here, based on
the info you provided. The container object should just have a
constructor and/or an assignment operator taking XHandle as a parameter,
regardless of in which way the handle was obtained. Mixing up this class
with different ways to obtain the handle would just convolute the design.
If really needed, one could provide a separate "factory" class for taking
care of obtaining the handle in different ways.

hth
Paavo

This is thing I need to do
1) Obtain handle
2) Iterate over the handle
3) Dispose the obtained handle

For my task its the 1st (obtaining handle) that differs. 2nd and 3rd
(iterating over and disposing) are always done in same way so I put
them in same class.

But with your explanation it seems reasonable not to mix 2nd and 3rd.
So, obtaining and disposing handle should be responsibility of one
class and iterating over that should be done by another but related
class.

How about having one XContainer base class that has a nested public
Iterator class that knows how to iterate over the XContainer? And
there will be derived classes OR template specializations
XContainerOne/Two that know how to obtain the handle. Again which of
these two is better?

Thanks
Nitesh

[Paavo Helde]

Nitesh <ni************ @gmail.comkirju tas:

[...]

>
This is thing I need to do
1) Obtain handle
2) Iterate over the handle
3) Dispose the obtained handle

For my task its the 1st (obtaining handle) that differs. 2nd and 3rd
(iterating over and disposing) are always done in same way so I put
them in same class.

But with your explanation it seems reasonable not to mix 2nd and 3rd.
So, obtaining and disposing handle should be responsibility of one
class and iterating over that should be done by another but related
class.

How about having one XContainer base class that has a nested public
Iterator class that knows how to iterate over the XContainer? And

That's OK. But I would suggest to name the inner class "iterator" so
there might be a potential chance to pass XContainer to potential
template functions expecting STL containers.

there will be derived classes OR template specializations
XContainerOne/Two that know how to obtain the handle. Again which of
these two is better?

What I cannot understand is why is it necessary to make the handle
obtaining to be part of this system. This would reduce modularity. For
example, if somebody wants to use your classes for iterating over the
handle which has been obtained by some third way, he would have to write
a derived class or template policy for doing this. I don't see why this
should be necessary. KISS!

The situation would be different if the iteration or handle disposal
would be different for handles obtained in different ways. This
effectively means that there would be different kind of handles. In that
case one should use derivation and virtual functions somewhere if the
actual handle type is not known at compile time, and templates/policies
if the actual handle type is always known at compile time.

hth
Paavo