220 5229 <20f56505-2fba-4041-9d81-26088e67dc5d@isocpp.org> article Path: news.gmane.org!not-for-mail From: Jonathan Wakely Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Teachability problems with std::move Date: Wed, 26 Jun 2013 02:18:24 -0700 (PDT) Lines: 95 Approved: news@gmane.org Message-ID: <20f56505-2fba-4041-9d81-26088e67dc5d@isocpp.org> References: <73cad38f-c1b6-4ce3-bfc1-e4a660dbb638@isocpp.org> <09ec0612-ac10-48fb-a186-bd3c200bd5fe@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_307_31275737.1372238304414" X-Trace: ger.gmane.org 1372238307 8554 80.91.229.3 (26 Jun 2013 09:18:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Jun 2013 09:18:27 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCMONUNYS4IRBYPDVKHAKGQEG4UCJ6I@isocpp.org Wed Jun 26 11:18:28 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f200.google.com ([209.85.216.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Urlrv-0003wa-Gi for gclcip-std-proposals@m.gmane.org; Wed, 26 Jun 2013 11:18:27 +0200 Original-Received: by mail-qc0-f200.google.com with SMTP id n1sf18238048qcx.11 for ; Wed, 26 Jun 2013 02:18:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-beenthere:date:from:to:message-id:in-reply-to:references: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=1VzU+uNR+hT1GIG66cMEHaF0NVj6lC+lEea0+NAL+Zk=; b=NN3nJIIWh3ArMLrikJDRFi1mxH49XI+7nbv7fqsbpEhjekmHNVquhBjfu/pyg7mHQr /GvCniMpujbOIUl55TPjQhqBiq/LdNNT/h6RIREhJHrPodCwZ4/DJybaDx3k/P6mJqD6 7eg+txzxvLTc7Y0iLPgaJUgRHmTpbNxFMp/URH8QWoPYdj3bqXPVKy9qX2VxyK5DqhmG Z0YSRvqKLwTpJnaZHI8rsXS1H2BFZvKCI8Zht0iMOGhtJ+MHe4gpbuqpo7FtuNLq26+N EJnPLT941DS7bSO5887cx2TyFCV/Ylt3ogtGDlX8TfNUY5/Xm0zz7riuP5qpBFgCydKy m7WA== X-Received: by 10.224.29.76 with SMTP id p12mr2311694qac.5.1372238306609; Wed, 26 Jun 2013 02:18:26 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.122.6 with SMTP id lo6ls323257qeb.63.gmail; Wed, 26 Jun 2013 02:18:25 -0700 (PDT) X-Received: by 10.49.47.10 with SMTP id z10mr74971qem.7.1372238305406; Wed, 26 Jun 2013 02:18:25 -0700 (PDT) In-Reply-To: <09ec0612-ac10-48fb-a186-bd3c200bd5fe@isocpp.org> X-Original-Sender: cxx@kayari.org 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:5229 Archived-At: ------=_Part_307_31275737.1372238304414 Content-Type: text/plain; charset=ISO-8859-1 On Tuesday, June 25, 2013 7:46:25 PM UTC+1, Mikhail Semenov wrote: > > If you really need to convert, I suggest make it explicit: > > *std::unique_ptr FooFactory() {* > * std::unique_ptr result(new Foo);* > *ahem* std::make_unique ;-) * // ...* > * return std::unique_ptr(std::move(result));* > *}* > ** > It would be clear what you are doing. > It would be clear anyway with Geoffrey's suggestion, returning a unique_ptr of one type and having it convert to the return type. If I didn't want the return type to differ from the declared type I'd have used return type deduction anyway, right? > By the way, where I work we always write explicit casts. > That's your prerogative, but doesn't mean it is the only way or that everyone else should have to do it that way. Coming back to the original topic, are you really suggesting the code above is the ideal form for teaching when to use std::move and when not to? I think "return result;" is much simpler. -- --- 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_307_31275737.1372238304414 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tuesday, June 25, 2013 7:46:25 PM UTC+1, Mikhail Semenov wrote:<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">
If you really need to= convert, I suggest make it explicit:
 
std::un= ique_ptr<const Foo> FooFactory() {
  std::uniqu= e_ptr<Foo> result(new Foo);

*ahe= m* std::make_unique   ;-)

  // ...
  retur= n std::unique_ptr<const Foo>(std::move(result));
}
 
It would be clear what you are d= oing.

It would be clear anyway with Geoffrey's s= uggestion, returning a unique_ptr of one type and having it convert to the = return type.

If I didn't want the return type to differ from the dec= lared type I'd have used return type deduction anyway, right?
 
=
By the way, where I= work we always write explicit casts.

That's you= r prerogative, but doesn't mean it is the only way or that everyone else sh= ould have to do it that way.

Coming back to the original topic, are = you really suggesting the code above is the ideal form for teaching when to= use std::move and when not to?  I think "return result;" is much simp= ler.

--
 
---
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-proposals/<= /a>.
 
 
------=_Part_307_31275737.1372238304414-- .