Standard Template Library as container for Objects

[Michael Winter]

Is the Standard Template Library capable of storing complete objects rather
than pointers. For example, would either of the vectors below (a, c)
function correctly (note the member in C).

class A {};
class B {};
class C {
stl::vector<B> b;
};

std::vector<A> a;
std::vector<C> c;

The reason that I ask is that I had something similar to this in a library
that I was writing. It worked as far as I could add objects to the various
containers and index through them. However, when the objects dropped out of
scope and deallocated their lists an assertion was thrown (I forget the
message, but it was from deep within the bowels of CRT new) for each class
object that had a vector containing a class. In release mode, all hell
broke loose (access violations, everywhere).
I know that this would seem to scream, "No, don't use STL containers with
objects!" but I was wondering if there was any other explanation, like using
STL with DLLs, or linking the wrong run-time and using STL, or using
different and incompatible run-times between the test program and the DLL
project. So, could those be the cause, or is it just a case of using
pointers to objects instead? Would that include the stl::auto_ptr template
class?
Are there any rules that should be followed when it comes to the various
run-time libraries? Such as what combinations produce problems, and when
generally should the different libraries be used? Those sorts of details
seemed to be omitted from books, so are there any good references out there
(preferably web-sites, I'm poor, but *really* excellent books are OK).

Thank you (in advance),

Mike

--
Michael Winter
M.Winter@[no-spam]blueyonder.co.u k (remove [no-spam] to reply by e-mail)

[Marijn]

"Michael Winter" <M.Winter@[no-spam]blueyonder.co.u k> schreef in bericht
news:eE******** *************** @news-text.cableinet. net...

Is the Standard Template Library capable of storing complete objects rather than pointers. For example, would either of the vectors below (a, c)
function correctly (note the member in C).
Basically, storing objects in std:: containers is safe as long as the class
of those objects
support value semantics. Your object will basically need a safe (and
preferably efficient)
default constructor, copy constructor and assignment operator. I suspect
that in the example
you show below you are using a class that does not (properly) implement
these, and that
is what causes the problem at cleanup (double deletes maybe?).

Marijn Haverbeke

class A {};
class B {};
class C {
stl::vector<B> b;
};

std::vector<A> a;
std::vector<C> c;

The reason that I ask is that I had something similar to this in a library
that I was writing. It worked as far as I could add objects to the various containers and index through them. However, when the objects dropped out of scope and deallocated their lists an assertion was thrown (I forget the
message, but it was from deep within the bowels of CRT new) for each class
object that had a vector containing a class. In release mode, all hell
broke loose (access violations, everywhere).
I know that this would seem to scream, "No, don't use STL containers with
objects!" but I was wondering if there was any other explanation, like using STL with DLLs, or linking the wrong run-time and using STL, or using
different and incompatible run-times between the test program and the DLL
project. So, could those be the cause, or is it just a case of using
pointers to objects instead? Would that include the stl::auto_ptr template class?
Are there any rules that should be followed when it comes to the various
run-time libraries? Such as what combinations produce problems, and when
generally should the different libraries be used? Those sorts of details
seemed to be omitted from books, so are there any good references out there (preferably web-sites, I'm poor, but *really* excellent books are OK).

Thank you (in advance),

Mike

--
Michael Winter
M.Winter@[no-spam]blueyonder.co.u k (remove [no-spam] to reply by e-mail)

[Attila Feher]

Michael Winter wrote:

Is the Standard Template Library capable of storing complete objects
rather than pointers. For example, would either of the vectors below
(a, c) function correctly (note the member in C).

class A {};
class B {};
class C {
stl::vector<B> b;
};

std::vector<A> a;
std::vector<C> c;

The reason that I ask is that I had something similar to this in a
library that I was writing. It worked as far as I could add objects
to the various containers and index through them. However, when the
objects dropped out of scope and deallocated their lists an assertion
was thrown (I forget the message, but it was from deep within the
bowels of CRT new) for each class object that had a vector containing
a class. In release mode, all hell broke loose (access violations,
everywhere).
I know that this would seem to scream, "No, don't use STL containers
with objects!" but I was wondering if there was any other
explanation, like using STL with DLLs, or linking the wrong run-time

[SNIP]

It was most probably using DLLs. There is some issue (off-topic here) on
Windows if you static-link the runtime to the DLL and the EXE you will get
separate heaps and trouble.

The STL containers are fully capable of storing complete objects and
destroying them properly when they are removed.

--
Attila aka WW

[Mike Smith]

Attila Feher wrote:

It was most probably using DLLs. There is some issue (off-topic here) on
Windows if you static-link the runtime to the DLL and the EXE you will get
separate heaps and trouble.

Yes, I find that using the dynamic runtime for all DLLs and EXEs is the
safest practice (and produces the smallest output file). Note that this
means that MSVCPxx.DLL needs to be installed on the target machine if it
is not already present.

--
Mike Smith

[Michael Winter]

Thanks for all your help.

Marjin: I didn't specify the copy constructor and assignment operator as
the defaults should suffice, but I'll check. I suppose it's better practice
to explicitly define them anyway.

Attila and Mike: I've posted a question along those lines to a Windows
group, so hopefully they'll provide me some more information.

Again, thank you.

Mike

--
Michael Winter
M.Winter@[no-spam]blueyonder.co.u k (remove [no-spam] to reply)

[Ron Natalie]

"Marijn" <ma******@hotma il.com> wrote in message news:3f******** *************@n ews.inter.NL.ne t...

Basically, storing objects in std:: containers is safe as long as the class
of those objects
support value semantics. Your object will basically need a safe (and
preferably efficient)
default constructor, copy constructor and assignment operator.

A default constructor is not required.

[Ron Natalie]

"Michael Winter" <M.Winter@[no-spam]blueyonder.co.u k> wrote in message news:Dl******** ***********@new s-text.cableinet. net...

Thanks for all your help.

Marjin: I didn't specify the copy constructor and assignment operator as
the defaults should suffice, but I'll check. I suppose it's better practice
to explicitly define them anyway.

I don't feel it is. The implementation of these is not trivial to reproduce.
You have to copy/assign each base class and member seperately. If
the compiler generated ones are correct (and if your base classes and
members are all well behaved independentally , it will be).

[Michael Winter]

> > Marjin: I didn't specify the copy constructor and assignment operator
as

the defaults should suffice, but I'll check. I suppose it's better practice to explicitly define them anyway.
I don't feel it is. The implementation of these is not trivial to

reproduce. You have to copy/assign each base class and member seperately. If
the compiler generated ones are correct (and if your base classes and
members are all well behaved independentally , it will be).

I didn't consider large, complex classes. The ones this post relates to
aren't. It's a shame that the we can't have the best of both worlds: have
the compiler worry about simple members and leave the more complicated parts
(deep-copies, for example) for the developer.

Mike

--
Michael Winter
M.Winter@[no-spam]blueyonder.co.u k (remove [no-spam] to reply)

[Ron Natalie]

"Michael Winter" <M.Winter@[no-spam]blueyonder.co.u k> wrote in message news:9H******** ***********@new s-text.cableinet. net...

. It's a shame that the we can't have the best of both worlds: have
the compiler worry about simple members and leave the more complicated parts
(deep-copies, for example) for the developer.

Well, it's not clear how you would do that. How do you specify which members/bases
are not automatically copied and which are?

It's workable in C++. If you only have a few things that require special copying
semantics, wrap them in classes that perform those operations. That's one of
the reasons that string is better than char*, and vector is better than handling your
own new'd array, etc...

[Michael Winter]

> Well, it's not clear how you would do that. How do you specify which
members/bases

are not automatically copied and which are?
That's why I said it's a shame :) You can't in any real sense. Sorry, it
was a pointless comment.
It's workable in C++. If you only have a few things that require special copying semantics, wrap them in classes that perform those operations. That's one of the reasons that string is better than char*, and vector is better than handling your own new'd array, etc...

Mike