<![CDATA[Allocator in Library einbinden]]>Hallo,
angenommen ich schreibe eine Library und moechte, dass diese wahlweise einen anderen Allocator zur Speicherverwaltung nutzt. Dieser soll sich also in jedem Projekt, wo die Bibo genutzt wird aendern lassen.
Wie wuerde man das am besten loesen?
Jede Klasse, die dynamisch Speicher anfordert, mit einem template-Parameter zu versehen faellt fuer mich flach.
Damit ist die einzige Moeglichkeit, die mir noch einfaellt, beim Bauen der Library ein define zu setzen, was dann ggf. einen Header einbindet, der einen anderen Allocator beinhaltet (so mache ich es im Moment).
Dann muesste man natuerlich bei Nutzung eines anderen Allocators die ganze Lib neubauen, aber das waere bei templates ja wohl auch der Fall (bzw wuerde das implizit immer gemacht werden, weil alles im Header liegen wuerde <_<).
Meine eigentlich Frage ist nun: fallen euch Alternativen dazu ein? Ich wuerde defines dieser Art gerne vermeiden wenn es denn moeglich ist und mich gern ueber andere Wege aufklaeren lassen.
Hoffe das Problem ist verstaendlich erklaert.

Ciao

]]>https://www.c-plusplus.net/forum/topic/243911/allocator-in-library-einbindenRSS for NodeSat, 19 Sep 2026 16:50:00 GMTMon, 22 Jun 2009 19:11:45 GMT60<![CDATA[Reply to Allocator in Library einbinden on Mon, 22 Jun 2009 19:11:45 GMT]]>Hallo,
angenommen ich schreibe eine Library und moechte, dass diese wahlweise einen anderen Allocator zur Speicherverwaltung nutzt. Dieser soll sich also in jedem Projekt, wo die Bibo genutzt wird aendern lassen.
Wie wuerde man das am besten loesen?
Jede Klasse, die dynamisch Speicher anfordert, mit einem template-Parameter zu versehen faellt fuer mich flach.
Damit ist die einzige Moeglichkeit, die mir noch einfaellt, beim Bauen der Library ein define zu setzen, was dann ggf. einen Header einbindet, der einen anderen Allocator beinhaltet (so mache ich es im Moment).
Dann muesste man natuerlich bei Nutzung eines anderen Allocators die ganze Lib neubauen, aber das waere bei templates ja wohl auch der Fall (bzw wuerde das implizit immer gemacht werden, weil alles im Header liegen wuerde <_<).
Meine eigentlich Frage ist nun: fallen euch Alternativen dazu ein? Ich wuerde defines dieser Art gerne vermeiden wenn es denn moeglich ist und mich gern ueber andere Wege aufklaeren lassen.
Hoffe das Problem ist verstaendlich erklaert.

Ciao

]]>https://www.c-plusplus.net/forum/post/1731236https://www.c-plusplus.net/forum/post/1731236Mon, 22 Jun 2009 19:11:45 GMT<![CDATA[Reply to Allocator in Library einbinden on Mon, 22 Jun 2009 19:15:29 GMT]]>was ich noch vergessen hatte zu erwaehnen: es handelt sich um einen Allocator im std::allocator Stil, also mit diesem Interface - mit all seinen Problemen und Macken.

]]>https://www.c-plusplus.net/forum/post/1731241https://www.c-plusplus.net/forum/post/1731241Mon, 22 Jun 2009 19:15:29 GMT<![CDATA[Reply to Allocator in Library einbinden on Mon, 22 Jun 2009 19:25:52 GMT]]>Grundsätzlich wäre typedef noch etwas, aber das ist natürlich ungeeignet, wenn ein Typ parametrisiert werden muss. Template-Typedefs gibts ja noch nicht. Der Workaround wäre wohl auch ein wenig weit hergeholt:

template <typename T>
struct AllocatorType
{
    typedef MyAllocator<T> type; // MyAllocator kann ausgewechselt werden
};
]]>https://www.c-plusplus.net/forum/post/1731246https://www.c-plusplus.net/forum/post/1731246Mon, 22 Jun 2009 19:25:52 GMT<![CDATA[Reply to Allocator in Library einbinden on Mon, 22 Jun 2009 20:58:55 GMT]]>Danke fuer Deine Antwort.
Ein typedef loest aber das Problem nicht, dass der Benutzer der Bibliothek seinen eigenen Allocator einbinden koennen soll. Es geht darum, den Allocator bekannt zu machen, damit meine ich effektiv seine Interna. Denn auch wenn er sich an ein bekanntes Interface haelt, muss dennoch die Implementierung bekannt sein, damit er verwendet werden kann (etwa von Containern der STL), weil es sich um compile-time polymophie (templates) handelt (korrigiert mich, wenn ich mich irren sollte).

Zur Veranschaulichung:
ich habe folgenden Header

// Allocator.hpp

#ifdef CUSTOM_ALLOCATOR_INCLUDE
#  include CUSTOM_ALLOCATOR_INCLUDE
#else
#  include <memory>

namespace foo
{
  typedef std::allocator<int> Allocator;
}

#endif

Jetzt kann uniform auf einen Allocator fuer einen beliebigen Typ zugegriffen werden, so z.B.

std::vector<long, foo::Allocator::rebind<long>::other>

Soweit, so gut. In diesem Beispiel kann also mit Hilfe von z.B.

#define CUSTOM_ALLOCATOR_INCLUDE <MallocAllocator.hpp>

ein anderer Allocator bekannt gemacht werden (der im namespace foo als typedef Allocator bereitsteht). Wobei das eher projektweit definiert und auch die Bibliothek damit neu kompiliert werden muss (also eher kein define in dem Sinne, sondern eine configure option oder eine Einstellung im Projekt).
Man beachte dabei, dass Allocator.hpp (der obige Header) zur Bibliothek gehoert (welche Nutzer natuerlich nicht im Code veraendern sollen), sondern nur in diesem Beispiel um einen anderen Allocator ergaenzen, der von irgendwo her kommen kann.

Aber desto mehr ich darueber nachdenke desto eher glaube ich, es geht nicht anders. Wenn dennoch Ideen vorhanden sind: immer her damit.

]]>https://www.c-plusplus.net/forum/post/1731294https://www.c-plusplus.net/forum/post/1731294Mon, 22 Jun 2009 20:58:55 GMT