Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Questions about destructors on std library containers

Reply
Thread Tools

Questions about destructors on std library containers

 
 
Ross Boylan
Guest
Posts: n/a
 
      02-12-2004
I am trying to understand under what circumstances destructors get called
with std::vector. I have an application in which I will put real objects,
not just pointers, in the vector.

1. The standard says that empty() has constant complexity. If it actually
called the destructor for each object, it seems to me it would have
linear complexity. Does empty() call the destructor for each object in the
container? If yes, why is it described as having constant commplexity?
If no, that seems like a problem too.

2. The standard describes clear by saying that it behaves like
erase(begin, end). That seems as if it would erase the first element, copying
all succedding elements over it, and so on, which is obviously very
inefficient. Is it safe to assume something more reasonable is happening
under the covers?

3. Does erase call the destructor for the elements erased?
More properly, I guess I should ask if the elements freed at the end after
being moved over erased items are cleared. I'd probably only be erasing
the whole vector or its last element.

As I'm writing this I realize I may have a basic confusion, and that
constructors and destructors are only called at the beginning and end
of the vector's life (and when its capacity expands). The rest of the
time elements are either in use or not, with the behavior of the assignment
operator being key. Is that what's really going on?


I'm interested both in what can and can't be inferred from the standard, and
in what current compiler practice on different platforms is--in other words,
what's safe to assume in portable code.


 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      02-12-2004
"Ross Boylan" <(E-Mail Removed)> wrote...
> I am trying to understand under what circumstances destructors get called
> with std::vector. I have an application in which I will put real objects,
> not just pointers, in the vector.
>
> 1. The standard says that empty() has constant complexity. If it actually
> called the destructor for each object, it seems to me it would have
> linear complexity. Does empty() call the destructor for each object in

the
> container? If yes, why is it described as having constant commplexity?
> If no, that seems like a problem too.


'empty' is not the same as 'clear'. Do not confuse the two. For C++
library containers, 'empty' is an adjective, not a verb.

> 2. The standard describes clear by saying that it behaves like
> erase(begin, end). That seems as if it would erase the first element,

copying
> all succedding elements over it, and so on, which is obviously very
> inefficient. Is it safe to assume something more reasonable is happening
> under the covers?


Absolutely. When semantics are explained, it doesn't mean that the
implementation is precisely the same. Do not confuse semantics and
implementation.

>
> 3. Does erase call the destructor for the elements erased?


Yes.

> More properly, I guess I should ask if the elements freed at the end after
> being moved over erased items are cleared.


I am not sure I completely understand the sentence, but elements can
be freed even in the middle of erasing, during the move. std::vector
is a tricky container, it has to reallocate and move things all the
time, so the old elements will get destroyed right after new copies of
them are made.

> I'd probably only be erasing
> the whole vector or its last element.


Don' make no difference, they are still gonna get destroyed. Hafta.

>
> As I'm writing this I realize I may have a basic confusion, and that
> constructors and destructors are only called at the beginning and end
> of the vector's life (and when its capacity expands).


....and when you insert or remove an element in the middle. IOW, every
time elements get moved around.

> The rest of the
> time elements are either in use or not, with the behavior of the

assignment
> operator being key. Is that what's really going on?


Plenty. Why not trace all the constructor and destructor calls? It's
fun and it's educational. It's educational fun.

> I'm interested both in what can and can't be inferred from the standard,

and
> in what current compiler practice on different platforms is--in other

words,
> what's safe to assume in portable code.


Nothing is safe to assume except what's said in the Standard.

V


 
Reply With Quote
 
 
 
 
Ivan Vecerina
Guest
Posts: n/a
 
      02-12-2004
"Ross Boylan" <(E-Mail Removed)> wrote in message
newsan.2004.02.12.00.13.04.615017@stanfordalumni .org...
> I am trying to understand under what circumstances destructors get called
> with std::vector. I have an application in which I will put real objects,
> not just pointers, in the vector.
>
> 1. The standard says that empty() has constant complexity. If it actually
> called the destructor for each object, it seems to me it would have
> linear complexity. Does empty() call the destructor for each object in

the
> container? If yes, why is it described as having constant commplexity?
> If no, that seems like a problem too.


A conforming implementation of empty() is: return this->size() > 0;
This function does not empty the vector ( unlike clear() ): it only
returns a boolean that indicates whether the container is empty or not.

> 2. The standard describes clear by saying that it behaves like
> erase(begin, end). That seems as if it would erase the first element,

copying
> all succedding elements over it, and so on, which is obviously very
> inefficient. Is it safe to assume something more reasonable is happening
> under the covers?

erase() does not remove elements one by one: the whole range is "removed"
by copying/moving the following elements over it. Then the unused trailing
elements are removed.
Say if the first three elements of ABCDEFGH are erased, steps that will
typically happen are:
DEFGH are copied down using the assignment operator --> DEFGHFGH
The trailing elements are destroyed --> DEFGH

> 3. Does erase call the destructor for the elements erased?

Yes.
> More properly, I guess I should ask if the elements freed at the end after
> being moved over erased items are cleared. I'd probably only be erasing
> the whole vector or its last element.

