Why is the construction of std::optional more expensive than a std::pair?

后端 未结 4 625
死守一世寂寞
死守一世寂寞 2020-12-08 09:07

Consider these two approaches that can represent an \"optional int\":

using std_optional_int = std::optional;
using my_optional_int =         


        
4条回答
  •  感动是毒
    2020-12-08 09:50

    The optimization is technically permitted, even with std::is_trivially_copyable_v> being false. However, it may require an unreasonable degree of "cleverness" for the compiler to find. Also, for the specific case of using std::optional as the return type of a function, the optimization may need to be done at link-time rather than compile-time.

    Performing this optimization would have no effect on any (well-defined) program's observable behavior,* and is therefore implicitly allowed under the as-if rule. However, for reasons which are explained in other answers, the compiler has not been explicitly made aware of that fact and would need to infer it from scratch. Behavioral static analysis is inherently difficult, so the compiler may not be able to prove that this optimization is safe under all circumstances.

    Assuming the compiler can find this optimization, it would then need to alter this function's calling convention (i.e. change how the function returns a given value), which normally needs to be done at link time because the calling convention affects all of the call sites. Alternatively, the compiler could inline the function entirely, which may or may not be possible to do at compile time. These steps would not be necessary with a trivially-copyable object, so in this sense the standard does inhibit and complicate the optimization.

    std::is_trivially_copyable_v> ought to be true. If it were true, it would be much easier for compilers to discover and perform this optimization. So, to answer your question:

    Is this a QoI issue, or is there something in std::optional's specification preventing this optimization?

    It's both. The spec makes the optimization substantially harder to find, and the implementation is not "smart" enough to find it under those constraints.


    * Assuming you haven't done something really weird, like #define int something_else.

提交回复
热议问题