views:

45

answers:

1

I have a (C++) system that has many classes that have variable storage (memory) requirements. In most of these cases, the size of the required storage is known at the creation of the object, and is fixed for the lifetime of the object.

I use this, for instance, to create a "String" object that has a count field, followed directly by the actual characters, inline with the object.

class String {
public:
    size_t count;
    String(size_t count, const char* text) : count(count) {/*...*/}
    inline char& at(size_t index) {
        return *(reinterpret_cast<char*>(this + 1) + index);
    }
    void* operator new (size_t size, size_t count) {
        return new char[size + count * sizeof(char)];
    }
};

class Node {
public:
    size_t count;
    Node(size_t count, ...) : count(count) {/*...*/}
    inline Node*& at(size_t index) {
        return *(reinterpret_cast<Node**>(this + 1) + index);
    }
    void* operator new (size_t size, size_t count) {
        return new char[size + count * sizeof(Node*)];
    }
};

// ... and several more like this

I am trying to reduce this code duplication by factoring out this "inline array" behavior into a common base class:

template<class T>
class Expando {
    size_t count;
    Expando(size_t count) : count(count) {}
    inline T& at(size_t index) {
        return *(reinterpret_cast<T*>(this + 1) + index);
    }
    void* operator new (size_t size, size_t count) {
        return new char[size + count * sizeof(T)];
    }
};

However, when I inherit from this class:

class String : public Expando<char> {/*...*/}

And go to create a new String:

String* str = new (4) String(4, "test");

GCC tries to use my globally overloaded new operator, instead of the one in Expando:

inline void* operator new (size_t size, void* mem) { return mem; }

Now, I could just duplicate the new operator for each of the classes (String, Node, ...), but that would half-defeat the purpose of the refactoring.

Is there a simple solution to this? I'd like to maintain the data inline with the rest of the class (to avoid extra dereferencing and heap allocation), as well as avoid non-standard extensions (such as the zero-size arrays at the end of classes). At the same time, I'd like to reduce duplication.

+1  A: 

have you used

using Expando::new

in your derived class new operator? For example:

void* operator new (....)
{
    using Expando::new;
    ....
}

Otherwise, if you don't mind my opinion, I think your implementation of your String class is way off base. You have a count member, but no actual pointer data member to point to an array of whatever will comprise your string. Talk about a weird implementation. That is just asking for trouble from a maintanence developer a few years down the road as they scratch their head and go: "Whaaat?"

C Johnson
I was hoping for a solution that didn't require me to implement the new operator in each derived class - I am trying to "factor out" all of the implementations of (primarily) the at(...) and operator new(...). Also, keep in mind that the code is already written this way, and has been for several years. It would certainly make a lot more sense to me, as a maintanence developer, if I knew that everything derived from "Expando" used this funky "inline data" concept.
Joshua Warner
I feel rather stupid now - I went back and realized that I had accidentally declared Expando::operator new "private", and the compiler was just giving irrelevant errors.
Joshua Warner
We all inherit some weird code that we have to maintain from time to time.
C Johnson