This question already has answers here:
boost::any replacement for the code below
(2 answers)
Closed 8 years ago.
I don't have access to the Boost library and am trying to implement something similar to Boost any (a container that can store multiple types). I found an example at http://learningcppisfun.blogspot.co.uk/2007/09/boostany.html, however when I compile it I get a segmentation fault. Debugging it seems to suggest that it's Variant's destructor causing an issue. When I comment the destructor out it works fine -- although it's leaking memory. Can anyone explain what's happening? Thanks!
#include <iostream>
#include <vector>
using namespace std;
class BaseHolder
{
public:
virtual ~BaseHolder(){}
};
template<typename T>
class HoldData : public BaseHolder
{
public:
HoldData(const T& t_) : t(t_){}
T t;
};
class Variant
{
public:
template<typename T>
Variant(const T& t) : data(new HoldData<T>(t)){}
~Variant(){delete data;}
BaseHolder* data;
};
int main(){
vector<Variant> a;
int x = 10;
double y = 3.15;
a.push_back(x);
a.push_back(y);
cout << dynamic_cast<HoldData<int> *>(a[0].data)->t << endl;
cout << dynamic_cast<HoldData<double> *>(a[1].data)->t << endl;
return 0;
}
Output:
10
3.5
You have a basic violation of the rule of three.
You allocate in the default constructor, and de-allocate in the destructor. Now, what about your copy constructor and assignment operator? What about when two Variant objects point to the same data, and then they both go out of scope?
Since vectors maintain internal integrity by copying elements around and, in fact hold copies in the first place, it should be clear that this is a serious factor.
What I think is happening is this
You push int 10 onto the vector a
This triggers Constructor call for a temp Variant lets call this var1.
Constructor calls new HoldData (10)
Now vector a calls the Variant's copy constructor (which is automatically supplied by compiler) to create a Variant var2 in the vector. The default copy constructor is just a bitwise copy so var1 and var2 both have a data pointer pointing to same place.
var1 now goes out of scope and its destructor is called deleting its data pointer.
var2 in the vector now has a pointer to invalid memory. When vector a goes out of scope var2 will call its destructor and try to delete the memory a second time hence the crash.
You need to provide your own copy constructor in Variant that will safely copy the HoldData pointer.
Related
I'm trying to store structs in a vector. Struct needs to dynamically allocate memory for char* of a given size.
But as soon as I add the struct to a vector, its destructor gets called, as if I lost the pointer to it.
I've made this little demo for the sake of example.
#include "stdafx.h"
#include <iostream>
#include <vector>
struct Classroom
{
char* chairs;
Classroom() {} // default constructor
Classroom(size_t size)
{
std::cout << "Creating " << size << " chairs in a classroom" << std::endl;
chairs = new char[size];
}
~Classroom()
{
std::cout << "Destroyng chairs in a classroom" << std::endl;
delete[] chairs;
}
};
std::vector<Classroom> m_classrooms;
int main()
{
m_classrooms.push_back(Classroom(29));
//m_classrooms.push_back(Classroom(30));
//m_classrooms.push_back(Classroom(30));
system("Pause");
return 0;
}
The output is
Creating 29 chairs in a classroom
Destroyng chairs in a classroom
Press any key to continue . . .
Destroyng chairs in a classroom
Yes, seems like the destructor gets called twice! Once upon adding to a vector, and second time upon the program finishing its execution.
The exact same thing happens when I try to use a class instead of a struct.
Can someone explain why this happens and what are the possible ways to accomplish my task correctly?
The Classroom class cannot be used in a std::vector<Classroom> safely because it has incorrect copy semantics. A std::vector will make copies of your object, and if the copy semantics have bugs, then you will see all of those bugs manifest themselves when you start using the class in containers such as vector.
For your class to have correct copy semantics, it needs to be able to construct, assign, and destruct copies of itself without error (those errors being things like memory leaks, double deletion calls on the same pointer, etc.)
The other thing missing from your code is that the size argument needs to be known within the class. Right now, all you've posted is an allocation of memory, but there is nothing that saves the size. Without knowing how many characters were allocated, proper implementation of the user-defined copy constructor and assignment operator won't be possible, unless that char * is a null-terminated string.
Having said that, there a multiple ways to fix your class. The easiest way is to simply use types that have correct copy semantics built into them, instead of handling raw dynamically memory yourself. Those classes would include std::vector<char> and std::string. Not only do they clean up themselves, these classes know their own size without having to carry a size member variable.
struct Classroom
{
std::vector<char> chairs;
Classroom() {} // default constructor
Classroom(size_t size) : chairs(size)
{
std::cout << "Creating " << size << " chairs in a classroom" << std::endl;
}
};
The above class will work without any further adjustments to it, since std::vector<char> has correct copy semantics already. Note that there is no longer a need for the destructor, since std::vector knows how to destroy itself.
If for some reason you had to use raw dynamically allocated memory, then your class has to implement a user-defined copy constructor, assignment operation, and destructor.
#include <algorithm>
struct Classroom
{
size_t m_size;
char* chairs;
// Note we initialize all the members here. This was a bug in your original code
Classroom() : m_size(0), chairs(nullptr)
{}
Classroom(size_t size) : m_size(size), chairs(new char[size])
{}
Classroom(const Classroom& cRoom) : m_size(cRoom.m_size),
chairs(new char[cRoom.m_size])
{
std::copy(cRoom.chairs, cRoom.chairs + cRoom.m_size, chairs);
}
Classroom& operator=(const Classroom& cRoom)
{
if ( this != &cRoom )
{
Classroom temp(cRoom);
std::swap(temp.m_size, m_size);
std::swap(temp.chairs, chairs);
}
return *this;
}
~Classroom() { delete [] chairs; }
};
Note the usage of the member-initialization list when initializing the members of the class. Also note the usage of the copy / swap idiom when implementing the assignment operator.
The other issue that was corrected is that your default constructor was not initializing all of the members. Thus in your original class a simple one line program such as:
int main()
{
Classroom cr;
}
would have caused issues, since in the destructor, you would have deleted an uninitialized chairs pointer.
After this, a std::vector<Classroom> should now be able to be safely used.
#LPVOID
Using emplace_back(..) to create the object in place can help you avoid the double free or corruption error you are facing here.
m_classrooms.emplace_back(29)
However, it is a better practice to always follow the rule of 3/5/0 to not end up with a dangling pointer.
This question already has answers here:
Why does the C++ map type argument require an empty constructor when using []?
(6 answers)
Closed 4 years ago.
class A
{
public:
A(int i)
{
x = new int(i);
}
~A()
{
if (x != NULL)
{
delete x;
x = NULL;
}
}
private:
A();
int *x;
};
void f()
{
{
map<int,A> myMap;
A a(2);
// myMap[7] = a; // cannot access default ctor
pair<int, A> p(7,a);
myMap.insert(p);
}
}
The problem here is that upon scope exit the destructor of A is called twice. Probably the first time to destruct A a(2) and the 2nd time to destruct some temp object created by map. This causes an exception since x is not allocated.
Why does the command myMap[7] = a construct a new A and why does it use the default ctor?
What can be a solution?
Because the subscript operator returns a reference to an element in the map, which you then assign to. In order to have an object to refer to, and assign to, that element must be constructed (unless an element already happens to exist for the given key).
a. To avoid the copy: emplace the A directly into the map instead of copying a local variable.
b. While getting rid of unnecessary copies is a good thing, it is not a substitute to fixing your class. Either make the class have well defined behaviour after assignment and copying, or make the class non copyable and non assignable. For more info, see rule of three (five).
You should never have bare owning pointers. Using a unique pointer instead would fix the class in an elegant way.
I am new to C++ and I do not know how to solve the following problem.
The class Foo has a constructor which creates a array of doubles of a given size. The destructor deletes this array. The print method prints the array.
#include <iostream>
class Foo {
private:
int size;
double* d;
public:
Foo(int size);
~Foo();
void print();
};
Foo::Foo(int size)
{
this->size = size;
d = new double[size];
for (int i = 0; i < size; i++)
{
d[i] = size * i;
}
}
Foo::~Foo()
{
delete[] d;
}
void Foo::print()
{
for (int i = 0; i < size; i++)
{
std::cout << d[i] << " ";
}
std::cout << std::endl;
}
Now I have a function func(Foo f) which does nothing.
void func(Foo f){}
int main()
{
Foo f(3);
f.print();
func(f);
Foo g(5);
f.print();
return 0;
}
Executing this code gives the following output:
0 3 6
0 5 10
Although I am printing f both times, somehow the values inside the array have changed.
I guess that the destructor of Foo is called on parameter Foo f after the execution of func(Foo f) and this frees the allocated memory for d, which is reallocated for Foo g(5). But how can I avoid this without using vectors or smart pointers?
The problem is with the design of the class. The default copy constructor will create a new instance of Foo when passed by value into the free standing function named func.
When the instance of Foo named f exits scope then the code invokes the user-provided destructor that deletes the array of doubles. This opens the code to the unfortunate situation of deleting the same array twice when the original instance of Foo named f exits scope at the end of the program.
When run on my machine, the code does not produce the same output. Instead I see two output lines of 0 3 6 followed by fault indicating the double free operation.
The solution is to avoid the copy by passing by reference (or by const reference): void func(Foo const &f) { } or to supply a valid copy constructor that makes a deep copy of the underlying array. Passing by reference is just a bandaid that avoids exercising the bug.
Using std::vector<double> fixes the problem because the default copy constructor will perform a deep copy and avoid double deallocation. This is absolutely the best approach in this small example, but it avoids having to understand the root of the problem. Most C++ developers will learn these techniques then promptly do what they can to avoid having to write code that manually allocates and deallocates memory.
You should probably pass the object as a reference func(Foo& f) or - if you do not want to modify it at all - as a constant reference func(const Foo& f). This will not create or delete any objects during the function call.
Aside from that, as others have already mentioned, your class should better implement the Rule of Three.
When you pass a value to a function, it is supposed to be copied. The destructor is run on the copy and should no effect on the original object. Foo fails to implement a copy constructor, so compiler provides the default one which simply performs a member-wise copy of the struct. As a result, the "copy" of Foo inside Func contains the same pointer as the original, and its destructor frees the data pointed to by both.
In order to be usable by idiomatic C++ code, Foo must implement at least a copy constructor and an assignment operator in addition to the destructor. The rule that these three come together is sometimes referred to as "the rule of three", and is mentioned in other answers.
Here is an (untested) example of what the constructors could look like:
Foo::Foo(const Foo& other) {
// copy constructor: construct Foo given another Foo
size = other->size;
d = new double[size];
std::copy(other->d, other->d + size, d);
}
Foo& Foo::operator=(const Foo& other) {
// assignment: reinitialize Foo with another Foo
if (this != &other) {
delete d;
size = other->size;
d = new double[size];
std::copy(other->d, other->d + size, d);
}
return *this;
}
Additionally, you can also modify functions like func to accept a reference to Foo or a constant reference to Foo to avoid unnecessary copying. Doing this alone would also happen fix the immediate problem you are having, but it would not help other issues, so you should definitely implement a proper copy constructor before doing anything else.
It's a good idea to get a good book on C++ where the rule of three and other C++ pitfalls are explained. Also, look into using STL containers such as std::vector as members. Since they implement the rule of three themselves, your class wouldn't need to.
One problem is that calling func creates a bitwise copy. When that copy goes out of scope the destructor is called which deletes your array.
You should change void func(Foo f){} to void func(Foo& f){}.
But better yet you add a create copy constructor or add a private declaration to stop it being called unexpectedly.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
initializer_list and move semantics
Environment: Linux, g++-4.7
I used std::vector and a class of my own to test this. And I found that when using the std::initializer_list to construct a vector, it actually calls the copy constructor of the custom class to make a temporary object. Therefore, I consider it really unefficient and I used "const std::initializer_list & li" to replace it.
Why is it really common in STL library?? Eg:
// This is in STL: stl_vector.h
vector(initializer_list<value_type> __l, const allocator_type & __a = allocator_type())
//...
Is there actually something skiped my mind?
My test code is shown below:
#include <iostream>
#include <vector>
#include <initializer_list>
class Test
{
public:
Test(const Test & t) : v(t.v) {
std::cout << "Copy Cons" << std::endl;
}
Test(Test && t) : v(std::move(t.v)) {
std::cout << "MC" << std::endl;
}
Test(int val) : v(val) {}
private:
int v;
};
int main()
{
std::vector<Test> vv({Test(0), Test(1), Test(2)});
return 0;
}//main
It's output:
Copy Cons
Copy Cons
Copy Cons
If you look closely at the link provided in the first comment, you will see why the copy happens:
When you define an initializer_list, the compiler stuffs the content of that list somewhere into a chunk of memory. The initializer_list then consists only of two pointers to the begin and end of that chunk of memory.
When the list is copied into the constructor, only the pointers are copied.
When the vector has allocated its own memory, it copies your objects from the list's chunk'o'mem into it's own memory. That's where you see the copy ctor, not when the list itself is copied.
You can see the syntactic element named initializer lis, i.e. curly braces and a list of comma separated values, as an instruction for the compiler to put the content of that list into a read-only chunk of memory. The std::initializer_list is nothing more than a pair of iterators to that chunk.
Here is the situation :
I use a malloc to allocate memory for a struct.
The struct contains various items such as pointers, string variables and vectors.
The fact is, when we use malloc, no constructors are called. Using a code similar to the following one, I've experienced some situation where some variables worked while others didn't.
Note : The following code doesn't compile. It's purpose is only to illustrate the situation.
struct MyStruct
{
MyClass* mFirstClass;
bool mBool;
std::string mString;
std::vector<MyClass> mVector;
};
int main()
{
MyStruct* wMyStructure;
wMyStructure = (MyStruct*) malloc (sizeof(MyStruct));
MyClass wMyClassObject;
wMyStructure->mFirstClass = new MyClass();
wMyStructure->mFirstClass->func();
wMyStructure->mBool = false;
wMyStructure->mString = "aString";
wMyStructure->mVector.push_back(wMyClassObject);
return 0;
}
By using pointers instead of those variables (std::string* mString), followed by a call to the object constructor (mString = new std::string;) Exception are not thrown.
However, I've experienced a situation where the mString was used without problem without the constructor being called, but when it came to the vector, the application exit automatically.
This left me with many questions:
When will an object throw an exception if no constructor were used?
In the situation I experienced, only the vector caused problem. Could mString be left as it is or should I call it's constructor?
What would be the safest way, using malloc, to do the whole thing?
Using object without constructing it must be an undefined behaviour. Anything may happen at any moment. If you do this, you must not rely on any part of your code to run smoothly, because the language doesn't guarantee anything in this case.
Your code causes undefined behaviour, because your wMyStructure does not point to an object, so you may not use the accessor operator -> on it.
An object only commences its life after its constructor has completed. Since you don't call any constructor, you do not have an object.
(If your struct were a POD, i.e. just consisting of primitive types and PODs, then this would be OK, because PODs have trivial constructors, which do nothing.)
The concrete problem you're facing is that the string and vector members of your struct didn't get to call their constructors, so those members don't exists, and hence the entire object doesn't.
If you want to decouple memory management from object construction, you can use placement syntax:
// get some memory
char arena[HUGE_VAL];
void * morespace = malloc(HUGE_VAL);
// construct some objects
MyClass * px = new (arena + 2000) MyClass; // default constructor
YourClass * py = new (morespace + 5000) YourClass(1, -.5, 'x'); // non-default constructor
(You have to destroy those objects manually, px->~MyClass(); etc., when you're done with them.)
It is undefined behaviour to use a non-initialized object. Exception may be thrown at any time- or not at all.
1 ) When will an object throw an exception if no constructor were used ?
If you don't call the constructor, there is no object. You have just allocated some space.
2 ) In the situation I experienced, only the vector caused problem. Could mString be left as it is or should I call it's constructor ?
This is all undefined behavior, just about anything could happen. There are no rules.
3 ) What would be the safest way, using malloc, to do the whole thing ?
The safest way would be not to use malloc, but allocate using new that will call constructors. It is as simple as this
MyStruct* wMyStructure = new MyStruct;
None of the other answers appear to explain what the compiler is doing. I'll try to explain.
When you call malloc the program reserve some memory space for the struct. That space is filled with memory garbage, (i.e. random numbers in place of the struct fields).
Now consider this code:
// (tested on g++ 5.1.0 on linux)
#include <iostream>
#include <stdlib.h>
struct S {
int a;
};
int main() {
S* s = (S*)malloc(sizeof(S));
s->a = 10;
*((int*)s) = 20;
std::cout << s->a << std::endl; // 20
}
So when accessing a member of a struct you are actually accessing a memory position, there should be no unexpected behavior when writing to it.
But in C++ you can overload operators. Now imagine what would happen if the overloaded assignment operator need the class to be initialized, like in the code below:
// (tested on g++ 5.1.0 on linux)
#include <iostream>
#include <stdlib.h>
class C {
public:
int answer;
int n;
C(int n) { this->n = n; this->answer = 42; }
C& operator=(const C& rhs) {
if(answer != 42) throw "ERROR";
this->n = rhs.n; return *this;
}
};
struct S {
int a;
C c;
};
int main() {
S* s = (S*)malloc(sizeof(S));
C c(10);
C c2(20);
c = c2; // OK
std::cout << c.n << std::endl; // 20
s->c = c; // Not OK
// Throw "ERROR"
std::cout << s->c.n << std::endl; // 20
}
When s->c = c is executed the assignment operator verifies if s->c.answer is 42, if its not it will throw an error.
So you can only do as you did in your example if you know that the overloaded assignment operator of the class std::vector does not expect an initialized vector. I have never read the source code of this class, but I bet it expects.
So its not advisable to do this, but its not impossible to be done with safety if you really need. You just need to be sure you know the behavior of all assignment operators you are using.
In your example, if you really need an std::vector on the struct you can use a vector pointer:
class MyClass { ... };
struct S {
std::vector<MyClass>* vec;
}
int main() {
S s;
MyClass c;
s.vec = new std::vector<MyClass>();
s.vec->push_back(c);
}