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.
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.]" which leaves the door open to adjust the value up or down for specific platforms in the future. Do you know, by chance, how to determine the
(default?) stack size on Windows (7, specifically)?
I'm sorry I don't know. It should be the stack size the Windows applications take by average? Maybe 256kB might be OK.
I'll look into it a little bit and see if I can figure anything out. - Jeff