habe hier eine Klassen Hierarchie:

class A{};
struct B:A{};
struct C:A{};
struct D:C{};
//... uvm ...

u.a. aus Performance Gründen, möchte ich nun versuchen, ob eine eigene Speicherverwaltung hier Vorteile bringt. Um das zu wissen, muss ich da wohl aber effektiv testen, und dabei natürlich möglichst wenig arbeit haben.
Zumindest was die Implementierung angeht.

Aktuell ist dies meine Überlegung:

template<class T, class alloc_impl = alloc_impl<sizeof(T)> >
class new_impl : public T
{
	alloc_impl alloc;
public:
	void* operator new(size_t size)
	{
		if(size != sizeof(new_impl<T,alloc_impl>))
			return ::operator new(size);
		return alloc.allocate(size);
	}
	void operator delete(void* p, size_t size)
	{
		if(size != sizeof(new_impl<T,alloc_impl>))
			return ::operator delete(size);
		return alloc.deallocate(size);
	}
};

A erbt dann einfach von new_impl.
Solange die Kinder die größe von sizeof(A) haben, ist das auch ne sichere sache.
Haben sie aber nich. mist. Mehrfachvererbung könnte man jetzt sagen, ala struct B:A,new_impl<B>
Da bleibt für mich jetzt die frage, ob sizeof(B) in new_impl<B > jetzt auch hier von A weiss?
Falls ja, super, problem gelöst.

Anderenfalls müsste ich wohl zu einer Art Man-in-the-Middle Vererbung greifen:

template<class T,class parent = T, class alloc_impl = alloc_impl<sizeof(T)> >
class new_impl : public parent
{
  ...
};
class A:new_impl<A>{};
class B:new_impl<B,A>

Kann man operator new/delete so vererben?
Gibt es einen besseren Ansatz, wenn man "Nachrüsten" will?

Warum hast du in new_impl die Überprüfung?

void* operator new(size_t size)
    {
        if(size != sizeof(new_impl<T,alloc_impl>))//die
            return ::operator new(size);
        return alloc.allocate(size);
    }

ohne würde dein Unterfangen meines Wissens nach out-of-the-box funktionieren. Der Compiler ruft dann für D A::operator new (sizeof(D)) auf und alles ist Okay. Natürlich musste dann deinen Allocator etwas umschreiben, damit er sich mit einem memory-pool verbindet der verschiedene Größen Allokieren kann. Aber das brauchste hier ja auch...

Hey,

Warum hast du in new_impl die Überprüfung?

void* operator new(size_t size)
    {
        if(size != sizeof(new_impl<T,alloc_impl>))//die
            return ::operator new(size);
        return alloc.allocate(size);
    }

ohne würde dein Unterfangen meines Wissens nach out-of-the-box funktionieren. Der Compiler ruft dann für D A::operator new (sizeof(D)) auf und alles ist Okay. Natürlich musste dann deinen Allocator etwas umschreiben, damit er sich mit einem memory-pool verbindet der verschiedene Größen Allokieren kann. Aber das brauchste hier ja auch...

Naja, also ich orientiere mich da an Effective C++, dort ist dass so beschrieben. Auch um das Standardverhalten von op new zu grantieren.
Damit habe ich halt momentan für jede Größe einen eigenen Pool, könnte man natürlich auch in eine Instanz tun...

Naja, also ich orientiere mich da an Effective C++, dort ist dass so beschrieben.

Dort ist dann bestimmt auch beschrieben dass eben diese Abfrage dazu da ist, dass abgeleitete Klassen mit sizeof(D) != sizeof(A) die Standard-Allokation benutzen.

phlox@work schrieb:

Naja, also ich orientiere mich da an Effective C++, dort ist dass so beschrieben.

Dort ist dann bestimmt auch beschrieben dass eben diese Abfrage dazu da ist, dass abgeleitete Klassen mit sizeof(D) != sizeof(A) die Standard-Allokation benutzen.

Jo, genau.
Nur stellt er das halt anhand einer recht kleinen Klasse vor, wobei ich hier ja das gerne auf eine schon bestehende Klassenhierarchie und mit möglichst hoher wiederverwendbarkeit implementieren will...

Deine "man-in-the-middle" Vererbung ist der Richtige weg, allerdings sollte parent nicht T sein, da du sonst zirkuläre vererbung hast (A erbt von new_impl, new_impl erbt von A,...):

struct Empty {};

template <class T, class Parent = Empty, class Alloc = alloc_impl<sizeof(T)> >
class new_impl : public Parent //Empty als Base können die meisten Compiler wegoptimieren
{
  /* ... */
};

Allerdings solltest du berücksichtigen, dass dabei die Zahl der Klassen in der Hierarchie verdoppelt wird und jede zweite davon (die new_impl) jeweils einen alloc als Member haben, von denen alle bis auf den letzten sinnlos sind.

Mit dem Allocator werde ich mich dann noch was beschäftigen müssen...