|
Boost : |
From: hicks (hicks_at_[hidden])
Date: 2002-04-28 21:07:01
//> To David White
//>
//> I did not realize that there would be a seperate allocator for each
//> object size.
//> Is that right?
//
//
//Well, originally I had in mind one allocator that would be shared
//between arrays. However, the arithmetic needed to make sure that objects
//are aligned properly is actually substantial, so I moved to having one
//allocator for each object size. I'm not sure if this is the right
//decision though, I think doing it either way has its merits.
For a fixed size, what would be the merits/demerits of re-using
array or deque containers?
//
//
//
//> I am having some trouble getting var_len_array.hpp and the test package
//> to compile under borland.
//>
//> I had to elise the line
//>
//> #ifndef __BORLANDC__
//> template<std::size_t ObjSize>
//> detail::stack_allocator_impl<ObjSize>
stack_allocator<ObjSize>::instance;
//> #endif
//>
//> in order to compile up to link.
//
//
//Well, afaik this is the proper way to define a static member of a class
//template, so unless someone can tell me otherwise I'll assume that
//Borland is simply doing the wrong thing in this case.
//
//I tried several other ways of implementing the singleton allocator,
//including some ways that I am fairly sure would work better on other
//compilers, but which exacted a substantial performance hit. E.g. using a
//Meyer's Singleton:
//
//Change:
//
//static detail::stack_allocator_impl<ObjSize> instance;
//
//(note that this is the declaration in the class, not the definition)
//
//To:
//
//static detail::stack_allocator_impl<ObjSize>& instance() {
// static detail::stack_allocator_impl<ObjSize> theinstance;
// return theinstance;
//}
//
//Then delete the definition I had previously, and change all occurences
//of stack_allocator<xxx>::instance to stack_allocator<xxx>::instance().
//
//Unfortunately this performs substantially worse than the original
//solution (at least on my system - gcc/Linux).
Meyer's singleton works fine on Boraland, thanks.
The performance drop you cite must be because of the function call
which is forced because static variables can't exist in inline functions.
But pop and push are already function calls anyway.
Just for your information, the error messages with the original code were
"pop is not a member function of detail::stack_allocation_impl"
"push is not a member function of detail::stack_allocation_impl"
Question: Allocators are supposed to be pure.
If they reference a class static variable, are they really pure,
or are they bending the rules?
Craig Hicks
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk