I write a simple class, I just wanna know where I should delete my pointer.
#include<iostream>
class test
{
private:
int* sum{new int};
public:
int addFunc(int num1 = 5, int num2 = 2)
{
*sum = num1 + num2;
return *sum;
}
void print()
{
std::cout << *sum << std::endl;
}
};
int main()
{
test obj;
obj.addFunc();
obj.print();
}
I know how to use unique pointers to get rid of deleting pointers, should I delete my pointer after
returning it or somewhere else.
You delete it in the destructor. But if you're managing raw memory you'll also have to implement a suitable copy constructor & copy assignment operator and their move counterparts.
In 99%+ of these cases you'll just want to use automatic lifetime or smart pointers instead.
Short answer: never, meaning at program end.
The problem is that your class is copyable. If you delete the pointer in destructor (which would be the correct place for something allocated at construction time), you will get a dangling pointer in the following use case:
you pass a reference to a test object to a function
inside that function you copy the object to a local object: the pointer will be copied so both the original object and the local copy will point the the same int
at the end the the function, the local object will be destroyed. If if deletes the int, the original will get a dangling pointer.
Long story made short: as soon as you use allocation at construction time, you should care for the copy/move construction and assignment, and destruction.
Related
What i think is occuring is that the rvalue A returned by SetVar is an identical copy to Class and shares the same pointer Var. but when the rvalue calls its deconstructor it deletes Class's Val.
class A
{
private:
int* Var;
public:
A SetVar(int);
~A()
{
delete Var;
}
};
A A::SetVar(int NewVar)
{
Var=new int;
*Var=NewVar;
//POINT A
return *this;
}
int main()
{
A Class;
Class.SetVar(8);
//POINT B
}
At POINT A *Val equals 8, but at POINT B *Val equals -17891602. I also Get _BLOCK_TYPE_IS_VALID(pHead->nHeadUse) due to trying to delete Val twice.
deleting the deconstructor solves the issue but creates a memory leak.
You have violated The Rule of Three
So, you make a copy of the object when you do
return *this
which gets destructed as well, and delete is called twice on the same pointer. You really shouldn't be doing this anyway. You should return a reference, but why should a setter function return a reference to the object it was called on anyway? Isd it to chain function calls?
Additionally, you are leaking Var every time you reassign it.
There are a few problems here.
First, the most direct cause of you problem is that a copy of the this object is made when SetVar() returns. (You probably want to return a reference to an A instead.) Since there is no copy constructor defined for class A, the values of all of the fields are implicitly copied. This means that the copy will have a pointer to the same Var int that you allocated in SetVar. In other words, you will have two pointers to the same memory, one in the original A variable (the one you call "Class") and one in the copy that is returned by SetVar(). When the second of these is destroyed, its destructor will be deleting the memory at an already-deleted pointer.
Given the code :
class Sample
{
public:
int *ptr;
Sample(int i)
{
ptr = new int(i);
}
~Sample()
{
delete ptr;
}
void PrintVal()
{
cout << "The value is " << *ptr;
}
};
void SomeFunc(Sample x)
{
cout << "Say i am in someFunc " << endl;
}
int main()
{
Sample s1= 10;
SomeFunc(s1);
s1.PrintVal();
}
The output is :
Say i am in someFunc
Null pointer assignment(Run-time error)
I'm not able to understand why the second line of output comes. The second line of the output. I think that the compiler supplies a copy constructor when it is not explicitly specified. So, in the function SomeFunc(Sample x), the local object to SomeFunc() which is X of Sample type should be created and destroyed and the Sample type object (s1) in main() should remain intact and should be freed only after main exits. Please answer why the above behaviour is happening?
Why the above behaviour is happening??
Short Answer:
Because You are not following the Rule of Three.
Long Answer:
Your class has a pointer member ptr with dynamic memory allocation in constructor and deallocation in destructor while your code creates temporary copies of the object while passing to the function SomeFunc() by calling copy constructor, implicitly generated by the compiler, which creates a shallow copy of the pointer member. Once the temporary is destroyed at the end of function call the memory is deallocated in destructor and you are left with a dangling pointer.This invalid pointer is dereferenced further when you call the function PrintVal() resulting in a Undefined Behavior, which manifests in the form of a segmentation fault.
How to avoid this problem?
Short Answer:
Follow the Rule of Three.
Long Answer:
You should provide a copy constructor which creates a deep copy of the pointer member ptr. This ensures that the pointer member of the object created in member remains valid through out the lifetime of the program.
EDIT:
Actually, the problem might even occur even before the function gets called, specifically when you call:
Sample s1= 10;
This calls the conversion constructor,
Sample(int i)
to create a temporary Sample object which is then used for constructing s1 object by calling the implicit copy constructor, If this is the case the temporary object created will be destroyed after creation of s1 does leaving the pointer member ptr in a dangling state.
However, most of the compilers will apply optimizations through copy elision using Return Value Optimization(RVO) thus eliminating the need of calling the copy constructor & hence this might not be a problem.
In either case solution to the problem remains the same.
here is my c++ code :
class Sample
{
public:
int *ptr;
Sample(int i)
{
ptr = new int(i);
}
~Sample()
{
delete ptr;
}
void PrintVal()
{
cout << "The value is " << *ptr;
}
};
void SomeFunc(Sample x)
{
cout << "Say i am in someFunc " << endl;
}
int main()
{
Sample s1= 10;
SomeFunc(s1);
s1.PrintVal();
}
it returns me the output like :
Say i am in someFunc
Null pointer assignment(Run-time error)
here As the object is passed by value to SomeFunc the destructor of the object is called when the control returns from the function
should i right ? if yes then why it is happening ? and whats the solution for this ???
Sample is passed by value to SomeFunc, which means a copy is made. The copy has the same ptr, so when that copy is destroyed when SomeFunc returns, ptr is deleted for both objects. Then when you call PrintVal() in main you dereference this invalid pointer. This is undefined behavior. Even if that works then when s1 is destroyed ptr is deleted again, which is also UB.
Also, if the compiler fails to elide the copy in Sample s1= 10; then s1 won't even be valid to begin with, because when the temporary is destroyed the pointer will be deleted. Most compilers do avoid this copy though.
You need to either implement copying correctly or disallow copying. The default copy-ctor is not correct for this type. I would recommend either making this type a value type (which holds its members directly rather than by pointer) so that the default copy-ctor works, or use a smart pointer to hold the reference so that it can manage the by-reference resources for you and the default copy-ctor will still work.
One of the things I really like about C++ is that it's really friendly toward using value types everywhere, and if you need a reference type you can just wrap any value type up in a smart pointer. I think this is much nicer than other languages that have primitive types with value semantics but then user defined types have reference semantics by default.
You usually need to obey the Rule of Three since you have an pointer member.
In your code example to avoid the Undefined Behavior you are seeing:
Replace the need to in first statement by must.
Since SomeFunc() takes its argument by value, the Sample object that you pass to it is copied. When SomeFunc() returns, the temporary copy is destroyed.
Since Sample has no copy constructor defined, its compiler-generated copy constructor simply copies the pointer value, so both Sample instances point to the same int. When one Sample (the temporary copy) is destroyed, that int is deleted, and then when the second Sample (the original) is destroyed, it tries to delete the same int again. That's why your program crashes.
You can change SomeFunc() to take a reference instead, avoiding the temporary copy:
void someFunc(Sample const &x)
and/or you can define a copy constructor for Sample which allocates a new int rather than just copying the pointer to the existing one.
When you pass the argument for the function it's called the copy constructor, but you don't have one so the pointer is not initialised. When it exits the function, the object is calls the destructor to delete the unitialised pointer, so it thows an error.
Instead of
int main()
{
Sample s1= 10;
SomeFunc(s1);
s1.PrintVal();
}
try to use
int main()
{
Sample* s1= new Sample(10);
SomeFunc(*s1);
s1->PrintVal();
}
#include <iostream>
#include <memory>
class test
{
private:
int x , y;
public:
test(int a , int b):x(a),y(b){}
void fun()
{
std::cout<< x<<" "<<y<<" "<<std::endl;
}
};
void show(std::auto_ptr<test> t1)
{
t1->fun();
}
int main()
{
show(new test(3,4));
}
I am getting a compilation error , please tell me what's wrong in this code?Thanks in advance.
Whenever you dynamically allocate an object, you should create a named smart pointer that immediately takes ownership of the object, then use that named smart pointer. For example,
std::auto_ptr<test> ptr(new test(3, 4));
show(ptr);
You cannot pass new test(3, 4) directly to the function because std::auto_ptr objects must be explicitly constructed; it would be quite unexpected if a smart pointer took ownership of an object implicitly.
That said, this is rather unusual anyway because when you call show(), the auto_ptr is copied and when auto_ptr is "copied," the original loses ownership and the copy gains ownership (so, after show() is called, you will find that ptr no longer has ownership of the object.
James explained how to resolve the problem.
But the reason auto_ptr was designed so that you can not do this:
show(new test(3,4));
Is because this is a bad idea.
Even this (if it were allowed):
show(std::auto_ptr<test>(new test(3,4)));
Would be a bad idea.
So you ask why.
Well in the normal situation not a big deal.
Bu what happens when you have a function that takes more than one parameter.
show2(std::auto_ptr<test>(new test(3,4)), SomeObject());
Now the standard gurantees that all parameters will be fully evaluated before the call (even the construction of the auto_ptr). But it does not guarantee the evaluation order nor that the evaluation will not be interleaved.
Thus it is possible for this evaluation:
// Phsedu code for parameter evaluation
test* tmp1 = new test(3,4);
SomeObject const& tmp2 = SomeObject();
std::auto_ptr<test> const& tmp3(tmp1);
call(tmp3, tmp1)
This order is bad. Because if the constructor of SomeObject throws an exception you will leak tmp1 as it has not yet been assigned to the std::auto_ptr.
This is why we auto_ptr was designed so that you have to give it a named variable.
std::auto_ptr<test> tmp3(new test(3,4));
SomeObject tmp1;
call(tmp3, tmp1)
Now if SomObject constructor throws the test object will be tidied up.
I have two methods to create an instance for a pointer.
But one of them will fail.
class A {
public:
int num;
};
void testPointer1(A* a){
a = new A();
a->num = 10;
}
A* testPointer2(){
A* a = new A();
a->num = 10;
return a;
}
void testPointer() {
A* a1 = NULL;
testPointer1(a1); // this one fails
//cout << a1->num << endl; // segmentation fault
A* a2 = NULL;
a2 = testPointer2();
cout << a2->num << endl;
}
why is testPointer1 wrong?
The syntax is valid, but it doesn't do what you want because testPointer1() is operating on a copy of the pointer, not the actual pointer itself. So when you assign the address to the newly allocated object, it gets assigned to the copy, not to the original a1 pointer.
Because of this, the address is lost and you get a memory leak. Also, since the original a1 pointer was never modified in the first place, you attempted to dereference a null pointer, which is a bad thing.
I'd say testPointer2() is the better way to do it, but if you want testPointer1() to work, try this:
void testPointer1(A*& a)
{
a = new A();
a->num = 10;
}
The parameter type indicates "a reference to a pointer to A." That way, instead of a copy of the pointer being passed, a reference to the original pointer will be passed. A C++ reference is an alias to another object. So whatever you do on the alias, it gets performed on the original object.
Extra notes:
Note that the parentheses in new A(); are actually significant and their presence or absence makes a difference.
Also note that you must manually delete all new'ed objects after you're done with them, or you will get a leak. Typically you would wrap the pointer in its own class and implement RAII or use a smart pointer such as Boost's smart pointers or auto_ptr, for proper memory management and exception safety.
If you're going to set the value of num on initialization, why not create a constructor?
class A
{
public:
A(int n) : num(n) {}
int GetNum() const { return num; }
private:
int num;
};
void testPointer1(A*& a)
{
a = new A(10);
}
A* testPointer2()
{
return new A(10);
}
// auto_ptr example, see link in second note above
std::auto_ptr<A> testPointer3()
{
return auto_ptr<A>(new A(10));
}
The testPointer1 functions works on a copy of the provided pointer : modifications to a in testPointer1 are not reflected to the caller.
It's exactly like in this simpler example :
void testInt1(int i)
{
i++;
}
void testInt()
{
int i = 0;
testInt1(i);
// i is still 0
}
If you want the change in testInt1 to be reflected to the caller, you have to pass either a pointer or reference to i (and not just the value of i). The same solution can be applied to your specific case, though one could argue that pointers to pointer and references to pointer are not really a best practice.
Is this homework ?
This seems to be obvious:
formal parameters are saved on the stack & restored after method/function call.
then whatever f(type x), manipulating x inside the function/method won't change it's value outside of the function.
even if type is a pointer type.
the only way to make x change inside a function is to tell it is modifiable through references or pointer to type.
in your case :
A* a1 =NULL
call to your method won't change value of a1 outside of testPointer1
so a1 will still be NULL after the call.