220 4759 article Path: news.gmane.org!not-for-mail From: Nikolay Ivchenkov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Implementability of std::optional Date: Fri, 31 May 2013 05:48:11 -0700 (PDT) Lines: 364 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_41_24142763.1370004491584" X-Trace: ger.gmane.org 1370004494 2756 80.91.229.3 (31 May 2013 12:48:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 May 2013 12:48:14 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDJK3XNWR4LRBDNYUKGQKGQEMWWNMWQ@isocpp.org Fri May 31 14:48:16 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vb0-f70.google.com ([209.85.212.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UiOkg-0006NZ-QO for gclcip-std-proposals@m.gmane.org; Fri, 31 May 2013 14:48:15 +0200 Original-Received: by mail-vb0-f70.google.com with SMTP id f13sf1747062vbg.5 for ; Fri, 31 May 2013 05:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-google-group-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=c6ILUt2VN3XFtKPEdgbemxOwwinRAzdgNCsvh2xRge0=; b=Qvj5r7Z0QVjrCiMk5ZDIruPt9lcaf4KKz739JAF1dVRsx0bJCQRtq+gK9xoBvcDwYf Qqxfb9lHJTeCtMB5YiC9eoNltH8W3Hl3pPkpPWCGFsQWHKqfKkCit+i8S0ybasMKHGIr /WYkjSgpQUGFbmNo5uCfqZO/f6vuucb7C8EuIyev95B9DB4CvKJGFBW346RgQiE3+jDR HjcIajGrD1qryyb0Bage+Ie8OM7bn1VnkbMFdY7FAPpdfANQDEF/x2aayVTLuUklS3qz qBO5YKh0iQjc8xU4Qycoeg1dGaAGkGBdUdPxSdYbfMYiA0tRzuwKC5XGfN7ucu23UyDQ KHiw== X-Received: by 10.236.15.34 with SMTP id e22mr6101980yhe.16.1370004493917; Fri, 31 May 2013 05:48:13 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.121.5 with SMTP id lg5ls888536qeb.21.gmail; Fri, 31 May 2013 05:48:12 -0700 (PDT) X-Received: by 10.49.71.135 with SMTP id v7mr934898qeu.22.1370004492656; Fri, 31 May 2013 05:48:12 -0700 (PDT) X-Original-Sender: mk.ivchenkov@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:4759 Archived-At: ------=_Part_41_24142763.1370004491584 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable [This thread is based on the recent discussion "Implementation of=20 assignment in std::optional and Core issue 1404: Object reallocation in=20 unions" on SG12 reflector (about undefined/unspecified behavior)]. ---------------------------------------------------------------------- The following concerns are related to the suggested implementation of=20 optional - see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html https://github.com/akrzemi1/Optional/blob/master/optional.hpp Consider the following example: #include "optional.hpp" #include struct A { constexpr A(int &x) : ref(x) {} int &ref; }; int main() { int n1 =3D 0, n2 =3D 0; std::experimental::optional opt =3D A(n1); opt.emplace(n2); opt->ref =3D 1; std::cout << n1 << " " << n2 << std::endl; } Here initialization of variable opt implies initialization of union member= =20 storage_.value_ (which has type A). Then expression opt.emplace(n2)destroys= object=20 storage_.value_ via explicit destructor call and creates new object by=20 placement form of new-expression (using forwarded n2 in the=20 new-initializer). All public functions that provide access to the stored=20 value (operator->(), operator *(), value(), etc.), obtain pointer/reference= =20 through object expression storage_.value_. This is a simplified version of the above code: #include #define FORWARD(x) static_cast(x) template union U { constexpr U(T &&x) : value_(FORWARD(x)) {} unsigned char dummy_; T value_; }; template struct optional { constexpr optional(T &&x) : storage_(FORWARD(x)) {} template void emplace(Params &&... params) { storage_.value_.~T(); new (&storage_.value_) T(FORWARD(params)...); } U storage_; }; struct A { constexpr A(int &x) : ref(x) {} int &ref; }; int main() { int n1 =3D 0, n2 =3D 0; optional opt2 =3D A(n1); opt2.emplace(n2); opt2.storage_.value_.ref =3D 1; std::cout << n1 << " " << n2 << std::endl; } The question is: What may happen at line opt->ref =3D 1; in the former code or opt2.storage_.value_.ref =3D 1; in the latter (simplified) code? According to N3485 - 3.8/7, If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied, a pointer that pointed to the original object, a reference that referred to the original object, or the name of the original object will automatically refer to the new object and, once the lifetime of the new object has started, can be used to manipulate the new object, if: [...] =97 the type of the original object is not const-qualified, and, if a class type, does not contain any non-static data member whose type is const-qualified or a reference type, and [...] In our case the cited condition is not satisfied, because A has a=20 non-static data member of a reference type =97 ref. I presume that the intention behind 3.8/7 was to allow optimizations=20 described below: #include struct X { int &ref; }; void f(X &); int main() { int n =3D 0; X x{n}; f(x); x.ref =3D 5; std::cout << n << std::endl; } Here a compiler is allowed to assume that x.ref =3D 5; is equivalent to n =3D 5; and therefore std::cout << n << std::endl; is equivalent to std::cout << 5 << std::endl; regardless of the definition of f (which may be unknown for compiler).=20 There is no legal way to modify reference x.ref after its initialization so= =20 that it would refer to a different location. Even if we overwrite the=20 storage of x by construction of a new object of type X at address &x (our= =20 mysterious f could do such thing), a compiler may assume that reference=20 x.ref is untouched. The same applies to the original example with optional: it looks like a=20 compiler is free to assume that opt->ref or opt2.storage_.value_.ref still= =20 refers to n1 (as if the accessed ref would be member of the old object)=20 rather than n2 (to which new ref is supposed to refer). Such a behavior may= =20 be unexpected for some programmers. There are several ways to handle the issue. It's possible to: 1) reflect the limitations of the suggested implementation in the=20 specification of std::optional; 2) find a reliable portable (and potentially less effective) implementation= =20 without limitations regarding to members of reference/const-qualified types= ; 3) acknowledge that an effective implementation of std::optional should=20 rely on some compiler-specific behavior in order to avoid troubles with=20 members of reference/const-qualified types; 4) make two templates: std::optional (which can use std::aligned_storage)= =20 with normal support of assignment but without support of constexpr=20 semantics, and std::literal_optional (which can use unions in order to=20 implement constexpr semantics); 5) introduce special rules for union members in order to make such tricks= =20 with unions well-defined; 6) reconsider the existing core rules in 3.8/7 more widely (not only with= =20 regard to unions). There may be other options. Which direction is the most preferable? --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/?hl=3Den. ------=_Part_41_24142763.1370004491584 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable [This thread is based on the recent discussion "Implementation of assignmen= t in std::optional and Core issue 1404: Object reallocation in unions" on S= G12 reflector (about undefined/unspecified behavior)].

