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

Subject: Re: [boost] [context] mini-review comments
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-01-14 15:58:27

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.

 > 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