220 3720 article Path: news.gmane.org!not-for-mail From: Andrew Sandoval Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Dnnnn - RAII classes... Date: Mon, 15 Apr 2013 12:38:55 -0700 (PDT) Lines: 145 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="----=_Part_553_7913120.1366054735940" X-Trace: ger.gmane.org 1366054738 3076 80.91.229.3 (15 Apr 2013 19:38:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Apr 2013 19:38:58 +0000 (UTC) Cc: Andrew Sandoval To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDIZ5RW5Y4IBBUNOWGFQKGQERD4DRPI@isocpp.org Mon Apr 15 21:39:01 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qe0-f70.google.com ([209.85.128.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1URpEw-0006Vf-So for gclcip-std-proposals@m.gmane.org; Mon, 15 Apr 2013 21:38:59 +0200 Original-Received: by mail-qe0-f70.google.com with SMTP id 1sf9624636qec.1 for ; Mon, 15 Apr 2013 12:38:58 -0700 (PDT) X-Received: by 10.224.65.6 with SMTP id g6mr13912594qai.4.1366054737982; Mon, 15 Apr 2013 12:38:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.25.138 with SMTP id c10ls959171qeg.29.gmail; Mon, 15 Apr 2013 12:38:56 -0700 (PDT) X-Received: by 10.49.15.68 with SMTP id v4mr658297qec.37.1366054736373; Mon, 15 Apr 2013 12:38:56 -0700 (PDT) In-Reply-To: <183CB42B-6923-44A7-917A-A57638EF62E2@hsr.ch> X-Original-Sender: sandoval@netwaysglobal.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:3720 Archived-At: ------=_Part_553_7913120.1366054735940 Content-Type: text/plain; charset=ISO-8859-1 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? > > 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. > 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 -- --- 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/?hl=en. ------=_Part_553_7913120.1366054735940 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Saturday, April 13, 2013 6:18:48 AM UTC-5, PeterSommerlad wrote:the loop advancement example is not ve= ry 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 lo= op by accidentally creating a path in the loop that skips the advancement.<= br>
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_p= tr or boost::scoped_ptr that already provide much of the functionality you = are proposing.

That horse has been beat to death already in the orig= inal thread on this.  The consensus was that these class are useful an= d serve a different purpose than unique_ptr.  You will find several th= at back your view point, but there is no reason for us to revisit this poin= t.  I didn't put hundreds of hours into the document after we'd alread= y had that discussion, just to fight that fight again now.  Please fee= l free to look at the previous posts.
 
The example given as Motivation B calls for a d= edicated RAII class for 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 pr= oposal, i.e., DIY local structs with destructors, or "misusing" unique_ptr/= shared_ptr for that purpose, in contrast to scoped_function and scoped_reso= urce.
 
Okay, I can definitely consider that= ..  Anyone concur?

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 u= sed in other cases to provide a hook for bool checks.

I disagree with that 100%.  In most cases resour= ces -- 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.
 
Just my CHF0.02 from a quick scan.

Peter.

Thank you for your feedback.
Where is everyone els= e lately?  Is this the week that the committee is in meetings in Brist= ol?
-Andrew Sandoval

--
 
---
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_553_7913120.1366054735940-- .