Dnnnn - <scope_exit> RAII classes...

[Andrew Sandoval]

I've requested a document number on this but haven't received it yet.  In the meantime I wanted to make sure that the latest version of the document was available for review. It is here: http://www.andrewlsandoval.com/scope_exit/scope_exit.h

Please be kind.  I'm not sure I am even in the ballpark on the "standardese" section, but it was very painful and time consuming (something I never have enough of to start with) to put together.

Thank you, and thanks to everyone that has contributed feedback thus far on this proposal.

-Andrew Sandoval

[Peter Sommerlad]

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

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.

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.

Just my CHF0.02 from a quick scan.

Peter.

> --
>
> ---
> 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-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
> <proposal.html>

--
Prof. Peter Sommerlad

Institut für Software: Bessere Software - Einfach, Schneller!
HSR Hochschule für Technik Rapperswil
Oberseestr 10, Postfach 1475, CH-8640 Rapperswil

http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includator.com
tel:+41 55 222 49 84 == mobile:+41 79 432 23 32
fax:+41 55 222 46 29 == mailto:peter.s...@hsr.ch

[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?

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

[Mikael Kilpeläinen]

15.4.2013 21:38, Andrew Sandoval kirjoitti:
>
> Thank you for your feedback.
> Where is everyone else lately? Is this the week that the committee is
> in meetings in Bristol?

Yes it is.


Mikael

[Francisco Lopes]

2013-04-15 Andrew Sandoval <sand...@netwaysglobal.com>

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 WaitForMultipleObjects is 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

[Andrew Sandoval]

Francisco,

Were you aware that this has been replaced by N3830?  The entire reference implementation is in the PDF document that Peter Sommerlad produced for the mailing.  (He did amazing work on the reference implementation1)

-Andrew Sandoval 

[Francisco Lopes]

2014-01-29 Andrew Sandoval <sand...@netwaysglobal.com>

Francisco,

Were you aware that this has been replaced by N3830?  The entire reference implementation is in the PDF document that Peter Sommerlad produced for the mailing.  (He did amazing work on the reference implementation1)

-Andrew Sandoval 

oh, indeed, I was aware, I did look at the paper, but I don't recall whether the "no delete" was addressed, will check again, and  also, I just missed a reference implementation that I could grab and use with latest clang/g++ -std=c++1y.

[Andrew Sandoval]

Understood.  I just created this and put the implementation that I use there.  Please feel free to try it out.

https://github.com/alsliahona/N3830

-Andrew Sandoval 

[Francisco Lopes]

2014-01-29 Andrew Sandoval <sand...@netwaysglobal.com>

Thanks Andrew