Re: [boost] [Fit]Â formal review starts today

Subject: Re: [boost] [Fit] formal review starts today
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2016-03-04 18:09:02

AMDG

On 03/04/2016 10:37 AM, paul Fultz wrote:
>>> - Different functions in the library do not
>>>   have a consistent interface for similar
>>>   variations:
>>>   - always/always_ref vs. capture/capture_forward/capture_decay vs
>>> partial w/ std::ref.
> 
> `alway_ref should be just an implementation detail. The user can already write
> `always(std::ref(x)) if they want a reference. I only use this to try and save
> `some template instantiations when I need to the always_ref(*this)(xs...)
> `pattern.
> 

  If it's meant to be an implementation detail,
then it shouldn't be documented.  Also, how do
you know that this optimization makes any difference?
If it does make a difference, then wouldn't users
want to take advantage of it too?

>>> 145: // Since we disable the error for 4579 on MSVC, which leaves the
>> static
>>>     // member unitialized at runtime, it is, therefore, only safe to
>>> use this
>>>     // class on types that are empty with constructors that have no
>>> possible
>>>     // side effects.
>>>     Shouldn't it also be safe for types with trivial
>>>     default constructors, since then, zero-initialization
>>>     will do the right thing?
>>
> 
>> That is probably another case as well.
> 
> Sorry this is wrong. The value is uninitialized. So its only valid when there is
> no data members to initialize(ie is_empty<T>) and the constructors have no
> side effects(ie is_literal<T>). Since it is uninitialized you can't expect it
> be zero-initialized either.
> 

  Okay, I'm not familiar with this particular
compiler bug.  I was just making a wild guess
based on [basic.start.init]:
"Variables with static storage duration (3.7.1)
or thread storage duration (3.7.2) shall be
zero-initialized (8.5) before any other
initialization takes place."

In Christ,
Steven Watanabe