How do I know if memory is already allocated?

[Kjell Arne Johansen]

Hi

How does it work?

//This works
//Constructor is run and memory allocated for m_AnObject
CSomeClass SomeClass1;
//copying data works fine
SomeClass1 = SomeClass2;

//Oooops, constructor is not run. (Should it be?) Memory is not
//allocated for m_AnObject. Only copy constructor and assignment
//operator is run. How do I check if memory is allocated for
//m_AnObject???
SomeClass SomeClass1 = SomeClass2;

//The code
//Standard constructor
CSomeClass::CSomeClass()
{
m_AnObject = new CAnObject();
}

//Copy constructor
CSomeClass::CSomeClass(const CSomeClass& orig)
{
*this = orig;
}

//Assignment operator overriding
CSomeClass& CSomeClass:perator=(const CSomeClass& rhs)
{
if(this != &rhs)
{ //Does m_AnObject point to legal memory??
*m_AnObject = *rhs.m_AnObject;
}
return *this;
}

How do I find out if memory is already allocated?

Regards
Kjell Arne Johansen

 

[Attila Feher]

Hi

How does it work?

//This works
//Constructor is run and memory allocated for m_AnObject
CSomeClass SomeClass1;
//copying data works fine
SomeClass1 = SomeClass2;

//Oooops, constructor is not run. (Should it be?) Memory is not
//allocated for m_AnObject. Only copy constructor and assignment
//operator is run. How do I check if memory is allocated for
//m_AnObject???
SomeClass SomeClass1 = SomeClass2;

//The code
//Standard constructor
CSomeClass::CSomeClass()
{
m_AnObject = new CAnObject();
}

//Copy constructor
CSomeClass::CSomeClass(const CSomeClass& orig)
{
*this = orig;
}

//Assignment operator overriding
CSomeClass& CSomeClass:perator=(const CSomeClass& rhs)
{
if(this != &rhs)
{ //Does m_AnObject point to legal memory??
*m_AnObject = *rhs.m_AnObject;
}
return *this;
}

How do I find out if memory is already allocated?

Why do you think it is not? Your constructor make it sure it does. The
other functions only copy. In your code the pointer always points to a
valid memory area returned by the new CAnObject() until your destructor is
called (I hope you have one).

 

[Nils Petter Vaskinn]

//Copy constructor
CSomeClass::CSomeClass(const CSomeClass& orig)
{

m_AnObject = new CAnObject();

*this = orig;
}

//Assignment operator overriding
CSomeClass& CSomeClass:perator=(const CSomeClass& rhs)
{
if(this != &rhs)
{ //Does m_AnObject point to legal memory??

// By allocating memory for it in the copy constructor we can now be sure
// that it does.

*m_AnObject = *rhs.m_AnObject;
}
return *this;
}

CSomeClass::~CSomeClass()
{
delete m_AnObject;
// make sure memory is freed
}



hth
NPV

 

[Nils Petter Vaskinn]

Kjell Arne Johansen wrote:

Why do you think it is not? Your constructor make it sure it does. The
other functions only copy. In your code the pointer always points to a
valid memory area returned by the new CAnObject() until your destructor is
called (I hope you have one).

But the copy constructor does not allocate it's own memory, so if you
copy an object the two will share the internal object. Then when one of
them is destroyed (with a proper destructor) the other object will be left
with a dangling pointer just waiting to cause a crash.
If this is the desired behaviour the default copy constructor will do fine.

regards
NPV

 

[Attila Feher]

Nils Petter Vaskinn wrote:
[SNIP]

But the copy constructor does not allocate it's own memory, so if you
copy an object the two will share the internal object. Then when one
of them is destroyed (with a proper destructor) the other object will
be left with a dangling pointer just waiting to cause a crash.
If this is the desired behaviour the default copy constructor will do
fine.

Hm. I have apparently missed the broken copy constructor. The OP needs to
do something like this (along the lines of his copy assignment operator):

//Copy constructor
CSomeClass::CSomeClass(const CSomeClass& orig)
{
m_AnObject = new CAnObject(*orig.m_AnObject);
}

Assuming his CAnObject type has a proper copy constructor.

 

[Kjell Arne Johansen]

Hi

Yes of course. Allocate memory in the copy constructor.
Thank You.

(I have a proper destructor

Regards
Kjell Arne

 

[llewelly]

Nils Petter Vaskinn wrote:
[SNIP]

But the copy constructor does not allocate it's own memory, so if you
copy an object the two will share the internal object. Then when one
of them is destroyed (with a proper destructor) the other object will
be left with a dangling pointer just waiting to cause a crash.
If this is the desired behaviour the default copy constructor will do
fine.

Hm. I have apparently missed the broken copy constructor. The OP needs to
do something like this (along the lines of his copy assignment operator):

//Copy constructor
CSomeClass::CSomeClass(const CSomeClass& orig)
{
m_AnObject = new CAnObject(*orig.m_AnObject);
}

Assuming his CAnObject type has a proper copy constructor.

But if that is desirable why not just abandon new, the pointer, the
hassle of dynamic memory allocation, and do this:

class CSomeClass
{
//This class relies on the compiler-generated
// default constructor,
// copy constructor,
// destructor,
// and copy-assignment operator.
CAnObject m_AnObject;
public:
//... Some public interface the OP didn't show us ...
};

Why do work when the compiler will do it for you?

 

[Attila Feher]

llewelly wrote:
[SNIP]

class CSomeClass
{
//This class relies on the compiler-generated
// default constructor,
// copy constructor,
// destructor,
// and copy-assignment operator.
CAnObject m_AnObject;
public:
//... Some public interface the OP didn't show us ...
};

Why do work when the compiler will do it for you?

Maybe he is using the PIMPL idiom?

 

[Kjell Arne Johansen]

llewelly wrote:
[SNIP]

class CSomeClass
{
//This class relies on the compiler-generated
// default constructor,
// copy constructor,
// destructor,
// and copy-assignment operator.
CAnObject m_AnObject;
public:
//... Some public interface the OP didn't show us ...
};

Why do work when the compiler will do it for you?

Maybe he is using the PIMPL idiom?

Thank you for your help. The problem is solved and everything is
fine. CSomeClass is an interface class operating on the CAnObject
methods.

Kjell Arne