Re: Values vs. references for deep, nested structures.
On Aug 4, 11:47 pm, Alexander Dong Back Kim <alexdb...@gmail.com>
wrote:
Hi AJG,
First of all, I don't think I'm the right person who can answer your
questions although I wish if I could. I would rather ask you one thing
that confuses me.
I know you already mentioned that inheritance or the using an
incompleted data type are not the main point in this post but I'm just
curious about this so please forgive me about this question.
Oh, no worries :)
struct Node : std::vector<Node> {
...
};
Doesn't the structure raise some sort of recursive issue during the
compile time? I means Node is "a vector of Node" so when the compiler
instantiates a concrete type for vector<Node>. it will start
evaluating about the type Node which hasn't been completed the
definition yet... I just naively guess that this might cause the Node
class would have unnecessary inheritances...
Well, to start with, I'm not certain of the legality of that
construct. I *think* it will technically lead to undefined behavior.
Having said that, I think compilers are smart enough to "special case"
that kind of simple recursion and deal with it appropriately. So I
don't worry too much about it. I don't know whether this type of thing
only "works" with standard containers, or with user-created classes as
well; some testing would be in order to find out.
I've never seen that kind of attempt and I actually really like it =)
Node a, b, c;
b.push_back(c);
a.push_back(b);
The codes above are really beautiful!
Yep. Value semantics are great, aren't they? :) You could make it even
prettier with operator overloading.
Since you started using boost::shared_ptr...
b->push_back(c);
a->push_back(b);
After the two lines of codes you provided, have you tried to add "c->push_back(a);" at the end?
Well, those examples were concocted on the fly, so I didn't really try
them. I suspect that if you were to append your suggested statement to
it, you will generate a circular reference (a "cycle") that will cause
shared_ptr to leak memory due to reference counts that never reach 0.
The way to solve this in the general case is to either a) manually
remove circular references at destruction time to break the cycle or
b) use something like weak_ptr to prevent the cycles from being
created in the first place.
It is extremely interesting codes =) but sorry that I couldn't answer
to your questions.
Sure, no prob :)
Thanks,
Al.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]