Re: private destructor and templates
Ben Voigt wrote:
A strict reading of the PostMessage docs for VC2005 implies it is illegal,
though I don't understand why it should be illegal, since, as you say, you
have control of the pointers at both ends.
Rather the strict reading says that the warnings don't apply to me because
I'm using WM_USER, not "a message in the range below WM_USER".
Ahh, I now see that the docs only apply to system messages, apologies
for the confusion.
The point is, you should not be calling constructors if you don't match
the constructor calls with equivalent destructor calls. To avoid
constructor calls, you shouldn't use new-expressions.
If I define operator new myself and have no data members with non-trivial
constructor, then the only extra code being executed are my constructors,
right?
Typically, though obviously the compiler can add any extra code it
wants. e.g. in debug builds, the constructors might initialize the
objects memory to 0xDEADBEEF or something before running any other
constructor code, or the object might be registered with a "live
objects" registry.
However, the reason not to use new-expressions is to avoid having to use
delete-expressions, which invoke destructors. If you instead allocate
the memory manually (with malloc, ::operator new or even class::operator
new), and then use placement new or an init function to initialize the
object, then the errors you were getting with destructors will not occur
on any compiler.
/**
** \param Base, should be derived from OpNotification or OpRequest
** and provide a default constructor.
**/
template<typename Base>
struct IConcurrentOperations::BufferedMessage
: public AllocHelper<IConcurrentOperations::BufferedMessage<Base>, Base>
{...}
That still needs to be explicitly specified for every concrete derived type
:(
An alternative would be to stick with the current inheritence heirarchy,
and create a free function (or a member of Base if you prefer):
template <class Derived>
Derived* Alloc()
{
void* p = Base::Alloc(sizeof(Derived));
return new(p) Derived();
}
and then the derived classes just allocate themselves with:
Derived* d = Alloc<Derived>();
rather than with
Derived* d = new Derived();
Again, you can avoid going near the destructors with your Free function,
since you won't use a delete-expression (but rather ::operator delete or
free()). You can also declare (but not define) a private operator new
and delete in Base, to make sure no one accidentally does a new or
delete on the derived types.
Is this page accurate:
http://www.informit.com/guides/content.asp?g=cplusplus&seqNum=196&rl=1
Well, it doesn't mention that the location of base objects is
unspecified. It has them directly preceding derived objects, but that
isn't required - they may actually be held in a completely different
part of memory. Only POD objects need use contiguous storage, though in
practice I've not heard of an implementation taking advantage of this
allowance. I suppose, in theory, an implementation could notice that the
base class is constant and can only take a limited set of values,
generate one sub-object for each possible value, and then put a pointer
to the relevent base class sub-object in the derived class on construction.
Tom