Is a created before b?

[ikl]

Given three classes:

class A
{
};

class B
{
};

class C
{
A a;
B b;
};

Is a for sure instantiated before b? If not, then is there any way to make
sure that? How to make sure a is deleted after b's deletion?

Thanks!

[Russell Hanneken]

ikl wrote:

Given three classes:

class A
{
};

class B
{
};

class C
{
A a;
B b;
};

Is a for sure instantiated before b?

Yes. Member variables are constructed in the order in which they appear
in the class definition.

--
Russell Hanneken
rg********@pobox.com
Remove the 'g' from my address to send me mail.

[Russell Hanneken]

ikl wrote:

Given three classes:

class A
{
};

class B
{
};

class C
{
A a;
B b;
};

Is a for sure instantiated before b?

Yes. Member variables are constructed in the order in which they appear
in the class definition.

--
Russell Hanneken
rg********@pobox.com
Remove the 'g' from my address to send me mail.

[Jeff Schwab]

ikl wrote:

Given three classes:

class A
{
};

class B
{
};

class C
{
A a;
B b;
};

Is a for sure instantiated before b?
Yes.
How to make sure a is deleted after b's deletion?

Since neither "a" nor "b" is allocated dynamically, I think you mean
"destructed," not "deleted." The answer is that "b" will be destructed
first unless you jump through some pretty contorted hoops. Is there a
particular situation in which you find the default behavior unsuitable?

[Jeff Schwab]

ikl wrote:

Given three classes:

class A
{
};

class B
{
};

class C
{
A a;
B b;
};

Is a for sure instantiated before b?
Yes.
How to make sure a is deleted after b's deletion?

Since neither "a" nor "b" is allocated dynamically, I think you mean
"destructed," not "deleted." The answer is that "b" will be destructed
first unless you jump through some pretty contorted hoops. Is there a
particular situation in which you find the default behavior unsuitable?

[Neil Zanella]

Since the clas A instance is specified prior to the class B instance it
will be guaranteed to be constructed before the class B instance. The
destructors are then guaranteed to be run in the reverse order. This
is regardless of any way constructors for such classes A and B may
be specified in initializer lists for class C.

Regards,

Neil

On Mon, 5 Apr 2004, ikl wrote:

Given three classes:

class A
{
};

class B
{
};

class C
{
A a;
B b;
};
int main() {
C c;
}

Is a for sure instantiated before b? If not, then is there any way to make
sure that? How to make sure a is deleted after b's deletion?

Thanks!

[Neil Zanella]

Since the clas A instance is specified prior to the class B instance it
will be guaranteed to be constructed before the class B instance. The
destructors are then guaranteed to be run in the reverse order. This
is regardless of any way constructors for such classes A and B may
be specified in initializer lists for class C.

Regards,

Neil

On Mon, 5 Apr 2004, ikl wrote:

Given three classes:

class A
{
};

class B
{
};

class C
{
A a;
B b;
};
int main() {
C c;
}

Is a for sure instantiated before b? If not, then is there any way to make
sure that? How to make sure a is deleted after b's deletion?

Thanks!

[Rolf Magnus]

Jeff Schwab wrote:

How to make sure a is deleted after b's deletion?
Since neither "a" nor "b" is allocated dynamically, I think you mean
"destructed," not "deleted."

I think the word is "destroyed" ;-)
The answer is that "b" will be destructed first unless you jump
through some pretty contorted hoops. Is there a particular situation
in which you find the default behavior unsuitable?

The OP actually wanted that behaviour.

[Rolf Magnus]

Jeff Schwab wrote:

How to make sure a is deleted after b's deletion?
Since neither "a" nor "b" is allocated dynamically, I think you mean
"destructed," not "deleted."

I think the word is "destroyed" ;-)
The answer is that "b" will be destructed first unless you jump
through some pretty contorted hoops. Is there a particular situation
in which you find the default behavior unsuitable?

The OP actually wanted that behaviour.

[Jeff Schwab]

Rolf Magnus wrote:

Jeff Schwab wrote:

How to make sure a is deleted after b's deletion?

