220 35832 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Output parameters Date: Sat, 9 Dec 2017 22:12:18 +0000 Lines: 86 Approved: news@gmane.org Message-ID: References: <1c1bb50b-2d59-4247-a158-158065fb1a9a@isocpp.org> <0c471d5c-b9b2-40f9-a2bf-908edbb1f272@isocpp.org> <17e3b13c-eb1b-fc2c-590e-3d394f164f9a@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11495e18300997055fef98a9" X-Trace: blaine.gmane.org 1512857539 2661 195.159.176.226 (9 Dec 2017 22:12:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 9 Dec 2017 22:12:19 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBQ57WHIQKGQEOBHZ3UQ@isocpp.org Sat Dec 09 23:12:15 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f72.google.com ([209.85.218.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNnLx-0000XQ-Ao for gclcip-std-proposals@m.gmane.org; Sat, 09 Dec 2017 23:12:13 +0100 Original-Received: by mail-oi0-f72.google.com with SMTP id u126sf6400643oif.23 for ; Sat, 09 Dec 2017 14:12:20 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1512857540; cv=pass; d=google.com; s=arc-20160816; b=rIq24FAfocb6esMXK4thydpKJXHLX2GNbnyDeR9fEaNWFc68PBuruUmgLLQZz4JOtR bcGVhu1GsxG0mXtE8uqhlFVgvvwbsY4z9yTMy+bcm73PPZd+lH1oN+N9LWMm5id5yie2 nZpuKJcmBXpkqn3Xyi8am8j/0OE2PqUCf3jwspWNdP7mTSlALTnaEBJyIPlSsmBbnWQI la1N6EWt9P580Du8RDRhxywZxd3nH4dslnN9bRMqGwXZa0fW17LNfDKfBrsBSjhinAHF 2rtkOhJCZ0aMFdzSj384u+Zda2BWDZ4H+BLKYBRHD/7ETzbdYnmNkiUPm7Dal4+R4Te8 I4+Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=udkOUr3xBE9fkklchhpqXagRVhDExZl6SsBFcUqHZGs=; b=EXLpgfIARgSfgWCvnvmZ1R7/Cz9UBoVnHJtER0CxXkhMonXLTcPUKGoQs6q8pRycYz Z7svAQaicOhsD0kqQR00wYWRxCx5oL0wAR8gXYgZkPwCGR33BeP7Kguzno3mNNDgCfDf 87Ux2GQ8XmoZ3iTUbjHjahHvNO3d73msyO4ykUEne5k3eOkUHcENNy9RfWzb8Dzb02cS VaMVga+h0FzzystatSttVl4Bg1BxEB0br3lgehlNbxDowdB1EnBWoXDbdHKT6iT4Y5xx CuXUudbzeYWS/qn+RKFg4rEcpVdP3COxeS8OfBACE7WOtlut3PmyrqHnnnoaCA3v6fbU Ctxg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Rq7d9Trt; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=udkOUr3xBE9fkklchhpqXagRVhDExZl6SsBFcUqHZGs=; b=u190Iqr3MwQ7SmcidLxzPnEBv9a7ZvPzeKjO42UVlv8AqtxBc0y4ku66X4egj6E4jp /s9HmzKQjn0oqUoN21g2n29CtiaFnGWzw/VexHr8Su7DFHi2Te2xndm30vaUM2dlijVg 7QRdreRo8POhHv0c+Brm1FiKtHZFly9rliic2TV0Hg5fHMB016oiXcaro7q/9e2g4gk7 TSz++HvGJUyEM+Z4tvcL8aMZoKYzzK0zMmT1zan5UID5N1ZfOvbn7z3bJoX5+aGCVjjp XKW8JUPVshoGyHbBNsRDpqc7vRNJMTtEyh/ODl/nRJyEY6wuBBJIat8LXYReBUOoJH4q Zsvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=udkOUr3xBE9fkklchhpqXagRVhDExZl6SsBFcUqHZGs=; b=UEb/kP5ftu9RIJ7kWrdwGTUosO9FSiyOyBH5jh8rS6Hs/iHVnUl4iDlNZAsInQxXHe DJg5bhVl4k/gKytVraRoQMmMF6dU5MMo3POfWjVAkQDv+kUp5rtc/0h0dv+1iV/63luj YxBFTHRiktysBFyWnqG9TQao85gakVIjnZXOqOnb6ErigmFgf8Wwt4bpmCaT4nOd5S6h FErlSgjDyY3YVlujvKB9eM52eHHRGXrm2a2EPqAeDLRUlbz4gA8cIp/lpYckByF7LZAk h/lZGMMAkV/DBXSy3K2enHibJvH1ObZk18+lEiDOzZl2MFb5CSeal+6iaQT/LLDT960a Ohlg== X-Gm-Message-State: AJaThX5neV1Fmk8ujI9RF0cuQmeJyGT3ADsqnCV0XWHJlxFAzVyqww6l wwvVcRm7kBBFiCok/Tj1faFi7w== X-Google-Smtp-Source: AGs4zMatbOqnK74twWvZYOjXnwqmn6+WH1fiJlDViUYcRB3Mqz6KcZxepaVUoBTDA5MBGqR7JnimLQ== X-Received: by 10.157.47.216 with SMTP id b24mr19821756otd.106.1512857540296; Sat, 09 Dec 2017 14:12:20 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.41.138 with SMTP id n10ls24905otb.5.gmail; Sat, 09 Dec 2017 14:12:19 -0800 (PST) X-Received: by 10.157.27.209 with SMTP id v17mr28880595otv.92.1512857539169; Sat, 09 Dec 2017 14:12:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512857539; cv=none; d=google.com; s=arc-20160816; b=r3TfIWjgMrax7Q2OOiKAX7fXksUUuqnhD0MkJe8qpfIKfRydKjTYpy8edOxyCn9UmU R0gC3fIDBdUO+SCQkPOJ7p55rvStQOJBmKLWzVDX4DbVXqn8c2SbcPmt065uFPyQcVL0 E0iCQmufXf/kSia+eUxc8jKexz/DzPPnVcFW5V85+Iw/ws/i3ZzuLsfpQJC+zo2WoldG PTfkLx7bCG+lthMJHcSj0IBb2CUPOcwHOLV2qK7UH5NUA4HoN5iH+L7ncqHJUrSU4qqU 37d5fLQrhNt6x8zLrVEVmKx7lVSW82jzoPuVO/ufg3KKuiqHUAUAjebEdcAYztCbMerB cdoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=rcRYja2S9e1kg/6jd0244RpCtdyXQenO2TQqt0gz1BI=; b=qcnK2t9ZhqINoHZl/Usj6KHz1UbEcGkv9A4/7NYc7uGgCbwOwuUDg/0fYmK+do4SBD Onv0fIeSQLYeHYTjeaKi7orulBXuDFuQ2rTcQeJB1DR04FadMB1+sBJAfPb/I9sbQdfc +17bZV8PHv7KQdL2JPn6AEh+WVNikLhLA1QXR2c5RFla2cnZ6jCKHLSC6AemX3GGg59t SEZOuirPAyhy6R7CD8WajetOqzOYs4+uxFZ4iKeKKSWkTv+PoehKbbBkrCbk+N7XAg6v p/v7hPeQxyAdOCw0AmnCPWZf2/jg/LIqndhuP1BNiY6JSHteNxB/sOa0F2Rs161WU0/K jUzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Rq7d9Trt; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id 89sor3875758ott.165.2017.12.09.14.12.19 for (Google Transport Security); Sat, 09 Dec 2017 14:12:19 -0800 (PST) Received-SPF: pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.157.52.142 with SMTP id g14mr32504697otc.346.1512857538659; Sat, 09 Dec 2017 14:12:18 -0800 (PST) Original-Received: by 10.168.69.140 with HTTP; Sat, 9 Dec 2017 14:12:18 -0800 (PST) Original-Received: by 10.168.69.140 with HTTP; Sat, 9 Dec 2017 14:12:18 -0800 (PST) In-Reply-To: X-Original-Sender: jake.arkinstall@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Rq7d9Trt; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:35832 Archived-At: --001a11495e18300997055fef98a9 Content-Type: text/plain; charset="UTF-8" On 9 Dec 2017 21:38, wrote: For case #2, Since the three results aren't really related, it feels clumsy to have a separate struct which is used only in one function. It seems, to me, to be perfectly reasonable to have a dedicated struct for this specific situation. Although the individual parameters are essentially independent, they do have quite a lot of meaning as a collective (which pretty much sums up the point of a struct, to me at least). I don't know. Maybe I'm too liberal with structs and classes. But I rarely come across a legitimate time when a return type only occurs once - especially when the project matures somewhat and it turns out there is a lot more you want to do with the result than you originally anticipated. Returning a custom object also gives you a lot more flexibility during refactoring, too, especially if it has a decent amount of encapsulation. However, now I'm going quite off topic, because it is all to do with personal coding preferences. I cannot deny that there are attractive benefits to using out parameters, particularly if you have sufficient reason to only ever calculate a small number of fixed results and sufficient need to have control over their scope. If one result takes up a large amount of RAM, for example, you might have great reasons to have it disposed of as soon as possible, even if other return values are needed later on. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMHGJFH1EreRWoKG-CmCThUaAQKbASQtVKZC8859hPEEA%40mail.gmail.com. --001a11495e18300997055fef98a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 9 Dec 2017 21:38, <odomobo@gmail.com> wrote:
For case #2, Since the three results aren't really related, it fee= ls clumsy to have a separate struct which is used only in one function.

It seems, to me, to be perfectly reasonable to have a dedicated struct= for this specific situation. Although the individual parameters are essent= ially independent, they do have quite a lot of meaning as a collective (whi= ch pretty much sums up the point of a struct, to me at least).

I don't know. Maybe I'm too = liberal with structs and classes. But I rarely come across a legitimate tim= e when a return type only occurs once - especially when the project matures= somewhat and it turns out there is a lot more you want to do with the resu= lt than you originally anticipated. Returning a custom object also gives yo= u a lot more flexibility during refactoring, too, especially if it has a de= cent amount of encapsulation.

However, now I'm going quite off topic, because it is all to do w= ith personal coding preferences. I cannot deny that there are attractive be= nefits to using out parameters, particularly if you have sufficient reason = to only ever calculate a small number of fixed results and sufficient need = to have control over their scope. If one result takes up a large amount of = RAM, for example, you might have great reasons to have it disposed of as so= on as possible, even if other return values are needed later on.

--
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.
To view this discussion on the web visit h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMHGJFH= 1EreRWoKG-CmCThUaAQKbASQtVKZC8859hPEEA%40mail.gmail.com.
--001a11495e18300997055fef98a9-- .