Terminology - RAII vs. Scope Guard vs...?

Discussion in 'C++' started by Noah Roberts, Apr 10, 2012.

  1. Noah Roberts

    Noah Roberts Guest

    So RAII is when you make it so that the acquisition of a resource is
    tied to the initialization of a scope-based variable that cleans up
    said resource when it's destroyed.

    A Scope Guard is something you set up when you need to do some cleanup
    or something only if you leave the function early.

    What would you call it then when you create an object that just does
    something in particular when it's destroyed...has no resources to
    clean up, and isn't told NOT to do whatever. Would you still consider
    this a scope guard? Something else?

    An example:

    struct SomeLoop
    {
    ...

    void run()
    {
    struct shutdown_guard { ~shutdown_guard()
    { sendShutdownMessage(); } } guard;

    ... possibly throws....
    }
    };
     
    Noah Roberts, Apr 10, 2012
    #1
    1. Advertising

  2. On Apr 10, 1:47 pm, Noah Roberts <> wrote:
    > So RAII is when you make it so that the acquisition of a resource is
    > tied to the initialization of a scope-based variable that cleans up
    > said resource when it's destroyed.


    RAII is more than that. It's the way of coding in which you ensure
    that all resources
    1- have an owner whose destructor will free the resource, or
    2- be on the stack (or a global or some other "root" of the ownership
    tree).

    In other words, RAII is the way of coding in which at every step of
    the program, if you have a resource that needs to be freed, you can
    identify an object whose destructor will free it, or the resource is
    an object on the stack (or a global, etc.).

    This all assumes, of course, that you have a cycle-free ownership
    graph. This works amazingly well for almost all cases. Sure, you can
    invent some corner cases where this ownership tree approach isn't a
    good option, but that's beside the point. RAII is the default for
    writing good code.

    Scope Guards are mere utility classes to help facilitate writing in
    the RAII style.
     
    Joshua Maurice, Apr 10, 2012
    #2
    1. Advertising

  3. Noah Roberts

    Noah Roberts Guest

    On Apr 10, 2:36 pm, Joshua Maurice <> wrote:
    > On Apr 10, 1:47 pm, Noah Roberts <> wrote:
    >
    > > So RAII is when you make it so that the acquisition of a resource is
    > > tied to the initialization of a scope-based variable that cleans up
    > > said resource when it's destroyed.

    >
    > RAII is more than that. It's the way of coding in which you ensure
    > that all resources
    > 1- have an owner whose destructor will free the resource, or
    > 2- be on the stack (or a global or some other "root" of the ownership
    > tree).
    >
    > In other words, RAII is the way of coding in which at every step of
    > the program, if you have a resource that needs to be freed, you can
    > identify an object whose destructor will free it, or the resource is
    > an object on the stack (or a global, etc.).
    >
    > This all assumes, of course, that you have a cycle-free ownership
    > graph. This works amazingly well for almost all cases. Sure, you can
    > invent some corner cases where this ownership tree approach isn't a
    > good option, but that's beside the point. RAII is the default for
    > writing good code.
    >
    > Scope Guards are mere utility classes to help facilitate writing in
    > the RAII style.


    Well, I'd disagree with you on that and so does most if not all of the
    documentation on the subject; all that I've seen at any rate. It is
    true that using the RAII idiom as policy is a good policy decision, at
    least in my opinion (not everyone's), but it's still an idiom rather
    than a philosophy. It can form a part of a philosophic framework
    though.

    http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
     
    Noah Roberts, Apr 11, 2012
    #3
  4. On Apr 11, 9:10 am, Noah Roberts <> wrote:
    > On Apr 10, 2:36 pm, Joshua Maurice <> wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On Apr 10, 1:47 pm, Noah Roberts <> wrote:

    >
    > > > So RAII is when you make it so that the acquisition of a resource is
    > > > tied to the initialization of a scope-based variable that cleans up
    > > > said resource when it's destroyed.

    >
    > > RAII is more than that. It's the way of coding in which you ensure
    > > that all resources
    > > 1- have an owner whose destructor will free the resource, or
    > > 2- be on the stack (or a global or some other "root" of the ownership
    > > tree).

    >
    > > In other words, RAII is the way of coding in which at every step of
    > > the program, if you have a resource that needs to be freed, you can
    > > identify an object whose destructor will free it, or the resource is
    > > an object on the stack (or a global, etc.).

    >
    > > This all assumes, of course, that you have a cycle-free ownership
    > > graph. This works amazingly well for almost all cases. Sure, you can
    > > invent some corner cases where this ownership tree approach isn't a
    > > good option, but that's beside the point. RAII is the default for
    > > writing good code.

    >
    > > Scope Guards are mere utility classes to help facilitate writing in
    > > the RAII style.

    >
    > Well, I'd disagree with you on that and so does most if not all of the
    > documentation on the subject; all that I've seen at any rate.  It is
    > true that using the RAII idiom as policy is a good policy decision, at
    > least in my opinion (not everyone's), but it's still an idiom rather
    > than a philosophy.  It can form a part of a philosophic framework
    > though.
    >
    > http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization


    I'm sorry. I don't understand what point you are trying to make. From
    the wiki page:

    > Resources therefore need to be tied to the lifespan of suitable objects in order to gain automatic reclamation. They are acquired during initialization, when there is no chance of them being used before they are available, and released with the destruction of the same objects, which is guaranteed to take place even in case of errors.


    I think it's fair to say my initial post has equivalent meaning to
    that quote from wiki.
     
    Joshua Maurice, Apr 11, 2012
    #4
  5. Noah Roberts

    Rui Maciel Guest

    Noah Roberts wrote:

    > Well, I'd disagree with you on that and so does most if not all of the
    > documentation on the subject; all that I've seen at any rate. It is
    > true that using the RAII idiom as policy is a good policy decision, at
    > least in my opinion (not everyone's), but it's still an idiom rather
    > than a philosophy. It can form a part of a philosophic framework
    > though.
    >
    > http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization


    I don't know what you were trying to do, but your comment was a bit of a
    mind bender. You started by trying to imply that somehow Joshua Maurice was
    wrong but then you proceeded to support and corroborate everything he said.

    And just to entertain the idea that Joshua Maurice's claim was wrong, then
    that would make Bjarne Stroustrup also wrong.[1] If you take the time to
    read 14.4.1 from Stroustrup's "The C++ programming language" you will
    realize that what's described there is essentially (or, arguably, exactly)
    what Joshua Maurice just pointed out.

    Regarding your assertion that RAII is an "idiom rather than a philosophy",
    it isn't very reasonable. You are trying to discuss whether the term refers
    to the underlying principle, which you appear to deny, or one of the ways it
    can be implemented, which you appear to support.


    Rui Maciel

    [¹] http://www2.research.att.com/~bs/glossary.html#Gresource-acquisition-is-
    initialization
     
    Rui Maciel, Apr 11, 2012
    #5
  6. Noah Roberts

    Noah Roberts Guest

    On Apr 11, 12:28 pm, Joshua Maurice <> wrote:
    > On Apr 11, 9:10 am, Noah Roberts <> wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On Apr 10, 2:36 pm, Joshua Maurice <> wrote:

    >
    > > > On Apr 10, 1:47 pm, Noah Roberts <> wrote:

    >
    > > > > So RAII is when you make it so that the acquisition of a resource is
    > > > > tied to the initialization of a scope-based variable that cleans up
    > > > > said resource when it's destroyed.

    >
    > > > RAII is more than that. It's the way of coding in which you ensure
    > > > that all resources
    > > > 1- have an owner whose destructor will free the resource, or
    > > > 2- be on the stack (or a global or some other "root" of the ownership
    > > > tree).

    >
    > > > In other words, RAII is the way of coding in which at every step of
    > > > the program, if you have a resource that needs to be freed, you can
    > > > identify an object whose destructor will free it, or the resource is
    > > > an object on the stack (or a global, etc.).

    >
    > > > This all assumes, of course, that you have a cycle-free ownership
    > > > graph. This works amazingly well for almost all cases. Sure, you can
    > > > invent some corner cases where this ownership tree approach isn't a
    > > > good option, but that's beside the point. RAII is the default for
    > > > writing good code.

    >
    > > > Scope Guards are mere utility classes to help facilitate writing in
    > > > the RAII style.

    >
    > > Well, I'd disagree with you on that and so does most if not all of the
    > > documentation on the subject; all that I've seen at any rate.  It is
    > > true that using the RAII idiom as policy is a good policy decision, at
    > > least in my opinion (not everyone's), but it's still an idiom rather
    > > than a philosophy.  It can form a part of a philosophic framework
    > > though.

    >
    > >http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

    >
    > I'm sorry. I don't understand what point you are trying to make.


    The point I'm trying to make is that RAII is just one idiom. It's a
    technique that can be used as part of a coding policy. It isn't
    itself a policy as you claim. It also isn't the only valid policy and
    might not be a good fit for every project. It would actually fit
    rather poorly in a project that used allocation pools for example.
     
    Noah Roberts, Apr 11, 2012
    #6
  7. Noah Roberts

    Noah Roberts Guest

    On Apr 11, 1:28 pm, Rui Maciel <> wrote:
    > Noah Roberts wrote:
    > > Well, I'd disagree with you on that and so does most if not all of the
    > > documentation on the subject; all that I've seen at any rate.  It is
    > > true that using the RAII idiom as policy is a good policy decision, at
    > > least in my opinion (not everyone's), but it's still an idiom rather
    > > than a philosophy.  It can form a part of a philosophic framework
    > > though.

    >
    > >http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

    >
    > I don't know what you were trying to do, but your comment was a bit of a
    > mind bender. You started by trying to imply that somehow Joshua Maurice was
    > wrong but then you proceeded to support and corroborate everything he said.


    Well, I fail to see where he laid any support, but whatever.
    >
    > And just to entertain the idea that Joshua Maurice's claim was wrong, then
    > that would make Bjarne Stroustrup also wrong.[1]  If you take the time to
    > read 14.4.1 from Stroustrup's "The C++ programming language" you will
    > realize that what's described there is essentially (or, arguably, exactly)
    > what Joshua Maurice just pointed out.


    I don't have that book on my shelf at the moment and you don't even
    bother to paraphrase so I have no idea if I disagree with Bjarne or
    not.

    He's not a God you know. All the big mucky mucks make mistakes. I
    myself have corrected Myers on occasion.

    I very much doubt that Bjarne would claim that, "RAII is the way of
    coding in which at every step of the program, if you have a resource
    that needs to be freed, you can identify an object whose destructor
    will free it, or the resource is an object on the stack"

    It's just a technique whereby you can achieve that.

    > Regarding your assertion that RAII is an "idiom rather than a philosophy",
    > it isn't very reasonable.


    Well, it _is_ an idiom so if basing my statements on reality is not
    very reasonable then I guess that's what I am.

    > You are trying to discuss whether the term refers to the underlying principle, which you appear to deny, or one of the ways it can be implemented, which you appear to support.


    No, there are many ways to implement RAII. There's vectors, smart
    pointers, etc... I do not deny that RAII describes an underlying
    principle. It _is_ an idiom for heaven's sake. I do deny that RAII
    is as far reaching as you guys seem to claim or I might be tempted to
    say that the CRTP (another idiom) or the pimpl idiom where ways of
    coding in which every step of the program etc... I'd be totally wrong
    of course, which the two of you are now.

    Idioms are smaller and more specific than patterns. If patterns
    aren't "ways of coding in which every step of the program..." then why
    would idioms be?

    What you guys are trying to do is take a coding policy in which RAII
    is used anywhere resources are needed, which can be a very good policy
    to hold, and equate that with the idiom itself. It's just not the
    case. RAII is quite specific in its scope. Just look at the words
    the letters stand for: Resource Allocation Is Initialization.
     
    Noah Roberts, Apr 11, 2012
    #7
  8. Noah Roberts

    Jorgen Grahn Guest

    On Wed, 2012-04-11, Joshua Maurice wrote:
    > On Apr 11, 9:10 am, Noah Roberts <> wrote:

    ....
    >> http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

    >
    > I'm sorry. I don't understand what point you are trying to make. From
    > the wiki page: [...]


    Please be a bit careful when quoting that WP page. Every time I've
    checked it, it has been too confused to be useful. E.g. dozens of
    people trying to prove /their/ favorite language has RAII, too.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Apr 11, 2012
    #8
  9. Noah Roberts

    Noah Roberts Guest

    On Apr 11, 2:36 pm, Jorgen Grahn <> wrote:
    > On Wed, 2012-04-11, Joshua Maurice wrote:
    > > On Apr 11, 9:10 am, Noah Roberts <> wrote:

    > ...
    > >>http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

    >
    > > I'm sorry. I don't understand what point you are trying to make. From
    > > the wiki page: [...]

    >
    > Please be a bit careful when quoting that WP page. Every time I've
    > checked it, it has been too confused to be useful.  E.g. dozens of
    > people trying to prove /their/ favorite language has RAII, too.


    Yeah, I noticed that when I looked at the c2g or whatever page. Some
    person was on there saying it was just "finalization" and compared it
    to Java's finally block. Uh...NO!
     
    Noah Roberts, Apr 12, 2012
    #9
  10. Noah Roberts

    Rui Maciel Guest

    Noah Roberts wrote:

    >> And just to entertain the idea that Joshua Maurice's claim was wrong,
    >> then that would make Bjarne Stroustrup also wrong.[1] If you take the
    >> time to read 14.4.1 from Stroustrup's "The C++ programming language" you
    >> will realize that what's described there is essentially (or, arguably,
    >> exactly) what Joshua Maurice just pointed out.

    >
    > I don't have that book on my shelf at the moment and you don't even
    > bother to paraphrase so I have no idea if I disagree with Bjarne or
    > not.
    >
    > He's not a God you know. All the big mucky mucks make mistakes. I
    > myself have corrected Myers on occasion.


    He is not a God. He is the inventor of RAII, apparently. I believe we can
    agree that the inventor of RAII should be expected to know a bit about RAII.


    > I very much doubt that Bjarne would claim that, "RAII is the way of
    > coding in which at every step of the program, if you have a resource
    > that needs to be freed, you can identify an object whose destructor
    > will free it, or the resource is an object on the stack"


    You have the right to doubt that. Yet, if you happen to read "The Design
    and Evolution of C++", by Stroustrup, you will read on section 16.5, the
    section on RAII, that he states the following regarding RAII:

    <quote>
    Fortunately, there is a more elegant solution. The general form of the
    problem looks like this:

    void use()
    {
    // acquire resource 1
    // ...
    // acquire resource n

    // use resource

    // release resource n
    // ...
    // release resource 1
    }

    It is tipically important that resources are released in the reverse order
    of their acquisition. This strongly resembles the behavior of local objects
    created by constructors and destroyed by destructurs. Thus we can handle
    such resource acquisition and release problems by a suitable use of objects
    of classes with constructors and destructors.

    <snip/>

    I called this technique ''resource acquisition is initialization.''

    </quote>

    So, it may not be verbatim, but it sure is pretty much exactly what has been
    said. If you disagree then read the above quote and also the one repeated
    below, and do point out where these quotes don't agree.

    <quote>
    RAII is more than that. It's the way of coding in which you ensure
    that all resources
    1- have an owner whose destructor will free the resource, or
    2- be on the stack (or a global or some other "root" of the ownership
    tree).
    </quote>


    > It's just a technique whereby you can achieve that.
    >
    >> Regarding your assertion that RAII is an "idiom rather than a
    >> philosophy", it isn't very reasonable.

    >
    > Well, it _is_ an idiom so if basing my statements on reality is not
    > very reasonable then I guess that's what I am.


    The expression "programming idiom" refers to a particular way to express a
    concept or idea which is specific to a particular language. RAII may have
    been conceived by Stroustrup and described in a number of C++ books, but
    that hardly makes it a programming idiom, let alone one which is exclusive
    to C++. Any programming language which supports constructors/destructors
    can implement the RAII technique, and even if the language doesn't support
    constructors/destructors then you can always implement RAII by employing a
    number of tricks in any programming language.


    <snip/>

    Rui Maciel
     
    Rui Maciel, Apr 12, 2012
    #10
  11. Noah Roberts

    Rui Maciel Guest

    Noah Roberts wrote:z

    > The point I'm trying to make is that RAII is just one idiom. It's a
    > technique that can be used as part of a coding policy. It isn't
    > itself a policy as you claim.


    What definition of "idiom" and "coding policy" are you following?


    Rui Maciel
     
    Rui Maciel, Apr 12, 2012
    #11
  12. Noah Roberts <> wrote:
    > On Apr 11, 2:36 pm, Jorgen Grahn <> wrote:
    >> On Wed, 2012-04-11, Joshua Maurice wrote:
    >> > On Apr 11, 9:10 am, Noah Roberts <> wrote:

    >> ...
    >> >>http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

    >>
    >> > I'm sorry. I don't understand what point you are trying to make. From
    >> > the wiki page: [...]

    >>
    >> Please be a bit careful when quoting that WP page. Every time I've
    >> checked it, it has been too confused to be useful.  E.g. dozens of
    >> people trying to prove /their/ favorite language has RAII, too.

    >
    > Yeah, I noticed that when I looked at the c2g or whatever page. Some
    > person was on there saying it was just "finalization" and compared it
    > to Java's finally block. Uh...NO!


    The wikipedia page also seems to assume that RAII is just about scope-based
    construction and destruction of objects, as indicated for example by giving
    the gcc extension "cleanup" variable attribute as an example on how to
    emulate RAII in C. However, it's not just about construction and destruction
    of objects. One extremely important part of RAII is copying (both in the
    form of copy constructors and assignment operators).

    It is what allows, for example, to return objects by value from functions,
    give them to functions as value parameters and to have RAII even in the
    heap (as long as the container structure is allocated and deallocated
    appropriately, the contained objects will follow the RAII rules). I don't
    think any of this is something that can be implemented with that gcc
    extension nor in languages like Java.
     
    Juha Nieminen, Apr 12, 2012
    #12
  13. On Apr 11, 1:29 pm, Noah Roberts <> wrote:
    > On Apr 11, 12:28 pm, Joshua Maurice <> wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On Apr 11, 9:10 am, Noah Roberts <> wrote:

    >
    > > > On Apr 10, 2:36 pm, Joshua Maurice <> wrote:

    >
    > > > > On Apr 10, 1:47 pm, Noah Roberts <> wrote:

    >
    > > > > > So RAII is when you make it so that the acquisition of a resourceis
    > > > > > tied to the initialization of a scope-based variable that cleans up
    > > > > > said resource when it's destroyed.

    >
    > > > > RAII is more than that. It's the way of coding in which you ensure
    > > > > that all resources
    > > > > 1- have an owner whose destructor will free the resource, or
    > > > > 2- be on the stack (or a global or some other "root" of the ownership
    > > > > tree).

    >
    > > > > In other words, RAII is the way of coding in which at every step of
    > > > > the program, if you have a resource that needs to be freed, you can
    > > > > identify an object whose destructor will free it, or the resource is
    > > > > an object on the stack (or a global, etc.).

    >
    > > > > This all assumes, of course, that you have a cycle-free ownership
    > > > > graph. This works amazingly well for almost all cases. Sure, you can
    > > > > invent some corner cases where this ownership tree approach isn't a
    > > > > good option, but that's beside the point. RAII is the default for
    > > > > writing good code.

    >
    > > > > Scope Guards are mere utility classes to help facilitate writing in
    > > > > the RAII style.

    >
    > > > Well, I'd disagree with you on that and so does most if not all of the
    > > > documentation on the subject; all that I've seen at any rate.  It is
    > > > true that using the RAII idiom as policy is a good policy decision, at
    > > > least in my opinion (not everyone's), but it's still an idiom rather
    > > > than a philosophy.  It can form a part of a philosophic framework
    > > > though.

    >
    > > >http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

    >
    > > I'm sorry. I don't understand what point you are trying to make.

    >
    > The point I'm trying to make is that RAII is just one idiom.  It's a
    > technique that can be used as part of a coding policy.  It isn't
    > itself a policy as you claim.  It also isn't the only valid policy and
    > might not be a good fit for every project.  It would actually fit
    > rather poorly in a project that used allocation pools for example.


    Ok. Sorry. This is now an unintentional argument over definitions
    ("philosophy" and "idiom" and "policy"). The argument is not terribly
    interesting. I am glad we are otherwise in agreement.
     
    Joshua Maurice, Apr 12, 2012
    #13
  14. Noah Roberts

    Noah Roberts Guest

    On Apr 11, 6:27 pm, Rui Maciel <> wrote:

    > <quote>
    > Fortunately, there is a more elegant solution.  The general form of the
    > problem looks like this:
    >
    > void use()
    > {
    >     // acquire resource 1
    >     // ...
    >     // acquire resource n
    >
    >     // use resource
    >
    >     // release resource n
    >     // ...
    >     // release resource 1
    >
    > }
    >
    > It is tipically important that resources are released in the reverse order
    > of their acquisition.  This strongly resembles the behavior of local objects
    > created by constructors and destroyed by destructurs.  Thus we can handle
    > such resource acquisition and release problems by a suitable use of objects
    > of classes with constructors and destructors.
    >
    > <snip/>
    >
    > I called this technique ''resource acquisition is initialization.''
    >
    > </quote>
    >
    > So, it may not be verbatim, but it sure is pretty much exactly what has been
    > said.  If you disagree then read the above quote and also the one repeated
    > below, and do point out where these quotes don't agree.


    Certainly not the way I interpret it. Looks to me like he's
    describing a technique that answers a specific class of problem, not a
    programming paradigm that needs to be used across the board in a
    program.
     
    Noah Roberts, Apr 13, 2012
    #14
  15. Noah Roberts

    Noah Roberts Guest

    On Apr 12, 2:31 pm, Joshua Maurice <> wrote:

    > Ok. Sorry. This is now an unintentional argument over definitions
    > ("philosophy" and "idiom" and "policy"). The argument is not terribly
    > interesting. I am glad we are otherwise in agreement.


    Except that you claimed that scope guards are a kind of RAII that that
    does not appear to be the case. They are *similar*, in that they both
    use the destructor to cause something to happen when scope is exited,
    but not the same. RAII for one clearly means that we're acquiring a
    resource as we initialize an object...that is the fundamental part of
    scope based creation/destruction events that makes something RAII.
    Scope guards don't necessarily do that nor are they necessarily about
    any resource at all...they might just print a message if you don't
    tell them not to.

    Thus my question remains and you've done little but serve to distract
    the conversation. When talking about these different things, and it's
    important that they have different terms because they are in fact
    different, what do you call something that's sort of like a scope
    guard but does not have a backout...in other words you never release
    it.

    Before you go saying it's the same thing...it's not:
    http://en.wikibooks.org/wiki/More_C++_Idioms/Scope_Guard

    In this case we want something to happen no matter why you leave
    scope.

    Now, I'd agree that this seems like pedantic little differences, but
    I'm interested in discussing these techniques on an instructional
    level and I want to make sure not to muddle terms. The difference
    between a general "use RAII like stuff everywhere" policy and the
    exact idioms themselves is important here. RAII != scope guard !=
    whatever I'm doing even though all are methods to leverage destructors
    to take care of things for you.
     
    Noah Roberts, Apr 13, 2012
    #15
  16. On 13.04.2012 01:48, Noah Roberts wrote:
    > On Apr 12, 2:31 pm, Joshua Maurice<> wrote:
    >
    >> Ok. Sorry. This is now an unintentional argument over definitions
    >> ("philosophy" and "idiom" and "policy"). The argument is not terribly
    >> interesting. I am glad we are otherwise in agreement.

    >
    > Except that you claimed that scope guards are a kind of RAII that that
    > does not appear to be the case. They are *similar*, in that they both
    > use the destructor to cause something to happen when scope is exited,
    > but not the same. RAII for one clearly means that we're acquiring a
    > resource as we initialize an object...that is the fundamental part of
    > scope based creation/destruction events that makes something RAII.
    > Scope guards don't necessarily do that nor are they necessarily about
    > any resource at all...they might just print a message if you don't
    > tell them not to.
    >
    > Thus my question remains and you've done little but serve to distract
    > the conversation. When talking about these different things, and it's
    > important that they have different terms because they are in fact
    > different, what do you call something that's sort of like a scope
    > guard but does not have a backout...in other words you never release
    > it.
    >
    > Before you go saying it's the same thing...it's not:
    > http://en.wikibooks.org/wiki/More_C++_Idioms/Scope_Guard


    The Wikipedia article is written by someone who doesn't understand a
    thing, and who treats obvious things as significant.

    It's very annoying with such wanna-be academics.

    You better read up on the original DDJ article by Alexandrescu & Marginan.


    Cheers & hth.,

    - Alf
     
    Alf P. Steinbach, Apr 13, 2012
    #16
  17. Noah Roberts

    Miles Bader Guest

    "Alf P. Steinbach" <> writes:
    > The Wikipedia article is written by someone who doesn't understand a
    > thing, and who treats obvious things as significant.
    >
    > It's very annoying with such wanna-be academics.


    'cause, you know, c.l.c++ is SO MUCH BETTER...

    -miles

    --
    「寒ã„ã­ã€ã¨è©±ã—ã‹ã‘ã‚Œã°ã€Œå¯’ã„ã­ã€ã¨ç­”ãˆã‚‹äººã®ã„ã‚‹ã‚ã£ãŸã‹ã• [俵万智]
     
    Miles Bader, Apr 13, 2012
    #17
  18. Gareth Owen <> wrote:
    > You could define
    >
    > * a language that forces copyable object to have a java-like
    > user-provided clone() for all objects, and no implicit copying or
    > assignment for user defined types (just as many C++ polymorphic
    > classes do)
    > * or a language where every object acted like std::shared_ptr
    > * or even (god forbid) a language where every object acted like
    > std::auto_ptr
    >
    > and still have RAII, just as long as you had destruction when the last
    > reference vanished.


    I suppose you could, but then you would be seriously hindering the
    flexibility and efficiency of the language. For instance, you could not
    anylonger create generic code, eg. generic data containers, that would
    work on basic types as well as objects, each object would be slow to
    create and destroy and would consume extra memory, it would be complicated
    to make one object have the same state as another (ie. assignment), it
    would be difficult to implement a copy-on-write mechanism, and so on.

    Moreover, the copying/assignment mechanism essential to RAII would
    still be there, it's just that it would be limited to the native "smart
    pointer" type and you would be unable to create your own special smart
    pointers (because of the inability of treating objects by value and
    implementing copy constructors and copy assignment operators for them).

    (And even moreover, forcing each object to be handled by a reference
    counting smart pointer can more easily lead to situations where the
    object is never freed or is freed too soon. It's basically impossible
    for a compiler to automatically detect such situations.)
     
    Juha Nieminen, Apr 13, 2012
    #18
  19. Noah Roberts

    Guest

    On Wednesday, April 11, 2012 5:10:39 PM UTC+1, Noah Roberts wrote:
    > On Apr 10, 2:36 pm, Joshua Maurice <> wrote:
    > > On Apr 10, 1:47 pm, Noah Roberts <> wrote:


    > > > So RAII is when you make it so that the acquisition of a resource is
    > > > tied to the initialization of a scope-based variable that cleans up
    > > > said resource when it's destroyed.


    I'd have skipped the "scope-based" bit

    > > RAII is more than that. It's the way of coding in which you ensure
    > > that all resources
    > > 1- have an owner whose destructor will free the resource, or
    > > 2- be on the stack (or a global or some other "root" of the ownership
    > > tree).
    > >
    > > In other words, RAII is the way of coding in which at every step of
    > > the program, if you have a resource that needs to be freed, you can
    > > identify an object whose destructor will free it, or the resource is
    > > an object on the stack (or a global, etc.).


    sounds a good defintion

    > > This all assumes, of course, that you have a cycle-free ownership
    > > graph. This works amazingly well for almost all cases. Sure, you can
    > > invent some corner cases where this ownership tree approach isn't a
    > > good option, but that's beside the point. RAII is the default for
    > > writing good code.
    > >
    > > Scope Guards are mere utility classes to help facilitate writing in
    > > the RAII style.


    yes

    > Well, I'd disagree with you on that and so does most if not all of the
    > documentation on the subject;


    I think you're reading that documentation in an odd manner

    > all that I've seen at any rate. It is
    > true that using the RAII idiom as policy is a good policy decision, at
    > least in my opinion (not everyone's),


    who disagrees?

    > but it's still an idiom rather
    > than a philosophy.


    what's the difference between and idiom, a policy and a philosophy. You threw the "philosophy" in no one had mentioned it up to now.

    > It can form a part of a philosophic framework though.


    it guides my moral decisions?

    > http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
     
    , Apr 13, 2012
    #19
  20. Noah Roberts

    Guest

    On Wednesday, April 11, 2012 9:40:47 PM UTC+1, Noah Roberts wrote:
    > On Apr 11, 1:28 pm, Rui Maciel <> wrote:
    > > Noah Roberts wrote:


    [basic defintion of RAII]

    > > > Well, I'd disagree with you on that and so does most if not all of the
    > > > documentation on the subject; all that I've seen at any rate.  It is
    > > > true that using the RAII idiom as policy is a good policy decision, at
    > > > least in my opinion (not everyone's), but it's still an idiom rather
    > > > than a philosophy.  It can form a part of a philosophic framework
    > > > though.

    > >
    > > >http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

    > >
    > > I don't know what you were trying to do, but your comment was a bit of a
    > > mind bender. You started by trying to imply that somehow Joshua Mauricewas
    > > wrong but then you proceeded to support and corroborate everything he said.

    >
    > Well, I fail to see where he laid any support, but whatever.


    "laid any support" meaning what? Are we reading the same posts?

    > > And just to entertain the idea that Joshua Maurice's claim was wrong, then
    > > that would make Bjarne Stroustrup also wrong.[1]  If you take the time to
    > > read 14.4.1 from Stroustrup's "The C++ programming language" you will
    > > realize that what's described there is essentially (or, arguably, exactly)
    > > what Joshua Maurice just pointed out.


    <snip>

    > I very much doubt that Bjarne would claim that, "RAII is the way of
    > coding in which at every step of the program, if you have a resource
    > that needs to be freed, you can identify an object whose destructor
    > will free it, or the resource is an object on the stack"
    >
    > It's just a technique whereby you can achieve that.


    this seems like a distinction without a difference.

    > > Regarding your assertion that RAII is an "idiom rather than a philosophy",
    > > it isn't very reasonable.

    >
    > Well, it _is_ an idiom so if basing my statements on reality is not
    > very reasonable then I guess that's what I am.


    why is it an idiom? What is an idiom? I'd define an idiom as a particular coding technique. What's a "philosophy"? Why isn't scope guard simply one way of achieving (the idiom) RAII?

    > > You are trying to discuss whether the term refers to the underlying principle, which you appear to deny, or one of the ways it can be implemented,which you appear to support.

    >
    > No, there are many ways to implement RAII. There's vectors, smart
    > pointers, etc... I do not deny that RAII describes an underlying
    > principle. It _is_ an idiom for heaven's sake.


    again what does this mean. Why is it important?

    > I do deny that RAII
    > is as far reaching as you guys seem to claim


    but if it's applied systematically then you can be sure who owns what and be able to guarentee correct destruction and realease of "resources" (resource maybe more widely defined than you use it).

    > or I might be tempted to
    > say that the CRTP (another idiom) or the pimpl idiom where ways of
    > coding in which every step of the program etc... I'd be totally wrong
    > of course, which the two of you are now.


    what?

    > Idioms are smaller and more specific than patterns. If patterns
    > aren't "ways of coding in which every step of the program..." then why
    > would idioms be?


    dunno. Who was claiming any of this? And I'm still not sure what "idiom" means to you.

    > What you guys are trying to do is take a coding policy in which RAII
    > is used anywhere resources are needed, which can be a very good policy
    > to hold, and equate that with the idiom itself.


    I can't see the difference

    > It's just not the
    > case. RAII is quite specific in its scope. Just look at the words
    > the letters stand for: Resource Allocation Is Initialization.


    etomology is sometimes a poor guide to semantics

    homophobic: fear of sameness
     
    , Apr 13, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Johannes Schaub (litb)

    Re: Why is RAII called RAII?

    Johannes Schaub (litb), Sep 12, 2010, in forum: C++
    Replies:
    2
    Views:
    430
    James Kanze
    Sep 18, 2010
  2. cpp4ever

    Re: Why is RAII called RAII?

    cpp4ever, Sep 12, 2010, in forum: C++
    Replies:
    1
    Views:
    431
    BGB / cr88192
    Sep 13, 2010
  3. Goran Pusic

    Re: Why is RAII called RAII?

    Goran Pusic, Sep 13, 2010, in forum: C++
    Replies:
    11
    Views:
    595
    ptyxs
    Sep 16, 2010
  4. Paul
    Replies:
    63
    Views:
    1,328
  5. scope and RAII

    , Mar 24, 2007, in forum: Ruby
    Replies:
    7
    Views:
    115
    Rick DeNatale
    Mar 26, 2007
Loading...

Share This Page