473,881 Members | 1,679 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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::i terator 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 3956
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::i terator 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 "implementa tion 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 "implementa tion 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::i terator 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 Wikström
--
"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::i terator 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 "implementa tion 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 "implementa tion 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_****@netvisi on.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_s tr(). 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_****@netvisi on.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_s tr(). 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_****@netvisi on.co.il> wrote:
Neil Cerutti wrote:
On 2005-11-17, Gregory <g_****@netvisi on.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_s tr(). 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_****@netvisi on.co.il> wrote:
Neil Cerutti wrote:
On 2005-11-17, Gregory <g_****@netvisi on.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_s tr(). 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_****@netvisi on.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 misunderstandin g.

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
2398
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: std::vector<Stuff> m_stuff; Or to wrap it in a 'StuffVector' class, encapsulating operations on the vector...
4
3545
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 from MFC and intentionally I am trying to avoid inheriting from CList and CArray classes. Recently, I became familiar with iterators and have read many articles including the GOF description on what they help to achieve. My understanding so far...
0
1107
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
2864
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. '**************************************************************************** ' Issues '****************************************************************************
2
1321
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. #include "stdafx.h" using namespace System; using namespace System::Collections::Generic; interface class IA;
1
1805
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 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1745.pdf. Now I'm not sure how to interpret a requirement relating to exception safety. It says in 6.3.1.1: "For unordered associative containers, if an exception is thrown by any operation other than the container's hash function from within...
15
4110
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 containers destructors virtual >
21
2230
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 necessarily the same... class base { int x;
2
4618
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 objects. class poly_base { public: virtual int foo(int i, int j) = 0; };
0
9776
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
11105
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10724
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10827
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10403
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
7113
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5781
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5978
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4599
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system

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.