Since neither "a" nor "b" is allocated dynamically, I think you mean
"destructed," not "deleted."

I think the word is "destroyed" ;-)

I think both terms are fine. "Destruct" is what an object does when its
"destructor" is called, the process being known as "destruction."

"destroy" happens to be the name of the method in the standard
allocators that causes the destruction of an object, so I prefer to say
an object whose destructor is invoked implicity by the run-time
environment is "destructed," rather than "destroyed."

The answer is that "b" will be destructed first unless you jump
through some pretty contorted hoops. Is there a particular situation
in which you find the default behavior unsuitable?

The OP actually wanted that behaviour.

Yes, I see (upon re-reading the OP) that you're right. What I said is
true, it's just not very useful. :)

[Jeff Schwab]

Rolf Magnus wrote:

Jeff Schwab wrote:

How to make sure a is deleted after b's deletion?

Since neither "a" nor "b" is allocated dynamically, I think you mean
"destructed," not "deleted."

I think the word is "destroyed" ;-)

I think both terms are fine. "Destruct" is what an object does when its
"destructor" is called, the process being known as "destruction."

"destroy" happens to be the name of the method in the standard
allocators that causes the destruction of an object, so I prefer to say
an object whose destructor is invoked implicity by the run-time
environment is "destructed," rather than "destroyed."

The answer is that "b" will be destructed first unless you jump
through some pretty contorted hoops. Is there a particular situation
in which you find the default behavior unsuitable?

The OP actually wanted that behaviour.

Yes, I see (upon re-reading the OP) that you're right. What I said is
true, it's just not very useful. :)

[ikl]

Neil Zanella <nz******@cs.mun.ca> wrote in message
news:Pi**************************************@garf ield.cs.mun.ca...

Since the clas A instance is specified prior to the class B instance it
will be guaranteed to be constructed before the class B instance. The
destructors are then guaranteed to be run in the reverse order. This
is regardless of any way constructors for such classes A and B may
be specified in initializer lists for class C.

Regards,

Neil

On Mon, 5 Apr 2004, ikl wrote:

Given three classes:

class A
{
};

class B
{
};

class C
{
A a;
B b;
};

int main() {
C c;
}

Is a for sure instantiated before b? If not, then is there any way to make sure that? How to make sure a is deleted after b's deletion?

Thanks!

Thanks to you all! This is not a question to me any more.

Is there any difference if a and b in any order on initializer lists for
class C?

Does an initializer list always go with a definition of a constructor not
declaration?

If there is a method in C that makes the class C like,
class C
{
A a;
B b;
public:
void method1(A& a1, B& b1);
};

When method1() is invoked, is it always safe to say that a and b have been
created already?

[ikl]

Neil Zanella <nz******@cs.mun.ca> wrote in message
news:Pi**************************************@garf ield.cs.mun.ca...

Since the clas A instance is specified prior to the class B instance it
will be guaranteed to be constructed before the class B instance. The
destructors are then guaranteed to be run in the reverse order. This
is regardless of any way constructors for such classes A and B may
be specified in initializer lists for class C.

Regards,

Neil

On Mon, 5 Apr 2004, ikl wrote:

Given three classes:

class A
{
};

class B
{
};

class C
{
A a;
B b;
};

int main() {
C c;
}

Is a for sure instantiated before b? If not, then is there any way to make sure that? How to make sure a is deleted after b's deletion?

Thanks!

Thanks to you all! This is not a question to me any more.

Is there any difference if a and b in any order on initializer lists for
class C?

Does an initializer list always go with a definition of a constructor not
declaration?

If there is a method in C that makes the class C like,
class C
{
A a;
B b;
public:
void method1(A& a1, B& b1);
};

When method1() is invoked, is it always safe to say that a and b have been
created already?

[Mike Wahler]

"ikl" <ik***@dsp.com> wrote in message
news:RH********************@bgtnsc05-news.ops.worldnet.att.net...

Neil Zanella <nz******@cs.mun.ca> wrote in message
news:Pi**************************************@garf ield.cs.mun.ca...

Since the clas A instance is specified prior to the class B instance it
will be guaranteed to be constructed before the class B instance. The
destructors are then guaranteed to be run in the reverse order. This
is regardless of any way constructors for such classes A and B may
be specified in initializer lists for class C.

Regards,

Neil

On Mon, 5 Apr 2004, ikl wrote:

Given three classes:

class A
{
};

class B
{
};

class C
{
A a;
B b;
};
int main() {
C c;
}

Is a for sure instantiated before b? If not, then is there any way to make sure that? How to make sure a is deleted after b's deletion?

Thanks!

Thanks to you all! This is not a question to me any more.

Is there any difference if a and b in any order on initializer lists for
class C?

The order of initialization is that of the
order of the member definitions. The expressions
in the initializer list can be in any order, and
do not affect initialization order.

Does an initializer list always go with a definition of a constructor not
declaration?
Correct.

If there is a method in C that makes the class C like,
class C
{
A a;
B b;
public:
void method1(A& a1, B& b1);
};

When method1() is invoked, is it always safe to say that a and b have been
created already?

Yes. Once a constructor has run (whether it's user-defined
or not), the object exists, and member functions can be
invoked against it.

-Mike

[Mike Wahler]

"ikl" <ik***@dsp.com> wrote in message
news:RH********************@bgtnsc05-news.ops.worldnet.att.net...

Neil Zanella <nz******@cs.mun.ca> wrote in message
news:Pi**************************************@garf ield.cs.mun.ca...

Since the clas A instance is specified prior to the class B instance it
will be guaranteed to be constructed before the class B instance. The
destructors are then guaranteed to be run in the reverse order. This
is regardless of any way constructors for such classes A and B may
be specified in initializer lists for class C.

Regards,

Neil

On Mon, 5 Apr 2004, ikl wrote:

Given three classes:

class A
{
};

class B
{
};

class C
{
A a;
B b;
};
int main() {
C c;
}

Is a for sure instantiated before b? If not, then is there any way to make sure that? How to make sure a is deleted after b's deletion?

Thanks!

Thanks to you all! This is not a question to me any more.

Is there any difference if a and b in any order on initializer lists for
class C?

The order of initialization is that of the
order of the member definitions. The expressions
in the initializer list can be in any order, and
do not affect initialization order.

Does an initializer list always go with a definition of a constructor not
declaration?
Correct.

If there is a method in C that makes the class C like,
class C
{
A a;
B b;
public:
void method1(A& a1, B& b1);
};

When method1() is invoked, is it always safe to say that a and b have been
created already?

Yes. Once a constructor has run (whether it's user-defined
or not), the object exists, and member functions can be
invoked against it.

-Mike

[Ben Measures]

Jeff Schwab wrote:

Rolf Magnus wrote:

Jeff Schwab wrote:

How to make sure a is deleted after b's deletion?
Since neither "a" nor "b" is allocated dynamically, I think you mean
"destructed," not "deleted."

I think the word is "destroyed" ;-)

I think both terms are fine. "Destruct" is what an object does when its
"destructor" is called, the process being known as "destruction."

I don't think Rolf was correcting your terms, just your
grammar/spelling: "destructed" is not in the English dictionary.

Destruct - to Destroy. "It has been destroyed - I see only destruction."

--
Ben Measures
Software programming, Internet design/programming, Gaming freak.

http://ben.measures.org.uk - when I find time

[Ben Measures]

Jeff Schwab wrote:

Rolf Magnus wrote:

Jeff Schwab wrote:

How to make sure a is deleted after b's deletion?
Since neither "a" nor "b" is allocated dynamically, I think you mean
"destructed," not "deleted."

I think the word is "destroyed" ;-)

I think both terms are fine. "Destruct" is what an object does when its
"destructor" is called, the process being known as "destruction."

I don't think Rolf was correcting your terms, just your
grammar/spelling: "destructed" is not in the English dictionary.

Destruct - to Destroy. "It has been destroyed - I see only destruction."

--
Ben Measures
Software programming, Internet design/programming, Gaming freak.

http://ben.measures.org.uk - when I find time