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

Subject: Re: [boost] [Fit] formal review starts today
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-03-04 19:09:09

On Friday, March 4, 2016 at 5:09:19 PM UTC-6, Steven Watanabe wrote:
>
> 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? 
>

`always_ref` is used a lot throughout the library. For users of the 
library, it
may not be used as often. Perhaps it would be better to leave it out for 
now,
and then I can added it later, if there is need for this in other libraries 
or
applications.
 

>
> >>> 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 
>
>
> _______________________________________________ 
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost 
>