By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,952 Members | 1,416 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,952 IT Pros & Developers. It's quick & easy.

STL containers in C++ class public interface

P: n/a
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

Nov 22 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Gregory wrote:
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 ?


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

Nov 22 '05 #2

P: n/a
On 2005-11-18 00:16, Gregory wrote:
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


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 Wikstrm
--
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure
out how to use my telephone" -- Bjarne Stroustrup
Nov 22 '05 #3

P: n/a
Jonathan Mcdougall писал(а):
Gregory wrote:
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 ?
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.


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


Regards.

Gregory

Nov 22 '05 #4

P: n/a
On 2005-11-17, Gregory <g_****@netvision.co.il> wrote:
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.


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. ;-)

--
Neil Cerutti
Nov 22 '05 #5

P: n/a
Neil Cerutti wrote:
On 2005-11-17, Gregory <g_****@netvision.co.il> wrote:
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.
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.


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. ;-)


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

Thanks,

Gregory

Nov 22 '05 #6

P: n/a
On 2005-11-18, Gregory <g_****@netvision.co.il> wrote:
Neil Cerutti wrote:
On 2005-11-17, Gregory <g_****@netvision.co.il> wrote:
> 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.


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.


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


Sorry about my ambiguity. I meant static in the member function
getTable; that way there is a seperate one for every instance.
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. ;-)


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


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.

--
Neil Cerutti
Nov 22 '05 #7

P: n/a

Neil Cerutti wrote:
On 2005-11-18, Gregory <g_****@netvision.co.il> wrote:
Neil Cerutti wrote:
On 2005-11-17, Gregory <g_****@netvision.co.il> wrote:
> 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.

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.


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


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


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.
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. ;-)


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


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.

--
Neil Cerutti


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

Regards,

Gregory

Nov 22 '05 #8

P: n/a
On 2005-11-18, Gregory <g_****@netvision.co.il> wrote:
Neil Cerutti wrote:
Sorry about my ambiguity. I meant static in the member
function getTable; that way there is a seperate one for every
instance.


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.


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.

--
Neil Cerutti
Nov 22 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.