Suppose I have a C++ class with an attribute that is a reference:
class ClassB {
ClassA &ref;
public:
ClassB(ClassA &_ref);
}
Of course, the constructor is defined this way:
ClassB::ClassB(ClassA &_ref) : ref(_ref) { /* ... */ }
My question is: When an instance of class 'ClassB' is destroyed, is the object referenced by 'ClassB::ref' also destroyed?
A reference is nothing but an alias for a variable, the alias gets destructed, not the actual variable. You could consider it some kind of pointer, but there are reasons to refrain from this kind of (evil) thoughts :).
No. Reference members do not affect the lifetime of whatever they point to. This means the thing they alias may have a longer or a shorter lifetime than that of the reference.
In your case it does not.
No. That's why you need a ~ClassB destructor if ClassB is responsible for the storage of ref which it might not be.
When an object is eliminated in C++, its memory is deallocated and thus everything that was embedded in it (such as member variables) is lost as well.
In the case of a pointer, the pointer is a member variable that contains an address, so the address is "destroyed" but the referenced object, if any, is not.
In the case of a reference member, the address is destroyed, but the target is not affected.
A class may define a destructor that could define special behaviors. One common such behavior is to invoke cleanup operations on members (if any), and to deallocate memory that was dynamically allocated earlier. Here, however, you already got an object so you should not be the one deallocating it.
No; references are merely an alternate syntax for pointers. The value they reference won't be modified if the reference is deallocated.
* or -> operators. A reference is an address in memory, dereferenced by the . operator. If you don't understand how pointers and references are fundamentally identical, you've got no business working in C++. –
Rosenberry const int& i = Function(); const int* p = &Function(); If Function() yields a temporary, how do those two lines differ in functionality, and how is this possible if references are identical to pointers? –
Enabling const int* p = &Function();, it's wrong. –
Rosenberry int a = 4; int &b = a;. b is not a pointer. It's not syntactic sugar over a pointer. It's another name for the same object which a is a name for. If the compiler implements it by taking a pointer to a then OK, that's how it implements it, but there's no particular reason in this example to think it should implement it that way, other than because in your head (not in the language spec, and quite possibly not in your compiler-writer's head), you have failed to form a conceptual model of references distinct from your conceptual model of pointers. –
Enceinte b even exists in the resultant binary, something is horribly wrong. –
Enabling Foo f() { return Foo(); }, then const Foo &a = f(); const Foo *b = &f(); ... some more code. Contrary to your earlier assertion that code using references is exactly the same as code using pointers, the temporary "struct with a bit etc" which is the return value of f() in each case is destructed at different times. References are not pointers (although as you incisively point out, they are implemented using them), and they don't (always) behave like pointers either. –
Enceinte b or for a pointer to a. At -O0, a pointer is taken for either one. At -O1, both are omitted (assuming you don't later take the address of the pointer, of course). But you don't need to know if they're the same or not to understand the concepts. If John insists that C++ (or for that matter, any compiled language) fundamentally "is" not an abstraction, but two things "are the same" if his compiler outputs the same code, then a reference and a pointer to a in this case are the same. But he's filibustering. –
Enceinte sizeof(char&) is 1 and not sizeof(char*). Also, a type like char& Class::* does not exist (member pointer to references don't exist). The language has a clear separation of these concepts. –
Dextral int. –
Enceinte const Foo a = f();, where a is (sort of) defined to be a copy of the temporary return value of f(). "Sort of" because copy elision is permitted there too, so a may or may not actually be a copy, since the temporary may or may not be created in the first place. But the upper limit on the number of copies is one greater than if the function were called without using the return value. With the const reference, the upper limit doesn't go up. I confess I've strayed off the original question, though, which was about a member reference, and those references can't do this trick. –
Enceinte NullPointerException, and gave the game away ;-) –
Enceinte If you want it to be destroyed, you will have to encapsulate it (normally done via "smart" pointers, like std::shared_ptr or std::unique_ptr), that will automatically release the memory in an appropriate fashion on destruction of B. In-language references have no memory freeing behaviour associated with them, except the actual memory of the reference itself, as opposed to the referred.
You will have to build and understand your own memory model. People typically use shared_ptr and reference counting for basic uses.
I don't have the C++ spec on hand, but my guess is "No".
Pointers aren't deleted automatically when an object is destroyed, I see no reason that a reference should be different. Plus, having the reference automatically destroyed would be ripe for interesting bugs.
© 2022 - 2024 — McMap. All rights reserved.