Boost logo

Boost :

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


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at