220 13941 <27e2ae9c-8b1f-4688-9bb3-9caef6bf4f54@isocpp.org> article Path: news.gmane.org!not-for-mail From: Myriachan Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Reconstruct function idea Date: Wed, 15 Oct 2014 15:22:53 -0700 (PDT) Lines: 174 Approved: news@gmane.org Message-ID: <27e2ae9c-8b1f-4688-9bb3-9caef6bf4f54@isocpp.org> References: <8a74f08b-7453-4d1a-9f20-bc1d3866617c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5730_1346458005.1413411773510" X-Trace: ger.gmane.org 1413411783 27383 80.91.229.3 (15 Oct 2014 22:23:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Oct 2014 22:23:03 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDKLT4PURQHRBPXH7OQQKGQEU6MANCY@isocpp.org Thu Oct 16 00:22:57 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XeWy8-0005np-93 for gclcip-std-proposals@m.gmane.org; Thu, 16 Oct 2014 00:22:56 +0200 Original-Received: by mail-ie0-f197.google.com with SMTP id rp18sf8940831iec.0 for ; Wed, 15 Oct 2014 15:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=zVSn4HiVdWM/fayAxWxxfV3b5BYJe9n6LtPVG2kGqtU=; b=pDWU35fzUryvZZo+9UE5spc22FubWwW1ey+H6Dw5oc/rTfeecARVFFBf32TMlbbeLh 7cgTRXzQ671WUqPtFKX7TjS7Y1SIS3GLIGZT+2ByLQCHq5kx6gQcZx21DnpgIw+6PEJu wOLt45BRVKIneatVHn3+UAC/Yj3fzfs5i/Oq4a/ixRF4cOXMoP3HvKNsY/IXYSCTABYb sVYccaSwTfMO4vb0Mk+5uYapPgFQnc8OH9HDc/DoEdrtaaJUhb3f6rbJVbiTduiGYoCw iecyVV+XzGqCMbZfmCgXIusvytf4K23/WKSjSRh/C75ePmNAfI0qn1ymnnvybyk5eRmA t4TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=zVSn4HiVdWM/fayAxWxxfV3b5BYJe9n6LtPVG2kGqtU=; b=McSH6UdYhKJ5fgCrIQR9wnpRlSfzwfkOzYlr/dVTZd3mVRlTEYhY6iW3LIEny8QdOH 2PivK9MEFIIfEcDtUsz2boPQoz5wbrMF19gJ4UNt3SE7hKdNNrggFKnV9KGr0qpjNlT6 ecrL2jNSsjkI713lQwk8589gQItpFu5NViiEBTEXQszxr4qC3YZH6xAKvmz9LcEAzeOt CfDZQ/HsNb7VCBIgiywgSwClKWcnKnWbid2lJFbFbobcVIRcucNWc5/8D4EXmZCCl/r0 nHPYWqg9V+ZQo2ca4N679OuPm2aBRTzOtG7IHKkOh8J8obTiGvjwT245WHeGeUidm8DV IVaA== X-Gm-Message-State: ALoCoQlFSnWF/Xa55JvviobeUg75exYmVt2F2QgTHZ4Z4K0jiL6u9IIiEOj/V7UDnr8LleQ34qmx X-Received: by 10.50.51.34 with SMTP id h2mr615317igo.5.1413411775365; Wed, 15 Oct 2014 15:22:55 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.161.212 with SMTP id k203ls382221ioe.24.gmail; Wed, 15 Oct 2014 15:22:54 -0700 (PDT) X-Received: by 10.50.20.198 with SMTP id p6mr263210ige.10.1413411774866; Wed, 15 Oct 2014 15:22:54 -0700 (PDT) In-Reply-To: X-Original-Sender: myriachan@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:13941 Archived-At: ------=_Part_5730_1346458005.1413411773510 Content-Type: text/plain; charset=UTF-8 On Wednesday, October 15, 2014 3:02:28 PM UTC-7, Ville Voutilainen wrote: > > On 16 October 2014 00:17, Myriachan > > wrote: > >> It's called std::experimental::optional. > > While that is a nice feature, it's not the same as needing to do this to > > types that weren't created as std::optional. > > > Some questions: > > 1) if you can refactor code to take into use this reconstruction > function, do you > think you can't change the same code to start using optional? If so, why? > > The main reason to use something like this is for copy constructors. Sometimes, the most convenient way to implement a copy or move constructor is like this: T &T::operator =(const T ©) { if (© != this) { this->~T(); new(this) T(copy); } return *this; } ....and equivalently with std::forward for move constructors. 2) do you think this function is important and common enough to standardize > it, > and if so, based on what(*)? > > (*) I'm looking for more than anecdotes here, because if you say "I use > such > a thing every day", I will respond "whereas I never use such things, > so let's call > it a push". ;) > After thinking more deeply about the exception implications, prompted by Nevin's reply, I can see how this is quite dangerous, since there's no way to stop a local destructor from executing. I just saw it as shorthand for what people do already. Melissa -- --- 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 email 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-proposals/. ------=_Part_5730_1346458005.1413411773510 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, October 15, 2014 3:02:28 PM UTC-7, Ville Vou= tilainen wrote:
On 16 October 2= 014 00:17, Myriachan <myri...@gmail= ..com> wrote:
>> It's called std::experimental::optional.
> While that is a nice feature, it's not the same as needing to do t= his to
> types that weren't created as std::optional<T>.


Some questions:

1) if you can refactor code to take into use this reconstruction
function, do you
think you can't change the same code to start using optional? If so, wh= y?


The main reason to use something like this is for= copy constructors.  Sometimes, the most convenient way to implement a= copy or move constructor is like this:

T &T::operator =3D(= const T &copy)
{
    if (&copy = !=3D this)
    {
      &nb= sp; this->~T();
        = new= (this) T(copy);
    }
    return *this<= span style=3D"color: #660;" class=3D"styled-by-prettify">;
}

...and e= quivalently with std::forward for move constructors.


2) do you think this function is im= portant and common enough to standardize it,
and if so, based on what(*)?

(*) I'm looking for more than anecdotes here, because if you say "I use= such
a thing every day", I will respond "whereas I never use such things,
so let's call
it a push". ;)

After thinking more deeply about the exception im= plications, prompted by Nevin's reply, I can see how this is quite dangerou= s, since there's no way to stop a local destructor from executing.  I = just saw it as shorthand for what people do already.

Melissa

--

---
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-proposa= ls+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-proposals/<= /a>.
------=_Part_5730_1346458005.1413411773510-- .