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