Which means you can call clear() and pop_back(), respectively,
instead of erase().

> As I'm writing this I realize I may have a basic confusion, and that
> constructors and destructors are only called at the beginning and end
> of the vector's life (and when its capacity expands). The rest of the
> time elements are either in use or not, with the behavior of the

assignment
> operator being key. Is that what's really going on?


The capacity of a vector is only allocated as raw memory.
The number of constructed objects within the vector is always equal to
the value returned by vector::size().

> I'm interested both in what can and can't be inferred from the standard,

and
> in what current compiler practice on different platforms is--in other

words,
> what's safe to assume in portable code.

No 'ghost' objects can be constructed by std::vector, given than:
- the element contained in an std::vector may not have a default
constructor
- keeping hidden copies of elements that have been erased would have
unexpected effects -- and is not allowed.



hth, Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form


 
Reply With Quote
 
Sharad Kala
Guest
Posts: n/a
 
      02-12-2004

"Ivan Vecerina" <(E-Mail Removed)> wrote in message
news:c0f308$2ok$(E-Mail Removed)...
> "Ross Boylan" <(E-Mail Removed)> wrote in message
> newsan.2004.02.12.00.13.04.615017@stanfordalumni .org...
> > I am trying to understand under what circumstances destructors get called
> > with std::vector. I have an application in which I will put real objects,
> > not just pointers, in the vector.
> >
> > 1. The standard says that empty() has constant complexity. If it actually
> > called the destructor for each object, it seems to me it would have
> > linear complexity. Does empty() call the destructor for each object in

> the
> > container? If yes, why is it described as having constant commplexity?
> > If no, that seems like a problem too.

>
> A conforming implementation of empty() is: return this->size() > 0;
> This function does not empty the vector ( unlike clear() ): it only
> returns a boolean that indicates whether the container is empty or not.


Josuttis in his book "The C++ standard library" recommends empty() over
container.size() > 0. He says it is _usually_ more efficient.
Given this implementation this might not be true.

> > 2. The standard describes clear by saying that it behaves like
> > erase(begin, end). That seems as if it would erase the first element,

> copying
> > all succedding elements over it, and so on, which is obviously very
> > inefficient. Is it safe to assume something more reasonable is happening
> > under the covers?

> erase() does not remove elements one by one: the whole range is "removed"
> by copying/moving the following elements over it. Then the unused trailing
> elements are removed.
> Say if the first three elements of ABCDEFGH are erased, steps that will
> typically happen are:
> DEFGH are copied down using the assignment operator --> DEFGHFGH
> The trailing elements are destroyed --> DEFGH

hmm..IIRC, they are not.
One must take care to erase the trailing elements (i.e FGH).

Best wishes,
Sharad


 
Reply With Quote
 
John Harrison
Guest
Posts: n/a
 
      02-12-2004

"Sharad Kala" <(E-Mail Removed)> wrote in message
news:c0f4jh$16a5ii$(E-Mail Removed)-berlin.de...
>
> "Ivan Vecerina" <(E-Mail Removed)> wrote in message
> news:c0f308$2ok$(E-Mail Removed)...
> > "Ross Boylan" <(E-Mail Removed)> wrote in message
> > newsan.2004.02.12.00.13.04.615017@stanfordalumni .org...
> > > I am trying to understand under what circumstances destructors get

called
> > > with std::vector. I have an application in which I will put real

objects,
> > > not just pointers, in the vector.
> > >
> > > 1. The standard says that empty() has constant complexity. If it

actually
> > > called the destructor for each object, it seems to me it would have
> > > linear complexity. Does empty() call the destructor for each object

in
> > the
> > > container? If yes, why is it described as having constant

commplexity?
> > > If no, that seems like a problem too.

> >
> > A conforming implementation of empty() is: return this->size() > 0;
> > This function does not empty the vector ( unlike clear() ): it only
> > returns a boolean that indicates whether the container is empty or not.

>
> Josuttis in his book "The C++ standard library" recommends empty() over
> container.size() > 0. He says it is _usually_ more efficient.
> Given this implementation this might not be true.
>


nitpick

empty() is the same as size() == 0

surely.

john


 
Reply With Quote
 
Ivan Vecerina
Guest
Posts: n/a
 
      02-12-2004
"Sharad Kala" <(E-Mail Removed)> wrote in message
news:c0f4jh$16a5ii$(E-Mail Removed)-berlin.de...
|
| "Ivan Vecerina" <(E-Mail Removed)> wrote in message
| news:c0f308$2ok$(E-Mail Removed)...
....
| > A conforming implementation of empty() is: return this->size() > 0;
^^^^^^^^^^
Note that my comment was about behavior, not performance or style.

| Josuttis in his book "The C++ standard library" recommends empty() over
| container.size() > 0. He says it is _usually_ more efficient.
| Given this implementation this might not be true.
Indeed, his advice is not universally true. Some implementations of
vector::empty() are definitely implemented by calling vector::size().

However, style-wise, I would concur that calling empty() is better
than comparing size() to zero. ( just as I recommended calling
clear() and pop_back() instead of erase(), when applicable )

