Constness with standard containters of pointers

[Javier]

Hello,

I have some cuestions about constness with standard containers and
pointers.
Supose I have a list of pointers to some class B:

std::list< B * > > list;

I have readed that constness in std::list is the same that it is in C
arrays (const std::list makes const both the list and its content):

const std::list< B * > > constList;

I can't do:

constList->push_back(x);

But, is it still possible to call any non-const member funcion of B?:

void B::nonConstMemberFuncion();

As in:

constList.begin()->nonConstMemberFuncion();

a) It is possible. I don't want the user to add elements nor modify
any of the list. Which is the correct way of doing this?

const std::list< const B * const > > constList;
const std::list< const B * > constList;

b) It is not possible. Then, I suppose that the next sentences are the
same:

const std::list < B > constList;
const std::list < const B > constList;

If I have the next class:

class A {
public:
std::list< B * > & list() { return m_list; };
private:
std::list< B * > m_list;
};

How I add a const version for A::list()?

What about if I have a smart_pointer instead of a C pointer?

const std::list< boost::shared_ptr< B > > constList =
something();
constList.begin()->nonConstMemberFunction();

Thanks.

 

[Frank Birbacher]

Hi!

const std::list< const B * > constList;

This is the way to go: "const B *" makes the "B" const, thus only const
functions can be called. The "const std::list" makes the list immutable,
thus you need to initialize it during construction.

Regards,
Frank

 

[Javier]

This is the way to go: "const B *" makes the "B" const, thus only const
functions can be called. The "const std::list" makes the list immutable,
thus you need to initialize it during construction.

Ok, then if I have:

class A
{
public:
...
std::list< B * > & getList() { return m_list; };
const std::list< const B * > & getList() const
{ ...???... };

private:
std::list< B * > m_list;
}

What should I write in the const version of "getList()"?

What about the conversion from "std::list< B * >" to "const std::list<
const B * >"... The second const changes the template argument so, is
it a different type?

 

[James Kanze]

[..] if I have:
class A
{
public:
...
std::list< B * > & getList() { return m_list; };
const std::list< const B * > & getList() const
{ ...???... };
private:
std::list< B * > m_list;
}
What should I write in the const version of "getList()"?

You can't do much there. list<T> and list<const T> are
different types and cannot be converted into each other.

That's not quite true. There's nothing to stop you from writing
something like:

std::list< B const* > const A::getList() const
{

Yep.

But the STL is designed so that you can convert any type of sequence
to
any other type, as long as the contained elements are
convertible. I use this rather regularly for initializations,
but it works generally.

 

[Javier]

The OP had the function returning a _reference_.

That's the point. I want to return a reference to the member
attribute, but avoiding the user to make any changes to the container
and its content.

I believe we use the term "convert" overloadedly here. Just as
much as one can "convert" an int into a C string...

I want to "cast" not to create a new object and return it (if it is
possible). If not, the solution posted by James is enough for me (I
think):

std::list< B const* > const A::getList() const
{
return std::list< B const* >( m_list.begin(), m_list.end() ) ;
}

Thanks all.

 

[Ian Collins]

If I have the next class:

class A {
public:
std::list< B * > & list() { return m_list; };
private:
std::list< B * > m_list;
};

How I add a const version for A::list()?

What about if I have a smart_pointer instead of a C pointer?

const std::list< boost::shared_ptr< B > > constList =
something();
constList.begin()->nonConstMemberFunction();

The obvious question is, why? If the list is private to the class, why
would you want to expose it (as a constant or not) to users of the
class? This looks like poor design to me.

If the class is a wrapper for the list and you only want to grant const
access to users, how about providing that access through const iterators?

typedef std::list<B*>::const_iterator const_iterator;

const_iterator begin() const { return m_list.begin(); }
const_iterator end() const { return m_list.end(); }

 

[James Kanze]

Victor Bazarov a écrit :

Javier wrote:
[..] if I have:
class A
{
public:
...
std::list< B * > & getList() { return m_list; };
const std::list< const B * > & getList() const
{ ...???... };
private:
std::list< B * > m_list;
}
What should I write in the const version of "getList()"?
You can't do much there. list<T> and list<const T> are
different types and cannot be converted into each other.

That's not quite true. There's nothing to stop you from writing
something like:
std::list< B const* > const A::getList() const
{
return std::list< B const* >( m_list.begin(), m_list.end() ) ;
}

The OP had the function returning a _reference_.

A const reference. But that's not the point. You can easily
convert a list< T > to a list< T const >. You can also bind the
results of the conversion to a const reference (although in this
case, all that it will give you is a dangling reference). So
the probably solution in his case is to redeclare the function
to return an object, and use the conversion.

I believe we use the term "convert" overloadedly here. Just
as much as one can "convert" an int into a C string...

Yes and no. There's a very real sense that the above is a
conversion, unlike the that of an int into a string. Like most
C++ conversions, however, the result is an rvalue---a copy of
the initial object, and not the object itself.

 

[James Kanze]

That's the point. I want to return a reference to the member
attribute, but avoiding the user to make any changes to the
container and its content.

The question then is why? Why not a copy?

 

[Kai-Uwe Bux]

Hello,

I have some cuestions about constness with standard containers and
pointers.
Supose I have a list of pointers to some class B:

std::list< B * > > list;

I have readed that constness in std::list is the same that it is in C
arrays (const std::list makes const both the list and its content):

const std::list< B * > > constList;

I can't do:

constList->push_back(x);

But, is it still possible to call any non-const member funcion of B?:

void B::nonConstMemberFuncion();

As in:

constList.begin()->nonConstMemberFuncion();

a) It is possible. I don't want the user to add elements nor modify
any of the list. Which is the correct way of doing this?

