Question

Removed the C tag, seeing as that was causing some confusion (it shouldn’t have been there to begin with; sorry for any inconvenience there. C answer as still welcome though 🙂

In a few things I’ve done, I’ve found the need to create objects that have a dynamic size and a static size, where the static part is your basic object members, the dynamic part is however an array/buffer appended directly onto the class, keeping the memory contiguous, thus decreasing the amount of needed allocations (these are non-reallocatable objects), and decreasing fragmentation (though as a down side, it may be harder to find a block of a big enough size, however that is a lot more rare – if it should even occur at all – than heap fragmenting. This is also helpful on embedded devices where memory is at a premium(however I don’t do anything for embedded devices currently), and things like std::string need to be avoided, or can’t be used like in the case of trivial unions.

Generally the way I’d go about this would be to (ab)use malloc(std::string is not used on purpose, and for various reasons):

struct TextCache
{
    uint_32 fFlags;
    uint_16 nXpos;
    uint_16 nYpos;
     TextCache* pNext;
    char pBuffer[0];
};

TextCache* pCache = (TextCache*)malloc(sizeof(TextCache) + (sizeof(char) * nLength));

This however doesn’t sit too well with me, as firstly I would like to do this using new, and thus in a C++ environment, and secondly, it looks horrible 😛

So next step was a templated C++ varient:

template <const size_t nSize> struct TextCache
{
    uint_32 fFlags;
    uint_16 nXpos;
    uint_16 nYpos;
     TextCache<nSize>* pNext;
    char pBuffer[nSize];
};

This however has the problem that storing a pointer to a variable sized object becomes ‘impossible’, so then the next work around:

class DynamicObject {};
template <const size_t nSize> struct TextCache : DynamicObject {...};

This however still requires casting, and having pointers to DynamicObject all over the place becomes ambiguous when more that one dynamically sized object derives from it (it also looks horrible and can suffer from a bug that forces empty classes to still have a size, although that’s probably an archaic, extinct bug…).

Then there was this:

class DynamicObject
{
    void* operator new(size_t nSize, size_t nLength)
    {
        return malloc(nSize + nLength);
    }
};

struct TextCache : DynamicObject {...};

which looks a lot better, but would interfere with objects that already have overloads of new(it could even affect placement new…).

Finally I came up with placement new abusing:

inline TextCache* CreateTextCache(size_t nLength)
{
    char* pNew = new char[sizeof(TextCache) + nLength];
    return new(pNew) TextCache;
}

This however is probably the worst idea so far, for quite a few reasons.

So are there any better ways to do this? or would one of the above versions be better, or at least improvable? Is doing even considered safe and/or bad programming practice?

---

As I said above, I’m trying to avoid double allocations, because this shouldn’t need 2 allocations, and cause this makes writing(serializing) these things to files a lot easier.
The only exception to the double allocation requirement I have is when its basically zero overhead. the only cause where I have encountered that is where I sequentially allocate memory from a fixed buffer(using this system, that I came up with), however its also a special exception to prevent superflous copying.

Answer 1

I’d go for a compromise with the DynamicObject concept. Everything that doesn’t depend on the size goes into the base class.

struct TextBase 
{ 
    uint_32 fFlags; 
    uint_16 nXpos; 
    uint_16 nYpos; 
     TextBase* pNext; 
}; 

template <const size_t nSize> struct TextCache : public TextBase
{ 
    char pBuffer[nSize]; 
}; 

This should cut down on the casting required.