| > > 2. The standard describes clear by saying that it behaves like
| > > erase(begin, end). That seems as if it would erase the first element,
| > copying
| > > all succedding elements over it, and so on, which is obviously very
| > > inefficient. Is it safe to assume something more reasonable is
happening
| > > under the covers?
| > erase() does not remove elements one by one: the whole range is
"removed"
| > by copying/moving the following elements over it. Then the unused
trailing
| > elements are removed.
| > Say if the first three elements of ABCDEFGH are erased, steps that will
| > typically happen are:
| > DEFGH are copied down using the assignment operator --> DEFGHFGH
| > The trailing elements are destroyed --> DEFGH
| hmm..IIRC, they are not.
| One must take care to erase the trailing elements (i.e FGH).
Not correct.

In the context of the OP, it seemed clear that this discussion was about
the vector::erase member function. This member function is not to be
confused with the non-member std::erase algorithm (to which your
comment would applly).

C++ standard 23.2.4.3/4 (about vector::erase):
Complexity: The destructor of T is called the number of times equal to the
number of the elements erased, but the assignment operator of T is called
the number of times equal to the number of elements in the vector after the
erased elements.


Regards,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form


 
Reply With Quote
 
Rob Williscroft
Guest
Posts: n/a
 
      02-12-2004
John Harrison wrote in news:c0f8hr$16ssf0$(E-Mail Removed)-berlin.de:

> nitpick
>
> empty() is the same as size() == 0
>
> surely.
>


With some implementations of std::list<> this is not the case.

In these implementations size() is calculated (std::distance( ... ))
every time it is called, empty() just needs to check wether the list
is empty or not. So its constant-time vs. O(n).

With these implementations splice() is faster because they don't
maintain a seperate size member.

Rob.
--
http://www.victim-prime.dsl.pipex.com/
 
Reply With Quote
 
John Harrison
Guest
Posts: n/a
 
      02-12-2004

"Rob Williscroft" <(E-Mail Removed)> wrote in message
news:Xns948DA283E8214ukcoREMOVEfreenetrtw@195.129. 110.204...
> John Harrison wrote in news:c0f8hr$16ssf0$(E-Mail Removed)-berlin.de:
>
> > nitpick
> >
> > empty() is the same as size() == 0
> >
> > surely.
> >

>
> With some implementations of std::list<> this is not the case.
>
> In these implementations size() is calculated (std::distance( ... ))
> every time it is called, empty() just needs to check wether the list
> is empty or not. So its constant-time vs. O(n).
>
> With these implementations splice() is faster because they don't
> maintain a seperate size member.
>
> Rob.
> --
> http://www.victim-prime.dsl.pipex.com/


Well I wasn't talking about efficiency I was just correcting the obvious
mistake that 'empty() is that same as size() > 0' which two posters had
made.

But since you brought up the topic I think that the standard requires size()
to be O(1) and allows splice on different lists to be O(n).

john


 
Reply With Quote
 
Ron Natalie
Guest
Posts: n/a
 
      02-12-2004

"Ivan Vecerina" <(E-Mail Removed)> wrote in message news:c0f308$2ok$(E-Mail Removed)...

> A conforming implementation of empty() is: return this->size() > 0;
>


Actually, that is specific NOT conforming for containers in general.
As alluded to in the original post, empty has constant complexity.
size() may take longer.

 
Reply With Quote
 
Rob Williscroft
Guest
Posts: n/a
 
      02-12-2004
John Harrison wrote in
news:c0gabm$16edm1$(E-Mail Removed)-berlin.de:

>> With some implementations of std::list<> this is not the case.
>>
>> In these implementations size() is calculated (std::distance( ... ))
>> every time it is called, empty() just needs to check wether the list
>> is empty or not. So its constant-time vs. O(n).
>>
>> With these implementations splice() is faster because they don't
>> maintain a seperate size member.
>>


>
> Well I wasn't talking about efficiency I was just correcting the
> obvious mistake that 'empty() is that same as size() > 0' which two
> posters had made.
>
> But since you brought up the topic I think that the standard requires
> size() to be O(1) and allows splice on different lists to be O(n).
>


In a note (bottom of 23.1 Table 65) it says size() "should have
constant complexity", it requires that splice has complexity
"Contant Time" 23.2.2.4/6

So I was wrong splice() is required to be O(1), I was under the
impression that this was upto the implementor, but this is the first
time I've checked the standard.

Rob.
--
http://www.victim-prime.dsl.pipex.com/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Are sequence containers not a subset of general containers? Sebastian Mach C++ 5 10-06-2012 07:54 PM
Containers of iterators vs. containers of references clark.coleman@att.net C++ 7 01-25-2008 01:37 PM
/usr/bin/ld: ../../dist/lib/libjsdombase_s.a(BlockGrouper.o)(.text+0x98): unresolvable relocation against symbol `std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostre silverburgh.meryl@gmail.com C++ 3 03-09-2006 12:14 AM
How do the STL containers interact with destructors/constructors? velthuijsen C++ 3 02-13-2004 02:52 PM
Is it a right way for using containers std::list< std::string > strList ? Anton C++ 1 08-06-2003 02:10 PM



Advertisments