 |
C++Talk.NET C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Guest
|
Posted: Sat Mar 17, 2007 2:39 am Post subject: stl container interna fuer boost::pool |
|
|
Hallo,
I. ich möchte gern boost::pool_alloc für stl::container benutzen,
benötige jedoch fürs release_memory oder purge_memory die Größe der
internen Knoten (map node, set node, list node). Gibt es einen STL-
Implementations-unabhängigen Weg, an diese Typen zu gelangen?
II. Warum sollte beim Anlegen des pool_alloc für zB set<T> T
interessant für die Parametrisierung von pool_alloc sein, wo doch der
pool aus n*set<T>::node<T> besteht?
Danke für Hilfe, jan. |
|
| Back to top |
|
 |
Markus Schaaf Guest
|
Posted: Sat Mar 17, 2007 4:45 pm Post subject: Re: stl container interna fuer boost::pool |
|
|
jan.boehme (AT) googlemail (DOT) com schrieb:
| Quote: | I. ich möchte gern boost::pool_alloc für stl::container benutzen,
benötige jedoch fürs release_memory oder purge_memory die Größe der
internen Knoten (map node, set node, list node). Gibt es einen STL-
Implementations-unabhängigen Weg, an diese Typen zu gelangen?
|
Was heißt "gelangen"? Sie werden dem Allokator doch als Parameter
übergeben. Über `allocator::rebind<U>` werden vom Container die
benötigten anderen Allokatoren beschafft und innerhalb dieser
kennst Du den Typen. Seine Größe ist dann `sizeof (T)`.
| Quote: | II. Warum sollte beim Anlegen des pool_alloc für zB set<T> T
interessant für die Parametrisierung von pool_alloc sein, wo doch der
pool aus n*set<T>::node<T> besteht?
|
Du meinst, warum ein Container für `double` mit
`allocator<double>` als Parameter startet, auch wenn er ihn nicht
direkt benötigt? Weil Du sonst bei jeder neuen Std-Lib-
Implementierung ein neues Interface hättest. |
|
| Back to top |
|
 |
jan boehme Guest
|
Posted: Mon Mar 19, 2007 8:03 pm Post subject: Re: stl container interna fuer boost::pool |
|
|
Hallo Markus,
danke für Deine Antwort.
On Mar 17, 12:45 pm, Markus Schaaf <mar...@sags-per-mail.de> wrote:
| Quote: | Was heißt "gelangen"? Sie werden dem Allokator doch als Parameter
übergeben. Über `allocator::rebind<U>` werden vom Container die
benötigten anderen Allokatoren beschafft und innerhalb dieser
kennst Du den Typen. Seine Größe ist dann `sizeof (T)`.
|
Unter gcc wäre das für set std::_Rb_tree_node<T>. Wenn ich einen
Allokator schreibe wird mir per rebind der Typ bekannt gemacht - das
hilft mir aber auf Anwenderebene nicht weiter. Leider sind die
zugehörigen typedefs private oder protected. Ich fragte nach einer
öffentlichen Typ-Bekanntmachung ala std::set<type>::node_type nur
verschachtelter, da es sowas ja nicht überall gibt. Offenbar gab es
beim Entwurf keinerlei Interessen, diese internen Strukturen per
typedef bekannt zu machen.
boost::pool::release_memory benötigt aber
sizeof( std::set<type>::node_type ) was ich nun mit vielen ifdefs
versehen zur Verfügung stellen müsste/muss.
| Quote: | Du meinst, warum ein Container für `double` mit
`allocator<double>` als Parameter startet, auch wenn er ihn nicht
direkt benötigt? Weil Du sonst bei jeder neuen Std-Lib-
Implementierung ein neues Interface hättest.
|
In anderem Kontext sicher sinnvoll, hier durch den Rebind und die Um-
Parametrisierung der Klasse schlicht sinnlos. Ich kann hier einen
anderen, beliebigen Typen einsetzen, ohne dass dies zu Ärger führen
würde. |
|
| Back to top |
|
 |
Powered by phpBB © 2001, 2006 phpBB Group
|