const std::list< const B * const > > constList;
const std::list< const B * > constList;

b) It is not possible. Then, I suppose that the next sentences are the
same:

const std::list < B > constList;
const std::list < const B > constList;

If I have the next class:

class A {
public:
std::list< B * > & list() { return m_list; };
private:
std::list< B * > m_list;
};

How I add a const version for A::list()?

Your problem is that the list contains B* object and making those const
(e.g. by refering to the list via a const reference) does not make the
pointees const. You could fix that using a smart pointer that forwards
constness:


template < typename T >
class const_forwarding_ptr {

T * the_ptr;

public:

const_forwarding_ptr ( T * ptr )
: the_ptr ( ptr )
{}

T & operator* ( void ) {
return ( *the_ptr );
}

T const & operator* ( void ) const {
return ( *the_ptr );
}

T * operator-> ( void ) {
return ( the_ptr );
}

T const * operator-> ( void ) const {
return ( the_ptr );
}

operator T * ( void ) {
return ( the_ptr );
}

operator T const * ( void ) const {
return ( the_ptr );
}

};


#include <list>

int main ( void ) {
std::list< const_forwarding_ptr< int > > the_list;
int * i_ptr = new int ( 5 );
the_list.push_back( i_ptr );
*(*(the_list.begin())) = 6;
std::list< const_forwarding_ptr< int > > const & c_ref = the_list;
// the following line does not compile:
// *(*(c_ref.begin())) = 5;
}

What about if I have a smart_pointer instead of a C pointer?

const std::list< boost::shared_ptr< B > > constList =
something();
constList.begin()->nonConstMemberFunction();

Depends on the smart pointer. With regard to shared_ptr from C++0X, it does
not forward constness to the pointee but acts similar to a raw pointer.


Best

Kai-Uwe Bux

 

[James Kanze]

I'm assuming you've probably already anticipated this reply
and have an answer ready, but I'll oblige by putting my foot
in it anyway...

"Because if n is the size of the list, making a copy is a
Theta(n) operation, whereas simply returning a reference (were
it possible in this case) would have been constant time."

In other words, you've already tried this solution, and found it
too slow.

The question then might be why you are using std::list, and not
std::vector or std::deque? If you can use one of them,
particularly std::vector, I think you'll find that your
performance problem disappears. It's true that there will be n
copies, but copying a pointer is ridiculously cheap; what's
causing the slowdown is probably the fact that std::list does an
allocation as well for each copy.

Another alternative---probably the best in the long run, at any
rate, is to define what the user wants to do with this list, and
provide an interface directly in your object for doing it. If
nothing else, you can easily provide iterators into it, by
wrapping the std::list<>::iterator. (You might have a look at
boost::iterator for this. If nothing else, it will save some
typing.)

It could be argued though that you should consider the real
reason for returning the list when doing this sort of thing:
if you just want clients of the class to be able to iterate
over the list, then you might be better off returning an
iterator (*) than the list itself (thus avoiding exposing an
aspect of the class's implementation). This allows you to get
round the type problem with the list, since for a list element
type T, you can convert from a T* to a const T* without any
problems.

Exactly. The real question is more along the lines of: what
does the user do with the list (or the reference to the list)
that it gets? And wouldn't it be sensible to make this possible
directly from the interface of your class, so that you don't
(directly or indirectly) expose the internals of your object,

(*) I don't necessarily mean "iterator" in the sense of a
C++-style iterator here - it's just a generic term for
something which will let you iterate over all the elements of
the list.

For better or for worse, we're stuck with the C++ style
iterators. It's what C++ programmers know best. So while I
greatly prefer a GoF iterator, and will always provide an
interface for it when reasonably possible, any iterator which
might be used in generic code, or might be used by client code,
will support the STL idiom, and any code that I write which
might end up being generic (and thus need to iterate over an STL
container) will use the STL iterators, even when my iterators
support a simpler and more intuitive idiom.

The problems with the STL iterators are well known, and
Boost::iterator goes a long way in compensating for them. In
the case where you are simply wrapping another iterator, to
change the return type of operator*(), of course, it's fairly
easy... to screw up. An input iterator is trivial, but the
operator* of a forward iterator must return a reference, so you
have to cache the converted value somewhere. (Technically, I
think that even that is wrong, since the reference is required
to be in the container. But if the iterator doesn't allow
mutation, it's a silly requirement. Still, it does mean that
&*c.begin() != &*c.begin().)