STL containers in C++ class public interface

G

Gregory

I have a question about using STL containers in C++ class public
interface.
Lets say that I want to return some container from class method or
accept class method parameter as some container. For example:

class A
{
public:
const vector<int>& getTable() { return m_table; }

private:
vector<int> m_table;
};

In this case there is strong dependency between class A implementation
and its public interface. When I want to change the implementation by
replacing private vector<> container with list<> I'm forced to replace
the above
getTable() method with 'const list<int>& getTable()'
If clients of class A already used vector specific interface (random
access, for instance)
they will be affected by this change. Bad.
Typedef also does not help here.

class A
{
public:
typedef vector<int> IntContainer;
const IntContainer& getCont() { return m_cont; }

private:
IntContainer m_cont;
};

The IntContainer is still either vector or list with their entire
interface exposed.

Another example. I don't want to expose the whole container in the
public interface. I want to define an iterator to access my private
container entries.

class A
{
public:
typedef vector<int> IntContainer;
typedef IntContainer::iterator IntContIter;

IntContIter begin() { return m_cont.begin; }
IntContIter end() { return m_cont.end; }

private:
IntContainer m_cont;
};

Later I wanted to replace my private vector<> with list<>. I have
problem again.
Since vector<> exposed random access iterator but list<> has
bi-directional iterator.
Class A clients will be affected as before.

What can be done ? I can wrap every STL container with my own container
and expose only small common portion of all STL containers interface
(does it exist ???) in the class public interface and thus protect
clients from the class A implementation changes.
I can also wrap STL container iterators and expose the wrappers in the
public interface.
This seems to be too much work :) Are there any other solutions for
these problems ?
What are accepted guidelines for using STL containers in class public
interface ?

Gregory
 
J

Jonathan Mcdougall

Gregory said:
I have a question about using STL containers in C++ class public
interface.
Lets say that I want to return some container from class method or
accept class method parameter as some container. For example:

class A
{
public:
const vector<int>& getTable() { return m_table; }

private:
vector<int> m_table;
};

In this case there is strong dependency between class A implementation
and its public interface. When I want to change the implementation by
replacing private vector<> container with list<> I'm forced to replace
the above
getTable() method with 'const list<int>& getTable()'
If clients of class A already used vector specific interface (random
access, for instance)
they will be affected by this change. Bad.
Typedef also does not help here.

class A
{
public:
typedef vector<int> IntContainer;
const IntContainer& getCont() { return m_cont; }

private:
IntContainer m_cont;
};

The IntContainer is still either vector or list with their entire
interface exposed.

Another example. I don't want to expose the whole container in the
public interface. I want to define an iterator to access my private
container entries.

class A
{
public:
typedef vector<int> IntContainer;
typedef IntContainer::iterator IntContIter;

IntContIter begin() { return m_cont.begin; }
IntContIter end() { return m_cont.end; }

private:
IntContainer m_cont;
};

Later I wanted to replace my private vector<> with list<>. I have
problem again.
Since vector<> exposed random access iterator but list<> has
bi-directional iterator.
Class A clients will be affected as before.

What can be done ? I can wrap every STL container with my own container
and expose only small common portion of all STL containers interface
(does it exist ???) in the class public interface and thus protect
clients from the class A implementation changes.
I can also wrap STL container iterators and expose the wrappers in the
public interface.
This seems to be too much work :) Are there any other solutions for
these problems ?
What are accepted guidelines for using STL containers in class public
interface ?
Click to expand...

Since the client code depends on the capabilities of the container, it
is not an "implementation detail". What makes you think it is? By
changing the container type, you are not changing the implementation,
you are changing the interface.

So to make the container type irrelevant, you need to somehow make it
an implementation detail. That means to create a wrapper. The wrapper
is the interface, the wrapped container is an implementation detail.

As for how you should wrap the container, that depends on the
circumstances. You cannot simply wrap the iterators and make them
random access, it's impossible because the underlying type may not
support it. I would say you have two choices:

