container within a container issue: set in the map

[puzzlecracker]

Guys, what is more preferable, given that I don't have access to boost
or shared pointers:

std::map<T*, std::set<T2*> * > *_myMap;

vs.

std::map<T*, std::set<T2*> > *myMap;

Notice that in the latter, containing set is not a pointer. Could
there be a drawbacks with the former, like copying over when trying to
insert elements into it?


Thanks

 

[Kai-Uwe Bux]

Guys, what is more preferable, given that I don't have access to boost
or shared pointers:

std::map<T*, std::set<T2*> * > *_myMap;

vs.

std::map<T*, std::set<T2*> > *myMap;

Notice that in the latter, containing set is not a pointer. Could
there be a drawbacks with the former, like copying over when trying to
insert elements into it?

Not enough data. For starters:

a) What is wrong with no pointers:

std::map< T, std::set<T2> > myMap;

b) What are typical instances for T and T2?

c) Are you sure that you don't want to use custom comparison predicates? and
related: can your pointers be null? and how do they arise anyway?


Best

Kai-Uwe Bux

 

[James Kanze]

Guys, what is more preferable, given that I don't have access
to boost or shared pointers:

std::map<T*, std::set<T2*> * > *_myMap;

std::map<T*, std::set<T2*> > *myMap;

Notice that in the latter, containing set is not a pointer.
Could there be a drawbacks with the former, like copying over
when trying to insert elements into it?

I'll second Kai-Uwe's comments, but with regards to the question
about copying: the node based containers (list, set and map)
never copy an object once it is in the container. More
generally, check the container specifications: if insert and
erase don't invalidate references and pointers into the
container (except for references or pointers to the erased
element), then copying can't take place.

 

[tony_in_da_uk]

[snip]
generally, check the container specifications: if insert and
erase don't invalidate references and pointers into the
container (except for references or pointers to the erased
element), then copying can't take place.

I'm confident this is true for all STL implementations, but would just
make the point that iterators in general are free to do things like
keep a pointer to the container and an offset, and their on-going
validity may not guarantee copying hasn't taken place. Not sure of
the Standard's actual requirements, but I hope none of us are bored
enough to care....

Tony

 

[Juha Nieminen]

std::map<T*, std::set<T2*> * > *_myMap;

I would remove all the asterisks from there, or at the very least,
replace them with some suitable smart pointer. That kind of code is
*very* hard to make safe because you need to perform quite a lot of
manual memory management.

(And do you really want to sort the elements by a *pointer* to T
rather than the *value* of T? It is possible, but oftentimes perhaps not
the best of ideas. It can cause all kinds of logistical problems, unless
you really know what you are doing and it's something you explicitly
want to do.)

 

[puzzlecracker]

I would remove all the asterisks from there, or at the very least,
replace them with some suitable smart pointer. That kind of code is
*very* hard to make safe because you need to perform quite a lot of
manual memory management.

(And do you really want to sort the elements by a *pointer* to T
rather than the *value* of T? It is possible, but oftentimes perhaps not
the best of ideas. It can cause all kinds of logistical problems, unless
you really know what you are doing and it's something you explicitly
want to do.)

I would like to use smart pointers but, as I said, I cannot access
fancy library, and auto_ptr is obviously not suitable here.

 

[James Kanze]

[snip]
generally, check the container specifications: if insert and
erase don't invalidate references and pointers into the
container (except for references or pointers to the erased
element), then copying can't take place.

I'm confident this is true for all STL implementations, but
would just make the point that iterators in general are free
to do things like keep a pointer to the container and an
offset, and their on-going validity may not guarantee copying
hasn't taken place.

That's probably the most common implementation, in fact. And it
does mean that iterators may remain valid despite copying. But
if you reread what I wrote, I said to check whether pointers and
references remain valid. No matter how the iterator is
implemented, if a pointer to the element remains valid, then the
element can't have been copied.

 

[James Kanze]

[...]

I would like to use smart pointers but, as I said, I cannot
access fancy library, and auto_ptr is obviously not suitable
here.

Smart pointers don't necessarily imply a fancy library; I think
my original implementation of RefCntPtr was only about 50 lines
(and in many cases, it's still preferable to
boost::shared_ptr---simplicity can be more important than
flexibility).

 

[tony_in_da_uk]

[snip]
generally, check the container specifications: if insert and
erase don't invalidate references and pointers into the
container (except for references or pointers to the erased
element), then copying can't take place.

I'm confident this is true for all STL implementations, but
would just make the point that iterators in general are free
to do things like keep a pointer to the container and an
offset, and their on-going validity may not guarantee copying
hasn't taken place.

That's probably the most common implementation, in fact. And it
does mean that iterators may remain valid despite copying. But
if you reread what I wrote, I said to check whether pointers and
references remain valid. No matter how the iterator is
implemented, if a pointer to the element remains valid, then the
element can't have been copied.

So you did. Sorry. - Tony