220 8927 article Path: news.gmane.org!not-for-mail From: Francisco Lopes Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Dnnnn - RAII classes... Date: Wed, 29 Jan 2014 16:41:25 -0200 Lines: 197 Approved: news@gmane.org Message-ID: References: <183CB42B-6923-44A7-917A-A57638EF62E2@hsr.ch> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c20364c9b7df04f1204922 X-Trace: ger.gmane.org 1391020890 15330 80.91.229.3 (29 Jan 2014 18:41:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Jan 2014 18:41:30 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDT3X37BUMLRBVUWUWLQKGQEI6U6V7Q@isocpp.org Wed Jan 29 19:41:35 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f200.google.com ([209.85.192.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W8a4n-0001K9-9l for gclcip-std-proposals@m.gmane.org; Wed, 29 Jan 2014 19:41:29 +0100 Original-Received: by mail-pd0-f200.google.com with SMTP id y10sf4539078pdj.3 for ; Wed, 29 Jan 2014 10:41:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from: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:content-type; bh=ceSpPy2KFvxmM/yNgE52AE9wQ7Nhmv44yq/6uYPS9Tw=; b=HwzMjCppUQKuuaoy8FoxQBiMlRjF+LmJcaDeIfoQuogn0ZNXXedssQbEcSy2ReLUYP n6F5zHilbZ0IGPwE/iywtPlECSpZQscTHXWPUmb2pxdlGtHnj4VwCus1QMyq9GsO2knq lYTWEKQgOBI6BAYnjuCkAP5ePqhm/U5NO1oQEgX93sXmLscwKVGvA7rk5llr0c/Ka/fg qYQQS1s1pq4DxE8G3/8KQP7o5AOsfb6qLJSjgmKnDQnksPon9FrhHIkD6F26RgIpJtMZ Ccd7HDdFF37XJ0mfCY6MS3FGhWeiCNFegpJam0rXEC/u2FYVDYwWFkobfObBRhNTX9CE BU2g== X-Gm-Message-State: ALoCoQnD7YOwspm7eURsOsR0EFNvLyidLGPCSwlPFnMHYTUFcGlMmYFYHiMLD5ETLPxQbxZelMaV X-Received: by 10.66.227.103 with SMTP id rz7mr3371768pac.37.1391020887919; Wed, 29 Jan 2014 10:41:27 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.239.133 with SMTP id vs5ls425202igc.18.gmail; Wed, 29 Jan 2014 10:41:26 -0800 (PST) X-Received: by 10.50.194.131 with SMTP id hw3mr10348889igc.4.1391020886619; Wed, 29 Jan 2014 10:41:26 -0800 (PST) Original-Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by mx.google.com with ESMTPS id k9si5451771igv.40.2014.01.29.10.41.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Jan 2014 10:41:26 -0800 (PST) Received-SPF: neutral (google.com: 209.85.223.181 is neither permitted nor denied by best guess record for domain of francisco.mailing.lists@oblita.com) client-ip=209.85.223.181; Original-Received: by mail-ie0-f181.google.com with SMTP id to1so2466047ieb.40 for ; Wed, 29 Jan 2014 10:41:26 -0800 (PST) X-Received: by 10.43.138.8 with SMTP id iq8mr7390370icc.37.1391020886040; Wed, 29 Jan 2014 10:41:26 -0800 (PST) Original-Received: by 10.64.166.197 with HTTP; Wed, 29 Jan 2014 10:41:25 -0800 (PST) In-Reply-To: X-Original-Sender: francisco.mailing.lists@oblita.com X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.223.181 is neither permitted nor denied by best guess record for domain of francisco.mailing.lists@oblita.com) smtp.mail=francisco.mailing.lists@oblita.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:8927 Archived-At: --001a11c20364c9b7df04f1204922 Content-Type: text/plain; charset=ISO-8859-1 2013-04-15 Andrew Sandoval > On Saturday, April 13, 2013 6:18:48 AM UTC-5, PeterSommerlad wrote: >> >> the loop advancement example is not very convincing because it can easily >> be dealt with by using for() instead of while() which is much simpler than >> the alternative you are proposing. >> >> I can remove that example if there is consensus. I find it a useful > method of preventing someone from producing a tight loop by accidentally > creating a path in the loop that skips the advancement. > > I also wonder if an local struct with a destructor and a corresponding >> variable wouldn't be simpler than the scoped example or alternatives like >> unique_ptr or shared_ptr or boost::scoped_ptr that already provide much of >> the functionality you are proposing. >> >> That horse has been beat to death already in the original thread on > this. The consensus was that these class are useful and serve a different > purpose than unique_ptr. You will find several that back your view point, > but there is no reason for us to revisit this point. I didn't put hundreds > of hours into the document after we'd already had that discussion, just to > fight that fight again now. Please feel free to look at the previous posts. > > >> The example given as Motivation B calls for a dedicated RAII class for >> CriticalSection IMHO, so again not very convincing. >> >> IMHO it would greatly improve your paper if you would provide additional >> examples showing the "uglyness" of using existing alternatives to your >> proposal, i.e., DIY local structs with destructors, or "misusing" >> unique_ptr/shared_ptr for that purpose, in contrast to scoped_function and >> scoped_resource. >> > > Okay, I can definitely consider that. Anyone concur? > I do, and I feel Peter was not trying to bringing up the previous noise again, but only, at the end, to make a point on what should be the focus. > >> Also providing the no-delete value is not very convincing. What if all >> values less than zero are "no-delete", or 7, 23 and 42? It complicates the >> class and API and doesn't serve a general purpose. Usually a predicate is >> used in other cases to provide a hook for bool checks. >> >> I disagree with that 100%. In most cases resources -- real resources > like file handles or descriptors, etc. are allocated and have either a 0 / > nullptr or a -1 value on failure Making the no-delete value simple saves a > lot of duplicate code. > Windows WaitForMultipleObjectsis an example of API that, may not completely fit scoped_resource scenery, but may give an idea of the problem. I too, have found that the current state fits a scenery that's not general enough, but may cover most cases in the wild... maybe, I can't be sure about that. > > >> Just my CHF0.02 from a quick scan. >> >> Peter. >> >> Thank you for your feedback. > Where is everyone else lately? Is this the week that the committee is in > meetings in Bristol? > -Andrew Sandoval > By the way, I'd like to have the newer reference implementations available in source code form (on github for example)... Regards, Francisco Lopes -- --- 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/. --001a11c20364c9b7df04f1204922 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2013-04-15 Andrew Sandoval <sandoval@netwaysgl= obal.com>
On Saturday, April 13, 2013 6:18:48 AM UTC-5, PeterSommer= lad wrote:
the loop advanc= ement example is not very convincing because it can easily be dealt with by= using for() instead of while() which is much simpler than the alternative = you are proposing.

I can remove that example if there is consensus= ..=A0 I find it a useful method of preventing someone from producing a tight= loop by accidentally creating a path in the loop that skips the advancemen= t.

I also wonder if an local struct with a destructor and a corresponding v= ariable wouldn't be simpler than the scoped example or alternatives lik= e unique_ptr or shared_ptr or boost::scoped_ptr that already provide much o= f the functionality you are proposing.

That horse has been beat to death already in th= e original thread on this.=A0 The consensus was that these class are useful= and serve a different purpose than unique_ptr.=A0 You will find several th= at back your view point, but there is no reason for us to revisit this poin= t.=A0 I didn't put hundreds of hours into the document after we'd a= lready had that discussion, just to fight that fight again now.=A0 Please f= eel free to look at the previous posts.
=A0
The example given as Motivation B calls for a dedicated RAII class fo= r CriticalSection IMHO, so again not very convincing.

IMHO it would greatly improve your paper if you would provide additiona= l examples showing the "uglyness" of using existing alternatives = to your proposal, i.e., DIY local structs with destructors, or "misusi= ng" unique_ptr/shared_ptr for that purpose, in contrast to scoped_func= tion and scoped_resource.
=A0
Okay, I can definitely consider t= hat.=A0 Anyone concur?

I do, and= I feel Peter was not trying to bringing up the previous noise again, but o= nly, at the end,
to make a point on what should be the focus.
=A0

Also providing the no-delete value is not very convincing. What if all = values less than zero are "no-delete", or 7, 23 and 42? It compli= cates the class and API and doesn't serve a general purpose. Usually a = predicate is used in other cases to provide a hook for bool checks.

I disagree with that 100%.=A0 In most cases res= ources -- real resources like file handles or descriptors, etc. are allocat= ed and have either a 0 / nullptr or a -1 value on failure=A0 Making the no-= delete value simple saves a lot of duplicate code.

Windows WaitFo= rMultipleObjects is an example of API that, may not completely fit scop= ed_resource scenery,
but may give an idea of the problem. I too, have found that the current sta= te fits a scenery that's not general
enough, but may cover most case= s in the wild... maybe, I can't be sure about that.
=A0
=A0
Just my CHF0.02 from a quick scan.

Peter.

Thank you for your feedback.
Where is everyo= ne else lately?=A0 Is this the week that the committee is in meetings in Br= istol?
-Andrew Sandoval

By the way, I'd like to have the newer= reference implementations available in source code form (on github for exa= mple)...

Regards,
Francisco Lopes

--
 
---
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>.
--001a11c20364c9b7df04f1204922-- .