-------------= ---------------------------------------------------------

The follow= ing concerns are related to the suggested implementation of optional - see<= br>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html
ht= tps://github.com/akrzemi1/Optional/blob/master/optional.hpp

Consider= the following example:

    #include "optional.hpp"
    #i= nclude <iostream>

    struct A
  &= nbsp; {
        constexpr A(int &= x) : ref(x) {}
        int &ref;<= br>    };

    int main()
 &nbs= p;  {
        int n1 =3D 0, n2 = =3D 0;
        std::experimental::opt= ional<A> opt =3D A(n1);
       = opt.emplace(n2);
        opt->ref= =3D 1;
        std::cout << n1= << " " << n2 << std::endl;
    }

Here initialization of variable opt implies initialization of unio= n member storage_.value= _ (which has type A). Then expression opt.emplace(n2) destroys object storage_.value_ via explicit d= estructor call and creates new object by placement form of new-expression (= using forwarded n2 in the new-initializer). All public functions that provi= de access to the stored value (operator->(), operator *(), value(), etc.= ), obtain pointer/reference through object expression storage_.value_.

This is a sim= plified version of the above code:

    #include <iostream>

&nbs= p;   #define FORWARD(x) static_cast<decltype(x) &&>= (x)

    template <class T>
   = ;     union U
    {
  &n= bsp;     constexpr U(T &&x) : value_(FORWARD(x)= ) {}
        unsigned char dummy_;        T value_;
   = };

    template <class T>
   = ;     struct optional
    {
 =        constexpr optional(T &&x) : st= orage_(FORWARD(x)) {}
        templat= e <class... Params>
       &nbs= p;    void emplace(Params &&... params)
 &nb= sp;      {
      =       storage_.value_.~T();
   &= nbsp;        new (&storage_.value_) = T(FORWARD(params)...);
        }
<= br>        U<T> storage_;
 = ;   };

    struct A
    {=
        constexpr A(int &x) : re= f(x) {}
        int &ref;
&nbs= p;   };

    int main()
   = ; {
        int n1 =3D 0, n2 =3D 0;        optional<A> opt2 =3D A(n= 1);
        opt2.emplace(n2);
&nbs= p;       opt2.storage_.value_.ref =3D 1;
&= nbsp;       std::cout << n1 << " = " << n2 << std::endl;
    }

