on Sat Jan 14 2012, "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung-AT-gmail.com> wrote:
On Sat, Jan 14, 2012 at 12:38 AM, Oliver Kowalke <oliver.kowalke@gmx.de>wrote:
Hi Jeff,
Am 13.01.2012 23:22, schrieb Jeffrey Lee Hellrung, Jr.:
Hmmm...I would consider that an oversight. Any operation (like calling operator new) which changes global state should be documented as such. With operator new, you're (likely) changing the amount of free store space, there's possibly the acquisition of locks (depending on implementation), and, I don't know, maybe some other effects observable outside of the local context. If you put the pimpl in the stack space via the stack allocator, then that changes whatever state the stack allocator has outside of the constructor. Example: If I write a merge sort function that allocates extra temporary scratch space, I would consider the documentation incomplete if it didn't mention where that scratch space is retrieved from. [...]
Hmmm - I've some doubt to buy this. AFAIK the STL documentation does not define how vector, list etc. should be implemented - it is up to the implementor and how it is implemented may change between platforms/vendors.
std::vector, std::list, and all other STL containers take an Allocator template parameter which dictates how memory should be allocated for the container. The default value for this Allocator parameter is std::allocator, and std::allocator uses operator new.
OK, then, consider all the adaptive algorithms: http://www.sgi.com/tech/stl/stable_sort.html IMO it should be possible to make memory allocation, the use of a second thread (with blocking), temporary file creation, etc. implementation details. That said, it is also polite if a specific implementation gives some details about those details ;-).
I don't think it's a good idea to guarantee (as much as one is able
to,
anyway) a one-size-fits-all default stack size for all present and future platforms for all time and across all dimensions and parallel universes.
default_stacksize() was only introduced for more comfort for the lib users. I could also remove this function - but some user might ask what stacksize they should use.
I'm simply pointing out that the documented semantics of default_stacksize() strike me as over-specified ("256 kB", regardless of platform), and I was (implicitly) asking, e.g., if you had considered this. Based on your above comment, it appears I didn't make my point clear enough...
so you suggest to remove it? sorry - I don't get it.
I'm suggesting that you change the documentation to something like
"Returns a default stack size, in bytes, which may be platform specific. [Note: The present implementation returns a value of 256 * 1024.]"
+1 -- Dave Abrahams BoostPro Computing http://www.boostpro.com