c++ reference Question
Author
Hello!
I whant to know something about references in c++:
Suppose this function:
CVeryBigClass& f() { return m_TheClass; }
And those two calls:
1.
CVeryBigClass A = f();
2.
CVeryBigClass& B = f();
i whant to know if allocation on the heap of an instance of CVeryBigClass is only done in the first case and not in the second ....
Thanks a lot !
Clément Vidal
To be exact, the first version will create the new object A on the stack (as local variable), not on the heap.
Quote:Original post by ClementLuminy
i whant to know if allocation on the heap of an instance of CVeryBigClass is only done in the first case and not in the second ....
Neither, if by "the heap" you mean dynamic storage. In your example, you create an object of automatic storage duration using the copy constructor. In other words, it's created "on the stack." The second, of course, is as rip-off said.
The thing to remember about number 2, though, is that it could lead to undefined behavior if the signature of f looks like the following:
CVeryBigClass f();
It will also lead to undefined behavior if the function looks like this:
CVeryBigClass& f()
{
CVeryBigClass object;
// Do something here
return object;
}
Becuase object disappears when f finishes, resulting in a dangling reference.
CVeryBigClass f();
It will also lead to undefined behavior if the function looks like this:
CVeryBigClass& f()
{
CVeryBigClass object;
// Do something here
return object;
}
Becuase object disappears when f finishes, resulting in a dangling reference.
Quote:Original post by Troll
The thing to remember about number 2, though, is that it could lead to undefined behavior if the signature of f looks like the following:
CVeryBigClass f();
It will also lead to undefined behavior if the function looks like this:
CVeryBigClass& f()
{
CVeryBigClass object;
// Do something here
return object;
}
Becuase object disappears when f finishes, resulting in a dangling reference.
i know this is an assumption, but the OP's source returned m_SomeVariable, where the m usually means member, which would outlive the function unless called on a temporary...
Quote:Original post by rip-offQuote:Original post by Troll
The thing to remember about number 2, though, is that it could lead to undefined behavior if the signature of f looks like the following:
CVeryBigClass f();
It will also lead to undefined behavior if the function looks like this:
CVeryBigClass& f()
{
CVeryBigClass object;
// Do something here
return object;
}
Becuase object disappears when f finishes, resulting in a dangling reference.
i know this is an assumption, but the OP's source returned m_SomeVariable, where the m usually means member, which would outlive the function unless called on a temporary...
totally true, which raises the next logical lifetime detail worth mentioning... the second version reference is valid only as long as the member returned is valid ... so if the object goes out of scope / is deleted ... then the reference is bad.
The first version (as stated) doesn't use heap memory, but stack memory, and invokes the copy-constructor (if there is one - or an automatic complier created one) -Its lifetime is not tied to the object on which you call f().
Author
You're right , it's not the heap but the Stack ( i made a mistake !!)
Thanks you all for your help !!
Cordialy: Clément Vidal
Thanks you all for your help !!
Cordialy: Clément Vidal
Quote:Original post by rip-offQuote:Original post by Troll
The thing to remember about number 2, though, is that it could lead to undefined behavior if the signature of f looks like the following:
CVeryBigClass f();
It will also lead to undefined behavior if the function looks like this:
CVeryBigClass& f()
{
CVeryBigClass object;
// Do something here
return object;
}
Becuase object disappears when f finishes, resulting in a dangling reference.
i know this is an assumption, but the OP's source returned m_SomeVariable, where the m usually means member, which would outlive the function unless called on a temporary...
It's not just an assumption, it's an extremely logical one to make:
1) m_ prefix.
2) f() is shown only to return this variable, not declare it in it's local scope.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
