473,322 Members | 1,501 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

Which design in better?

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) {}
~XHandleIterator() { 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 XHandleIteratorOne : public XHandleIterator {
public:
XHandleIteratorOne(SomeType obj) {
// Creates XHandle someway. Assigns to mHandle and mCount
}
};

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

<b>Option2:</bPolicy based design
template<typename HandleCreator>
class XHandleIterator {
public:
XHandleIterator (SomeType obj) : mHandle(0L), mCount(0)
{
HandleCreator::Create(obj, &mHandle);
mCount = GetXHandleSize(mHandle)/sizeof(X);
}
~XHandleIterator() { 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<XHandleCreator1XHandleIteratorOne;
typedef XHandleIterator<XHandleCreator2XHandleIteratorTwo;

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
Aug 25 '08 #1
5 1379
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)

iEYEABECAAYFAkizMXkACgkQx9p3GYHlUOKo+ACfSvjC0BkzZB 0lAlUG52z3S46m
6G0Anjl/3p5AHFB9v0fIUxdjIHBOAjNv
=+5yw
-----END PGP SIGNATURE-----

Aug 25 '08 #2
On Aug 26, 3:26*am, Sam <s...@email-scan.comwrote:
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_pgp-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
Aug 26 '08 #3
Nitesh <ni************@gmail.comkirjutas:
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) {}
~XHandleIterator() { 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 XHandleIteratorOne : public XHandleIterator {
public:
XHandleIteratorOne(SomeType obj) {
// Creates XHandle someway. Assigns to mHandle and mCount
}
};

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

<b>Option2:</bPolicy based design
template<typename HandleCreator>
class XHandleIterator {
public:
XHandleIterator (SomeType obj) : mHandle(0L), mCount(0)
{
HandleCreator::Create(obj, &mHandle);
mCount = GetXHandleSize(mHandle)/sizeof(X);
}
~XHandleIterator() { 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<XHandleCreator1XHandleIteratorOne;
typedef XHandleIterator<XHandleCreator2XHandleIteratorTwo;

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 = ObtainXHandleInWhatEverWay();

for(XContainer::iterator p = my_xvector.begin();
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
Aug 26 '08 #4
On Aug 26, 11:02*am, Paavo Helde <nob...@ebi.eewrote:
Nitesh <niteshchord...@gmail.comkirjutas:
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) {}
*~XHandleIterator() { 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 XHandleIteratorOne : public XHandleIterator {
public:
*XHandleIteratorOne(SomeType obj) {
*// Creates XHandle someway. Assigns to mHandle and mCount
}
};
class XHandleIteratorTwo : public XHandleIterator {
*XHandleIteratorTwo(SomeType obj) {
*// Creates XHandle in another way. Assigns to mHandle and mCount
*}
};
<b>Option2:</bPolicy based design
template<typename HandleCreator>
class XHandleIterator {
public:
*XHandleIterator (SomeType obj) : mHandle(0L), mCount(0)
*{
* HandleCreator::Create(obj, &mHandle);
* mCount = GetXHandleSize(mHandle)/sizeof(X);
*}
*~XHandleIterator() { 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<XHandleCreator1XHandleIteratorOne;
typedef XHandleIterator<XHandleCreator2XHandleIteratorTwo;
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 = ObtainXHandleInWhatEverWay();

for(XContainer::iterator p = my_xvector.begin();
* * * * 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
Aug 26 '08 #5
Nitesh <ni************@gmail.comkirjutas:

[...]
>
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

Aug 26 '08 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: sayoyo | last post by:
Hi Guys, I have to implement a design in Java which is a collection class gathers several units of the same class. I was thinking about two ways to implement it. the first is to create two...
133
by: Jane Withnolastname | last post by:
I have a web page that uses an unordered list (<UL>) and the LH (list header) tag. I know LH is a valid tag because it is clearly defined by the W3C here:...
10
by: heromull | last post by:
We have an asp.net app with about 200 data entry forms. Customers may enter data into any number of forms. Each form's data is persisted in a corresponding sql table. When data entry is...
1
by: Jason | last post by:
Hi all, I have 1 table which need to store 7 days data in a row, I not sure which table design will gain better performance in SELECT statement. Desgin 1. 7 columns (day1, ..., day7) with char(4)...
105
by: Christoph Zwerschke | last post by:
Sometimes I find myself stumbling over Python issues which have to do with what I perceive as a lack of orthogonality. For instance, I just wanted to use the index() method on a tuple which does...
4
by: Ronald S. Cook | last post by:
I'm implementing .NET Remoting on a project. We have about 12 instances of the application running at one time, 10 in trucks out in a wireless enviroment (trucks do not leave the yard.. they are...
8
by: =?Utf-8?B?eWRibg==?= | last post by:
I need to write a program validate a text file in CSV format. So I will have a class DataType and a lot of of derived class for various type, e.g. IntType, StringType, FloatType, MoneyType,...
20
by: mike3 | last post by:
Hi. (Xposted to both comp.lang.c++ and comp.programming since I've got questions related to both C++ language and general programming) I've got the following C++ code. The first routine runs in...
3
by: Ty Oft | last post by:
Hello Bytes! Maybe my question seems a bit silly (as one could simply answer it "Well, what are you more passionate about?" or stuff like that - please don't answer like this), but I am in a bit...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.