The= question is: What may happen at line

    opt->ref =3D 1;

i= n the former code or

    opt2.storage_.value_.ref =3D 1;

in th= e latter (simplified) code?

According to N3485 - 3.8/7,

 = ;   If, after the lifetime of an object has ended and before the<= br>    storage which the object occupied is reused or releas= ed, a new
    object is created at the storage location w= hich the original
    object occupied, a pointer that poi= nted to the original object, a
    reference that referre= d to the original object, or the name of the
    original= object will automatically refer to the new object and,
  &nbs= p; once the lifetime of the new object has started, can be used to
 = ;   manipulate the new object, if:

    [...= ]
    =97 the type of the original object is not const-qu= alified, and, if
      a class type, does not c= ontain any non-static data member whose
      t= ype is const-qualified or a reference type, and
    [...]=

In our case the cited condition is not satisfied, because A has a n= on-static data member of a reference type =97 ref.

I presume that th= e intention behind 3.8/7 was to allow optimizations described below:
    #in= clude <iostream>

    struct X
  &n= bsp; {
        int &ref;
 = ;   };

    void f(X &);

 &n= bsp;  int main()
    {
    &n= bsp;   int n =3D 0;
       = X x{n};
        f(x);
  = ;      x.ref =3D 5;
    &nb= sp;   std::cout << n << std::endl;
  &nb= sp; }

Here a compiler is allowed to assume that

    x.ref =3D = 5;

is equivalent to

    n =3D 5;

and therefore
   = ; std::cout << n << std::endl;

is equivalent to
   = ; std::cout << 5 << std::endl;

regardless of the = definition of f (which may be unknown for compiler). There is no legal way = to modify reference x.r= ef after its initialization so that it would refer to a different lo= cation. Even if we overwrite the storage of x by construction of a new obje= ct of type X at address &x (our mysterious f could do such thing), a co= mpiler may assume that reference x.ref is untouched.

The same applies to the origina= l example with optional: it looks like a compiler is free to assume that opt->ref or opt2.storage_.value_.ref still refers to n1 (as if the accessed ref would be member of the old object) rather = than n2 (to which new r= ef is supposed to refer). Such a behavior may be unexpected for some= programmers.

There are several ways to handle the issue. It's possi= ble to:

1) reflect the limitations of the suggested implementation i= n the specification of std::optional;

2) find a reliable portable (a= nd potentially less effective) implementation without limitations regarding= to members of reference/const-qualified types;

3) acknowledge that = an effective implementation of std::optional should rely on some compiler-s= pecific behavior in order to avoid troubles with members of reference/const= -qualified types;

4) make two templates: std::optional (which can us= e std::aligned_storage) with normal support of assignment but without suppo= rt of constexpr semantics, and std::literal_optional (which can use unions = in order to implement constexpr semantics);

5) introduce special rul= es for union members in order to make such tricks with unions well-defined;=

6) reconsider the existing core rules in 3.8/7 more widely (not onl= y with regard to unions).

There may be other options. Which directio= n is the most preferable?

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-pro= posals/?hl=3Den.
 
 
------=_Part_41_24142763.1370004491584-- .