1) roll your own container
2) provide a wrapper which gives access to the common subset of the
standard containers.

Remember, it's an "implementation detail" not because you say so, but
because it shouldn't affect the client.


Jonathan
 
?

=?ISO-8859-1?Q?Erik_Wikstr=F6m?=

I have a question about using STL containers in C++ class public
interface.
Lets say that I want to return some container from class method or
accept class method parameter as some container. For example:

class A
{
public:
const vector<int>& getTable() { return m_table; }

private:
vector<int> m_table;
};

In this case there is strong dependency between class A implementation
and its public interface. When I want to change the implementation by
replacing private vector<> container with list<> I'm forced to replace
the above
getTable() method with 'const list<int>& getTable()'
If clients of class A already used vector specific interface (random
access, for instance)
they will be affected by this change. Bad.
Typedef also does not help here.

class A
{
public:
typedef vector<int> IntContainer;
const IntContainer& getCont() { return m_cont; }

private:
IntContainer m_cont;
};

The IntContainer is still either vector or list with their entire
interface exposed.

Another example. I don't want to expose the whole container in the
public interface. I want to define an iterator to access my private
container entries.

class A
{
public:
typedef vector<int> IntContainer;
typedef IntContainer::iterator IntContIter;

IntContIter begin() { return m_cont.begin; }
IntContIter end() { return m_cont.end; }

private:
IntContainer m_cont;
};

Later I wanted to replace my private vector<> with list<>. I have
problem again.
Since vector<> exposed random access iterator but list<> has
bi-directional iterator.
Class A clients will be affected as before.

What can be done ? I can wrap every STL container with my own container
and expose only small common portion of all STL containers interface
(does it exist ???) in the class public interface and thus protect
clients from the class A implementation changes.
I can also wrap STL container iterators and expose the wrappers in the
public interface.
This seems to be too much work :) Are there any other solutions for
these problems ?
What are accepted guidelines for using STL containers in class public
interface ?

Gregory
Click to expand...

You might(!) be able to use a tamplate so that the client can specify
the type of container used. However, if this is possible depends on your
implementation. That is, if you can make your class generic enough that
it will work with any of the STL-containers and preferably user-made
containers too (or at least a subset of these, every container might not
make sence to use).

Erik Wikström
 
G

Gregory

Jonathan Mcdougall пиÑал(а):
Since the client code depends on the capabilities of the container, it
is not an "implementation detail". What makes you think it is? By
changing the container type, you are not changing the implementation,
you are changing the interface.
Click to expand...

Jonathan, thanks for your reply !

Well, this is actually a trade-off. I can stay with the same interface
that exposes,
say, vector<> container but internally (implementation detail) replace
vector with list,
because list will give me better performance in the internal
algorithms. However
this forces me to convert list to vector when returning it to the
client (performance overhead).
So to make the container type irrelevant, you need to somehow make it
an implementation detail. That means to create a wrapper. The wrapper
is the interface, the wrapped container is an implementation detail.
Click to expand...
As for how you should wrap the container, that depends on the
circumstances. You cannot simply wrap the iterators and make them
random access, it's impossible because the underlying type may not
support it.
Click to expand...

The underlying type may not support it directly, but we can almost
always emulate it using the underlying type - may be not very
efficiently. But these are only iterators, there might be also another
functionality that internal container provides and this job it does
better then previous random access container, so the class would still
benefit from the replacement.

I would say you have two choices:
1) roll your own container
Click to expand...

OK, this seems less applicable, since I do want to continue using STL
containers and benefit from their diverse functionality and robustness.
2) provide a wrapper which gives access to the common subset of the
standard containers.
Click to expand...

Does anybody really do this ? Where can I find example of source
code/examples using this strategy ?
By the way QT library does expose its own containers in its interface.
Remember, it's an "implementation detail" not because you say so, but
because it shouldn't affect the client.


Jonathan
Click to expand...

Regards.

Gregory
 
N

Neil Cerutti

I have a question about using STL containers in C++ class
public interface. Lets say that I want to return some container
from class method or accept class method parameter as some
container. For example:

