![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Speaking of RAII and all...
When an object is stuck into a standard collection in C++, and then the
collection goes out of scope, what order is defined on the destructors of
the things in the collection? I wouldn't imagine it's the order they were
inserted (at least for a random-access type collection). Does a stack
destruct in a different order than a queue does, for example? Does a vector
always destruct on increasing indexes? (An array doesn't call the
destructors of its element, does it?)
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> When an object is stuck into a standard collection in C++, and then the
> collection goes out of scope, what order is defined on the destructors of
> the things in the collection? I wouldn't imagine it's the order they were
> inserted (at least for a random-access type collection). Does a stack
> destruct in a different order than a queue does, for example? Does a vector
> always destruct on increasing indexes? (An array doesn't call the
> destructors of its element, does it?)
Funny, I have never thought of that. If I had to guess, I'd say that
the standard leaves it up to the implementation.
Arrays (either stack-allocated or dynamically allocated with 'new') are,
however, guaranteed to be constructed in the order of increasing indexes
and destroyed in the reverse order.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Funny, I have never thought of that.
I can see where having a stack destruct as if it's popping things could be
useful, for example. The topic came up discussing the Go "defer" bit in
another thread.
> If I had to guess, I'd say that
> the standard leaves it up to the implementation.
OK. I'll look it up if it ever comes up.
> Arrays (either stack-allocated or dynamically allocated with 'new') are,
> however, guaranteed to be constructed in the order of increasing indexes
> and destroyed in the reverse order.
Oh, so arrays do destruct. That's good to know. I guess that makes sense,
tho, now that I think about it, since the values get constructed if they
have constructors.
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> Speaking of RAII and all...
>
> When an object is stuck into a standard collection in C++, and then the
> collection goes out of scope, what order is defined on the destructors
> of the things in the collection? I wouldn't imagine it's the order they
> were inserted (at least for a random-access type collection). Does a
> stack destruct in a different order than a queue does, for example? Does
> a vector always destruct on increasing indexes?
See if you can discern the order of construction. The safest
destruction reverses this order.
Regards,
John
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Oh, so arrays do destruct. That's good to know. I guess that makes sense,
> tho, now that I think about it, since the values get constructed if they
> have constructors.
You would have a pretty bad danger of memory leak if arrays wouldn't
destroy their elements.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> You would have a pretty bad danger of memory leak if arrays wouldn't
> destroy their elements.
Yeah, I just wasn't thinking clearly, thinking "arrays aren't classes, so
they don't have destructors."
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Warp wrote:
> > You would have a pretty bad danger of memory leak if arrays wouldn't
> > destroy their elements.
> Yeah, I just wasn't thinking clearly, thinking "arrays aren't classes, so
> they don't have destructors."
Curiously, *all* primitive types in C++ have default constructors. At
least in syntax. (This default constructor initializes the variable to zero.)
It can be called like any other constructor. So you could have something
like:
void foo(int i = int()) { ... }
In other words, the foo() function takes optionally an int as parameter,
and if none is specified, it takes a default-initialized int instead.
Of course the above is *completely* equivalent to:
void foo(int i = 0) { ... }
so what's the point? It becomes important with (yeah, you guessed it)
templates. You can write something like:
template<typename T>
class MyClass
{
public:
void foo(T value = T());
};
and it will work even if T is a primitive type (such as int).
(The default function parameter value is just one example of many
situations where it becomes useful.)
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |