'x = this' in constructor

[Alex Vinokur]

Is this safe?

-----------------
struct Foo;

struct Bar
{
Foo* f;
};

struct Foo
{
Bar b;
Foo()
{
// Stuff
b.f = this; // Is that safe?
// Stuff
}
};


Thanks.

 

[roberts.noah]

Is this safe?

-----------------
struct Foo;

struct Bar
{
Foo* f;
};

struct Foo
{
Bar b;
Foo()
{
// Stuff
b.f = this; // Is that safe?
// Stuff
}
};

So long as Bar.f is a pointer I think you are ok. It's a cyclic
dependency though and best avoided if possible...sometimes it isn't.

http://c2.com/cgi/wiki?AcyclicDependenciesPrinciple

 

[TuxC0d3]

It depends on how you use it.. But i don't see anything wrong with
this. Just be careful that you don't destroy things more than once,
which might lead to undefined behaviour..

For instance, this would not be wise:
Foo* FooObj = new Foo;
//... use FooObj
delete FooObj->b.f; // Becouse f points to the same object that FooObj
points to, that object gets destroyed here..
//... The object that FooObj points to is no longer in existance here,
so..
FooObj->b.f = FooObj;
// That might look like restoring the address of the object that FooObj
*WAS* pointing to in b.f..
// But in fact, it is an error situation, becouse the object that
FooObj was pointing to, doesn't
// exist anymore and on most implementations (if not all), this would
couse undefined behaviour or couse an error.
delete FooObj; // This also is an error, becouse you're trying to
destroy an object that was already down the drain..

 

[Kaz Kylheku]

http://c2.com/cgi/wiki?AcyclicDependenciesPrinciple

So what? That page is just someone's ill-informed, inexperienced
opinion.

Just because someone dropped something into a Wiki doesn't mean it has
become gospel.

 

[Pete Becker]

So what? That page is just someone's ill-informed, inexperienced
opinion.

Just because someone dropped something into a Wiki doesn't mean it has
become gospel.

But this one is a "Principle"! It SAYS so! And it's based on what
someone else wrote, and even includes a link! So it must be true!

 

[roberts.noah]

But this one is a "Principle"! It SAYS so! And it's based on what
someone else wrote, and even includes a link! So it must be true!

Joke around all you want guys but these things are well worth knowing
or at least familiarizing yourself with. As anyone who has actually
read these articles and principles knows, it is stated in several
places that some of these principles are actually contradictory.
Everything needs balance.

Cyclic dependencies can become a major hassle. The principle I cited
above applies to packages mainly but the reasoning in it can be applied
to classes also to a lesser degree.

 

[Pete Becker]

Cyclic dependencies can become a major hassle. The principle I cited
above applies to packages mainly but the reasoning in it can be applied
to classes also to a lesser degree.

Since packages aren't part of C++, it's rather difficult to assess that
statement. And since the link goes to a page with a rather rambling
discussion that's mostly lacking in actual analysis, it's not
particularly helpful.

There's nothing wrong with cyclic dependencies among classes when that's
what the problem domain requires.

 

[roberts.noah]

Since packages aren't part of C++, it's rather difficult to assess that
statement. And since the link goes to a page with a rather rambling
discussion that's mostly lacking in actual analysis, it's not
particularly helpful.

Obviously you guys just want to get into a flame war.

Packages are not defined by the standard but in practical terms they
are definately part of the C++ programmer experience.

Most people understand that cyclic dependencies are best avoided (yes,
in classes too) if practical so I'll just leave it at that now.