Saving temporary objects

[MathStuf]

I am building a class which is like a tree of sorts. Each node can
hold numerous subnodes of itself. I have some constructors such as:

Node(string name, int value);
Node(string name, string value);

I would also like the following AddNode methods:

AddNode(Node &node);
AddNode(string name, int value);
AddNode(string name, string value);

The AddNode where another node is passed works fine. However, the ones
where new values are passed doesn't when set up as such:

AddNode(string name, int value)
{
Node add(name, value);
elements.push_back(add);
return &elements[elements.size() - 1];
}

I know it's because the instance of the new Node is temporary, but is
there a way to keep it around for future use?

--MathStuf

[sonison.james]

On Apr 10, 9:07 am, "MathStuf" <[e-mail]:

I am building a class which is like a tree of sorts. Each node can
hold numerous subnodes of itself. I have some constructors such as:

Node(string name, int value);
Node(string name, string value);

I would also like the following AddNode methods:

AddNode(Node &node);
AddNode(string name, int value);
AddNode(string name, string value);

The AddNode where another node is passed works fine. However, the ones
where new values are passed doesn't when set up as such:

AddNode(string name, int value)
{
Node add(name, value);
elements.push_back(add);
return &elements[elements.size() - 1];

}

I know it's because the instance of the new Node is temporary, but is
there a way to keep it around for future use?

--MathStuf

Hi,

Could you please elaborate the error that you get and the code snippet
for the method that works for you. If my guess is correct, "elements"
seems to be a vector of "Nodes". If that is the case, push backs on
the vector will invalidate the address that you are returning when the
vector gets resized.
Regards
SJ

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

On 10 Apr, 06:07, "MathStuf" <[e-mail]:

I am building a class which is like a tree of sorts. Each node can
hold numerous subnodes of itself. I have some constructors such as:

Node(string name, int value);
Node(string name, string value);

I would also like the following AddNode methods:

AddNode(Node &node);
AddNode(string name, int value);
AddNode(string name, string value);

The AddNode where another node is passed works fine. However, the ones
where new values are passed doesn't when set up as such:

AddNode(string name, int value)
{
Node add(name, value);
elements.push_back(add);
return &elements[elements.size() - 1];

}

I know it's because the instance of the new Node is temporary, but is
there a way to keep it around for future use?

As SJ pointed out, if elements is a container then it will contain a
copy of the object you push back, not the object itself, so the fact
that it's temporary is irrelevant. And instead of using
elements[elements.size() - 1] you can use elements.back().

--
Erik Wikström

[MathStuf]

On Apr 10, 2:47 am, "Erik Wikström" <[e-mail]>
wrote:

On 10 Apr, 06:07, "MathStuf" <[e-mail]:

I am building a class which is like a tree of sorts. Each node can
hold numerous subnodes of itself. I have some constructors such as:

Node(string name, int value);
Node(string name, string value);

I would also like the following AddNode methods:

AddNode(Node &node);
AddNode(string name, int value);
AddNode(string name, string value);

The AddNode where another node is passed works fine. However, the ones
where new values are passed doesn't when set up as such:

AddNode(string name, int value)
{
Node add(name, value);
elements.push_back(add);
return &elements[elements.size() - 1];

}

I know it's because the instance of the new Node is temporary, but is
there a way to keep it around for future use?

As SJ pointed out, if elements is a container then it will contain a
copy of the object you push back, not the object itself, so the fact
that it's temporary is irrelevant. And instead of using
elements[elements.size() - 1] you can use elements.back().

--
Erik Wikström- Hide quoted text -

- Show quoted text -

Thanks for the input. The returned pointer is more for use for
continual nesting so that its easy to add continually nested elements.
I've decided to cut it down to just AddNode(Node&) because as far as
I'm aware of, if you call AddNode(Node(name, value)), it doesn't
matter because the compiler will optimize it so that its constructed
right in the method. Also, is there a way to force
node.AddNode(Node(name, value)) to go to that definition and not have
to rewrite an AddNode(Node) method?

--MathStuf

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

On 10 Apr, 14:29, "MathStuf" <[e-mail]:

On Apr 10, 2:47 am, "Erik Wikström" <[e-mail]>
wrote:

On 10 Apr, 06:07, "MathStuf" <[e-mail]:

I am building a class which is like a tree of sorts. Each node can
hold numerous subnodes of itself. I have some constructors such as:

Node(string name, int value);
Node(string name, string value);

I would also like the following AddNode methods:

AddNode(Node &node);
AddNode(string name, int value);
AddNode(string name, string value);

The AddNode where another node is passed works fine. However, the ones
where new values are passed doesn't when set up as such:

AddNode(string name, int value)
{
Node add(name, value);
elements.push_back(add);
return &elements[elements.size() - 1];

}

I know it's because the instance of the new Node is temporary, but is
there a way to keep it around for future use?

As SJ pointed out, if elements is a container then it will contain a
copy of the object you push back, not the object itself, so the fact
that it's temporary is irrelevant. And instead of using
elements[elements.size() - 1] you can use elements.back().

--
Erik Wikström- Hide quoted text -

- Show quoted text -

Thanks for the input. The returned pointer is more for use for
continual nesting so that its easy to add continually nested elements.
I've decided to cut it down to just AddNode(Node&) because as far as
I'm aware of, if you call AddNode(Node(name, value)), it doesn't
matter because the compiler will optimize it so that its constructed
right in the method. Also, is there a way to force
node.AddNode(Node(name, value)) to go to that definition and not have
to rewrite an AddNode(Node) method?

Make it AddNode(const Node&).

--
Erik Wikström