 |
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 |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
