Cannot delete created library object

[Christian Christmann]

Hi,

in my source code I've included a library I've not written and source code
is available.

In a function, I've generate an object of that library class dynamically
with "new" and at the function's end I want to freed memory for that
object with "delete". However, doing that seem to be not allowed since
I get the compiler error:

error: `virtual LibraryClass::~LibraryClass()' is protected
myfile.cc:1000: error: within this context

Any ideas what to do in order to avoid memory leaking?

Regards,
Chris

 

[Alf P. Steinbach]

* Christian Christmann:

in my source code I've included a library I've not written and source code
is available.

In a function, I've generate an object of that library class dynamically
with "new" and at the function's end I want to freed memory for that
object with "delete". However, doing that seem to be not allowed since
I get the compiler error:

error: `virtual LibraryClass::~LibraryClass()' is protected
myfile.cc:1000: error: within this context

Any ideas what to do in order to avoid memory leaking?

Check how objects of that class are meant to be deleted. Some
possibilities for a meaningful design are:

* A free function 'destroy', declared as a 'friend'.

* A smart-pointer class such as 'std::auto_ptr', again, declared
as a 'friend'.

* A static member function, e.g. 'LibraryClass::destroy'.

* A non-static member function, e.g. 'pObject->destroy()' or
'pObject->release()'.

* Automagical clean-up through external means, e.g. a call to a
function 'destroyThemPeskyObjects' which destroys all LibraryClass
objects allocated since the last such call.

 

[Roland Pibinger]

* Christian Christmann:

Check how objects of that class are meant to be deleted. Some
possibilities for a meaningful design are:

* A free function 'destroy', declared as a 'friend'.

* A smart-pointer class such as 'std::auto_ptr', again, declared
as a 'friend'.

* A static member function, e.g. 'LibraryClass::destroy'.

* A non-static member function, e.g. 'pObject->destroy()' or
'pObject->release()'.

* Automagical clean-up through external means, e.g. a call to a
function 'destroyThemPeskyObjects' which destroys all LibraryClass
objects allocated since the last such call.

* the object isn't intended to be new-ed and deleted at all by the
user. It's either meant to be a stack object or created and managed
(owned) by another object. Anyway, it seems that the user is not in
charge of resource management for that object. The latter is a feature
of any good C++ library.

Best regards,
Roland Pibinger

 

[Alf P. Steinbach]

* Roland Pibinger:

* the object isn't intended to be new-ed and deleted at all by the
user. It's either meant to be a stack object or created and managed
(owned) by another object. Anyway, it seems that the user is not in
charge of resource management for that object. The latter is a feature
of any good C++ library.

Roland, unless this is a class you have designed yourself, where I think
anything would go, please do stop posting misleading nonsense in the
form of statements of fact: post the nonsense as questions (like, "could
perhaps...?") if you absolutely must. Hint why your statement is
nonsense: making the destructor inaccessible is a common technique for
/preventing/ stack allocation, as well as other non-dynamic allocation.
TIA for not posting your nonsense as statements of fact in the future.

 

[Heinz Ozwirk]

Hi,

in my source code I've included a library I've not written and source code
is available.

In a function, I've generate an object of that library class dynamically
with "new" and at the function's end I want to freed memory for that
object with "delete". However, doing that seem to be not allowed since
I get the compiler error:

error: `virtual LibraryClass::~LibraryClass()' is protected
myfile.cc:1000: error: within this context

Any ideas what to do in order to avoid memory leaking?

As Alf already told you -- read how those objects are supposed to use.

If the destructor is protected, it can only use by members of that class, by
members of a derived class or by friends. So additionally to the points Alf
already mentioned, pehaps the object is not intended to be used directly and
you are supposed to create your own class derived from that one in the
library. However, the usual way to force deriving another class is using
pure virtual functions in the base class or making all its ctors protected,
but a protected dtor also prevents direct use of such a class. So, read the
docs.

HTH
Heinz

 

[Roland Pibinger]

in my source code I've included a library I've not written and source code
is available.
In a function, I've generate an object of that library class dynamically
with "new" and at the function's end I want to freed memory for that
object with "delete". However, doing that seem to be not allowed since
I get the compiler error:

error: `virtual LibraryClass::~LibraryClass()' is protected
myfile.cc:1000: error: within this context

There are two common situations where this may arise. Since I was
deliberately misinterpreted in a subtread I give two examples of what
might have happened.

1. The class uses 'implementation' inheritance. To prevent derived
objects from being used polymorphically the base class destructor (and
constructor) are made protected. Implememtaton inheritance is
typically used for value types, i.e. small objects with value
semantics that are created on the stack:

class ValueImp{
protected:
ValueImp() {}
~ValueImp() {}
// ...
};

class Value : public ValueImp{
};

int main() {
ValueImp* p = new Value();
delete p; // error
}

2. The dynamically created object is managed (created, owned, deleted)
by another object. This idiom simplifies resource management issues
because allocation and deallocation disappear from the surface level
of your code. Again, a protected or private destructor inhibits
unintended behavior:

class Manager;

class ManagedObject {
protected:
~ManagedObject() {}
friend class Manager;
};

class Manager {
public:
Manager() {}
~Manager() {
while (!container.empty()) {
ManagedObject* tmp = container.back();
container.pop_back();
delete tmp;
}
}

ManagedObject* create() {
ManagedObject* p = new ManagedObject();
container.push_back (p);
return p;
}
private:
std::vector<ManagedObject*> container;
// non copyable
Manager (const Manager&);
Manager& operator= (const Manager&);
};


int main() {
Manager m;
ManagedObject* p = m.create();
delete p; // error
}

Best wishes,
Roland Pibinger

 

[Markus Moll]

Hi

* Roland Pibinger:

Roland, unless this is a class you have designed yourself, where I think
anything would go, please do stop posting misleading nonsense in the
form of statements of fact: post the nonsense as questions (like, "could
perhaps...?") if you absolutely must.

Sorry, but the "*" at the beginning of the paragraph imho clearly indicates
that he only wanted to add another possibility (that you forgot to mention)
to your list. (So, calm down It's healthier anyway)

Furthermore, I think it's the most likely possibility. Objects of that class
maybe should not be created by the user, but should be obtained by other
means (some kind of factory).

Markus

 

[Alf P. Steinbach]

* Markus Moll:

Hi


Sorry, but the "*" at the beginning of the paragraph imho clearly indicates
that he only wanted to add another possibility (that you forgot to mention)
to your list. (So, calm down It's healthier anyway)

Furthermore, I think it's the most likely possibility. Objects of that class
maybe should not be created by the user, but should be obtained by other
means (some kind of factory).

Regarding the possibility of "it" being a "stack object", the 'auto'
keyword in current C++: no, an inaccessible destructor disallows that.

Regarding the possibility of such objects being restricted to dynamic
allocation (as they are, unless one derives from the class) and
allocation via factory functions, no, in that case it's not reasonable
to use factory functions. Factory functions would just duplicate the
constructor functionality of the class. Avoiding that redundance --
i.e. avoiding factory functions -- is much of the point of using an
inaccessible destructor.

I agree that the "*" probably meant an additional point, and I
misinterpreted it. But that doesn't fix the point(s) being expressed.