P4 Description
It has many functions that ought not be part of its public API.
It has a "factory" function (new_from_buffer) whose only use is technically undefined behavior, since it is applying placement new to memory containing an already constructed object.
It can't be used as a data member or ordinary variable, but must *always* be allocated. But public ctor/dtor allow improper use. And while it must be allocated, it doesn't - and can't - use the normal hotspot mechanism for indicating that, e.g. derivation from CHeapObj. Doing so with a public ctor/dtor would again allow improper use. Instead the ctor/dtor should be private, with factory allocation and deallocation functions.
The computation of the "buffer" offset is also obscure and relying on unspecified behavior. The current mechanism and lack of documentation also obscures that this class has a roll-your-own "flexible array member" (using C99 terminology for a feature that isn't directly supported by C++, though C++ EWG issue 153 is about adding such).
It has a "factory" function (new_from_buffer) whose only use is technically undefined behavior, since it is applying placement new to memory containing an already constructed object.
It can't be used as a data member or ordinary variable, but must *always* be allocated. But public ctor/dtor allow improper use. And while it must be allocated, it doesn't - and can't - use the normal hotspot mechanism for indicating that, e.g. derivation from CHeapObj. Doing so with a public ctor/dtor would again allow improper use. Instead the ctor/dtor should be private, with factory allocation and deallocation functions.
The computation of the "buffer" offset is also obscure and relying on unspecified behavior. The current mechanism and lack of documentation also obscures that this class has a roll-your-own "flexible array member" (using C99 terminology for a feature that isn't directly supported by C++, though C++ EWG issue 153 is about adding such).