• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 185
  • Last Modified:

What is the simplest cleanest way to implement a container?

I want a global bag that I can throw things into
and then take them out later.  

The simplest contatiner that I can imagine.
(OK, surely there are simpler ones).
I want to put things into this bag in phase 1.
I will then read things from this bag in phase 2.

Write once.  Read once.  I don't care about
efficiency (spped or memory).  I just
want the simplest/cleanest interface.

Should I build my own container class on top of
one of STL's containter classes?  

My gut feel is that this ought to be one line in my .h
file, soemthing like:

extern slist<ObjectClass> ObjectContainer;

and a line in a .cc file, something like:

 slist<ObjectClass> ObjectContainer;

Possibly with an initialization to a null slist somewhere.

Then, in phase 1, I use:  ObjectContainer.pushback( ken)  to put ken in.  And, in phase 2, I use
an ObjectContainer iterator along with
 ObjectContainer.begin(), .next() and .end()
to read out all the objects.

Am I mising something?

  • 5
  • 2
  • 2
  • +1
1 Solution
Using one of the STL containers is probably the simplest (and standard) method. You don't need to initialise it to a 'null slist' anywhere.

Some things to consider:
1. Do you want duplicate objects in the container?
2. Will you be iterating bi-directionaly?
3. What are you storing in the container? STL requires that the objects have default & copy constructors and assignment operators.
4. Do you know how many objects you'll be storing before you start adding them?
Are we talking about the same "type of things", i.e. same classes, in each case.  i.e. will you have on container for class Widgits and one container for class Digits etc.?    If not, things get harder.  (Especiually if you are a polymorphism whimp. :-) )

If that is the case, then I woudl say you should use on the STL classes directly, or provide a thin wrapper around it.  There is no need to a heavy wrapper around the STL class, as it propides the type of behavior you want.  i.e you can leave data in the container class and copy it out of the container as many times as you like, like

vector<Widget> C;

Widget W1;

Widget W2 = C[0];
Widget W3 = C[0];
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

abancroft, you probably should have answered.  I will withdraw mine.
>> Should I build my own container class on top of
>> one of STL's containter classes?
I often like to do that because I find the STL syntax ugly and I often want my container to have a more limited set of behaviors.  So I often create a class that has that STL class (I don't actually use STL but the same idea applies) as a data member.  This class then provides a limited number of member functions that have just the interfaces I require of this class.  So there is less chance for code somewhere of accessing the STL class directly and altering it in ways that I didn't originally intend.  This would be considered a "thin wrapper".

>> My gut feel is that this ought to be one line in my .h
>> file, soemthing like:
>>extern slist<ObjectClass> ObjectContainer;

Well what that is doing is defining an instance of the class, not a wrapper class.  So this is using the STL class directly.  That is fine too, its a matter of your needs and your tastes.
it doesn't matter if he have difrent class's he can use STL class's anyway
he can use the containers idea using STL
or maximum use the STL class's and build one of his own

so i think you should use STL and except
abancroft's comment

ntdragon, I'm not understanding you there.
what i tried to say is that klopter can use STL in any case
if he want to use difrent class's he can use pointer's as his data
if he want's more option's then those in STL he can build his calss based on STL class's <i mean using STL class's>

klopterAuthor Commented:
The upshot is that
  list<int> mylist;
gives me exactly what I need and I
don't have to initialize it to
null or delete it after I am through -
it will disappear when the context it
is used in does.

It all seems too easy.

>> It all seems too easy.
That is the idea.

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 2
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now