C++ Puzzle: Prevent heap allocation for derived classes, allow automatic and static

Question

Objectives:

1. Objects of class Base may be static, automatic, allocated directly on the heap, and take part in composite objects allocated anywhere
2. For any class Derived which has Base as an accessible ancestor, objects may be static or automatic and take part in composites, but may not be allocated directly on the heap

Example:

#include "Base.h"
#include "Derived.h"

{
    static Base sb;              // OK
    Base ab, *hb = new Base;     // OK
    static Derived sd;           // OK
    Derived ad;                  // OK
    Derived *pd = &ad;           // OK
    Derived *hd = new Derived;   // Compile error, link error, 
                                 // test-unit exception, or lint gripe
    struct Composite {
        Base cb;
        Derived cd;
    } *hc = new Composite;       // OK 

    // Edit to show side-effects of solutions which hide Base::operator new.

    std::vector<Base> vb;        // OK 
    std::vector<Derived> vd;     // Error
    // ...
}

How could Base be implemented to achieve this? A compile-time error is preferred to a link-time error; but although both are preferred to a test-unit exception, and a test-unit exception is preferred to a lint gripe, any solution that does not require an update to Base.h for each derivation will do.

Edit: For the purposes of this question, solutions which involve forking the compiler so that it supports arbitrary decorations are, despite the technical challenge, classified as "trivial."

Answer 1

Hmm, Eclipse's answer is gone, but I thought it was on the right track.

class Base {
public:
    static Base *create() { return new Base; }
    static Base *create(size_t n) { return new Base[n]; }
private: 
    // Prevent heap allocation
    void *operator new(size_t s);
    void *operator new[](size_t s);
};

This isn't nice, as it obligates you to use Base::create() instead of new Base, and class Derived could still go and implement its own public operator new, but I think it's workable.

Answer 2

Here's one solution I found on the web:

Another standard new, the so-called "placement-new," doesn't allocate memory at all, but can be called to invoke an object's constructor on an arbitrary piece of memory. It is typically defined as:

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

From http://www.scs.stanford.edu/~dm/home/papers/c++-new.html .

Answer 3

While there are ways to "discourage" heap allocation of an object in code (several good ones discussed and linked to here), there is no way to fully prevent it. There are some types such as shared_ptr<T> that I generally never want heap allocated (or perhaps a variant that I truly never want heap allocated). For these, the absolute best solution is understanding and documenting why you never want them heap allocated. With that in place, we never ran into problems because we were consistent about it.

Answer 4

how about privately derive Base?

class Base {
public:
    void *operator new(size_t); 
};

class Derived : private Base {
public:
};

Answer 5

I feel bad for stealing ephemient's thunder here, but the only thing "wrong" with his answer is that he's made Base's operator new private, and not Derived's:

The following code compiles except for the last line, which I think is what you require:

#include <new>
#include <vector>

class Base {};

class Derived : public Base {
private:
  void * operator new (size_t);
};

void foo ()
{
    static Base sb;              // OK
    Base ab, *hb = new Base;     // OK
    static Derived sd;           // OK
    Derived ad;                  // OK
    Derived *pd = &ad;           // OK

    struct Composite {
        Base cb;
        Derived cd;
    } *hc = new Composite;       // OK 

    std::vector<Base> vb;        // OK 
    std::vector<Derived> vd;     // OK


    Derived *hd = new Derived;   // Compile error
}

UPDATE:

As Tal points out, you can still call "new Derived" from a static member of Derived, however by not defining the "operator new" this will result in a link error.

But you can change the code slightly so that it generates a compile error (which is always preferable). We can declare a placement operator new that will still stop us calling the usual operator new.

class Derived : public Base {
public:
  static Derived * create ()
  {
    return new Derived;
  }

private:
  class dont_dynamically_allocate_type_derived;
  void * operator new (size_t, dont_dynamically_allocate_type_derived);
};

Using g++, the the above generates:

t.cc: In static member function static Derived* Derived::create():

t.cc:10: error: no matching function for call to Derived::operator new(unsigned int)

t.cc:15: note: candidates are: static void* Derived::operator new(size_t, Derived::dont_dynamically_allocate_type_derived)

UPDATE (part duex):

I cannot think of any construct where a base class propagates a property that it itself doesn't also have. Tweaking the requirements slightly, if it's allowed to add an extra layer of inheritance you can create two leaf classes, one for Base the type that will be used to instantiate Base objects, and the other that is inherited from:

class Base
{
public:

private:
  friend class BaseInstance;
  friend class BaseDerived;
  ~Base () {}
};

class BaseInstance : public Base
{
public:
  ~BaseInstance () {}
};

class BaseDerived : public Base
{
public:
  ~BaseDerived () {}

private:
  static void * operator new (size_t);
  static void * operator new[] (size_t);
};

class Derived : public BaseDerived {
public:
  static Derived * create ()
  {
    return new Derived;
  }
};

There is still a problem that people can derive from "BaseInstance", although it's name could be made explicitly to stop that happening. There's also the possibility that that class is on the other side of an API and so clients only ever get to see "BaseDerived".