[context] new version with stack-allocator
boost vault contains a new version (0.4.0) where the user can provide its own stack allocator (the lib comes with a protected-stack allocator). Oliver
--- El lun 24-ene-11, Oliver Kowalke <k-oli@gmx.de> escribió:
De: Oliver Kowalke <k-oli@gmx.de> Asunto: [boost] [context] new version with stack-allocator Para: boost@lists.boost.org Fecha: lunes, 24 de enero de 2011, 10:00 boost vault contains a new version (0.4.0) where the user can provide its own stack allocator (the lib comes with a protected-stack allocator).
thanks for this change! i was precisely going to require passing a custom allocator to this (for a severely constrained system). just a question: Does the code relies on the 'standarese' assumption that allocators have to be stateless? the reason why i ask is because some of my code relies on allocators being stateful objects (yeah i know, break the standard and you are on your known, yadda yadda), hence it's ok if you do but i would like to know -Charles
Am 25.01.2011 17:39, schrieb Charlls Quarra:
thanks for this change! i was precisely going to require passing a custom allocator to this (for a severely constrained system).
just a question: Does the code relies on the 'standarese' assumption that allocators have to be stateless? the reason why i ask is because some of my code relies on allocators being stateful objects (yeah i know, break the standard and you are on your known, yadda yadda), hence it's ok if you do but i would like to know
-Charles
the restrictions on the allocator are: - must be copyable - functions allocate() and deallocate() must not throw (allocate() should return zero instead) so - the allocator can be state-full and can shared between several contexts/fiber etc. You could implement an allocator managing a pool of stack-space. so long, Oliver
Am 25.01.2011 17:39, schrieb Charlls Quarra:
just a question: Does the code relies on the 'standarese' assumption that allocators have to be stateless? the reason why i ask is because some of my code relies on allocators being stateful objects (yeah i know, break the standard and you are on your known, yadda yadda), hence it's ok if you do but i would like to know
an additional requirement: the stack must be aligned according to the architecture too
participants (2)
-
Charlls Quarra -
Oliver Kowalke