Re: [boost] [context] mini-review comments

Subject: Re: [boost] [context] mini-review comments
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-01-14 16:16:15

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_at_[hidden]>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