class A
{
public:
const vector<int>& getTable() { return m_table; }

private:
vector<int> m_table;
};

In this case there is strong dependency between class A
implementation and its public interface.
Click to expand...

Not necessarily. If the internal container type changes, alter
getTable to make a copy of your internal data structure into a
static vector, and return a reference to that. This vector's data
will become invalid as soon as the client calls another mutating
function, but it might be good enough for most purposes, a la
std::string.c_str(). Clients will need to be made aware of this
property, obviously.

You should reconsider whether clients actually need access to
your internal data as a vector. How will clients want to use the
data?

Alternatively, you could provide const_iterators to your internal
data structure. This potentially has the same problem as before,
since clients will not be pleased if your class silently switches
from providing random access iterators to bidirectional
iterators. What you may do to avoid this problem is to provide
only bidirectional iterators, regardless of the internal data
type. That allows you to convert, e.g., to a std::list without
affecting clients. It's admittedly more work. ;-)
 
G

Gregory

Neil said:
Not necessarily. If the internal container type changes, alter
getTable to make a copy of your internal data structure into a
static vector, and return a reference to that. This vector's data
will become invalid as soon as the client calls another mutating
function, but it might be good enough for most purposes, a la
std::string.c_str(). Clients will need to be made aware of this
property, obviously.
Click to expand...

If the vector is static it will be also re-written by a call to the
methods of _another
object_. It seems better to make the vector private and return const
reference to it then only calls to the same object methods will
invalidate it.
You should reconsider whether clients actually need access to
your internal data as a vector. How will clients want to use the
data?

Alternatively, you could provide const_iterators to your internal
data structure. This potentially has the same problem as before,
since clients will not be pleased if your class silently switches
from providing random access iterators to bidirectional
iterators. What you may do to avoid this problem is to provide
only bidirectional iterators, regardless of the internal data
type. That allows you to convert, e.g., to a std::list without
affecting clients. It's admittedly more work. ;-)
Click to expand...

Yes, it's a big, big problem :)

Thanks,

Gregory
 
N

Neil Cerutti

If the vector is static it will be also re-written by a call to
the methods of _another object_.
Click to expand...

Sorry about my ambiguity. I meant static in the member function
getTable; that way there is a seperate one for every instance.
Yes, it's a big, big problem :)
Click to expand...

Since it is self-imposed, you may be able to get around it by
releasing yourself from the obligation of providing access to
internal data as a vector.

Moreover, writing iterator-like classes is much easier than you
seem to think. Give it a try.
 
G

Gregory

Neil said:
Sorry about my ambiguity. I meant static in the member function
getTable; that way there is a seperate one for every instance.
Click to expand...

Sorry, but it's incorrect. There is a single member function
implementation for all
Since it is self-imposed, you may be able to get around it by
releasing yourself from the obligation of providing access to
internal data as a vector.

Moreover, writing iterator-like classes is much easier than you
seem to think. Give it a try.
Click to expand...

Thanks, Neil ! I actually have some expierence in writing iterators
wrappers over
STL iterators. So it seems to be quite easy.

Regards,

Gregory
 
N

Neil Cerutti

Sorry, but it's incorrect. There is a single member function
implementation for all objects. The <this> pointer passed to it
as the first parameter is different.
Click to expand...

Doh! Thanks for correcting my misunderstanding.

In that case, it wouldn't be a very good idea. You'd need to copy
into a normal member.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Is there any better approach to private inheriting from the STL containers? 0
Class with functions that return STL containers with incomplete types 7
C Containers Library vs STL 14
Deriving from STL containers 0
workaround for auto_ptr<> in STL containers? 8
Deriving from STL containers 6
Initialising stl containers 1
Somone's SO question: "Is there an existing library for dynamically-determineddimensional array in c 1

Members online

Total: 579 (members: 5, guests: 574)
Robots: 463

Forum statistics

Threads
474,261
Messages
2,571,040
Members
48,769
Latest member
Clifft

Latest Threads

Top