473,324 Members | 1,856 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,324 software developers and data experts.

STL containers in C++ class public interface

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
8 3904
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
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
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
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
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
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

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
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

12
by: Glen Able | last post by:
Hello, I've been getting into the STL lately for personal projects and I'm can't decide whether to wrap containers or not. So the choice is whether to have a member variable like this: ...
4
by: Merlin | last post by:
Hi, I am a C++ developer and would like to implement container classes for various types of objects. I use MS Visual C++ to compile my code. Nevertheless I like to write code that is independent...
0
by: SpOiLeR | last post by:
Hello! I have something like this: class A; Class B; typedef std::list<A> ContainerA; typedef std::vector<B> ContainerB;
4
by: Ray Dukes | last post by:
What I am looking to do is map the implementation of interface properties and functions to an inherited method of the base class. Please see below. ...
2
by: omellet | last post by:
I'm trying to define a class, A, that has a List<> of interface instances, IA. IA has a property pointing back to a class A instance, so I need to forward define IA in order to use it in A. ...
1
by: yonil | last post by:
I hope this is the correct group for this... I'm currently implementing the TR1 associative containers according to specification found in...
15
by: Nindi73 | last post by:
HI If I define the class DoubleMap such that struct DoubleMap : public std::map<std::string, double>{}; Is there any overhead in calling std::map member functions ? Moreover are STL...
21
by: George Exarchakos | last post by:
Hi everyone, I'd like your help... Can we have a std::list<BASEwhere BASE be the base class of a class hierarchy? I want to add to this list objects that are inherited from BASE class but not...
2
by: Arash Partow | last post by:
Hi all, I've got a question related to emulating aspects of polymorphism with CRTP. Below is a typical polymorphic class hierarchy with a definition of a "somewhat" heterogeneous container of...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, youll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
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: Shllpp 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: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
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.