Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #15277 > unrolled thread

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

Back to article view | Back to comp.lang.c++

Contents

  Terminology - RAII vs. Scope Guard vs...? Noah Roberts <roberts.noah@gmail.com> - 2012-04-10 13:47 -0700
    Re: Terminology - RAII vs. Scope Guard vs...? Joshua Maurice <joshuamaurice@gmail.com> - 2012-04-10 14:36 -0700
      Re: Terminology - RAII vs. Scope Guard vs...? Noah Roberts <roberts.noah@gmail.com> - 2012-04-11 09:10 -0700
        Re: Terminology - RAII vs. Scope Guard vs...? Joshua Maurice <joshuamaurice@gmail.com> - 2012-04-11 12:28 -0700
          Re: Terminology - RAII vs. Scope Guard vs...? Noah Roberts <roberts.noah@gmail.com> - 2012-04-11 13:29 -0700
            Re: Terminology - RAII vs. Scope Guard vs...? Rui Maciel <rui.maciel@gmail.com> - 2012-04-12 02:29 +0100
            Re: Terminology - RAII vs. Scope Guard vs...? Joshua Maurice <joshuamaurice@gmail.com> - 2012-04-12 14:31 -0700
              Re: Terminology - RAII vs. Scope Guard vs...? Noah Roberts <roberts.noah@gmail.com> - 2012-04-12 16:48 -0700
                Re: Terminology - RAII vs. Scope Guard vs...? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-04-13 02:34 +0200
                  Re: Terminology - RAII vs. Scope Guard vs...? Miles Bader <miles@gnu.org> - 2012-04-13 10:57 +0900
                    Re: Terminology - RAII vs. Scope Guard vs...? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-04-13 09:52 +0200
                    Re: Terminology - RAII vs. Scope Guard vs...? Rui Maciel <rui.maciel@gmail.com> - 2012-04-13 10:48 +0100
                      Re: Terminology - RAII vs. Scope Guard vs...? Miles Bader <miles@gnu.org> - 2012-04-13 22:18 +0900
                        Re: Terminology - RAII vs. Scope Guard vs...? Noah Roberts <roberts.noah@gmail.com> - 2012-04-13 09:21 -0700
          Re: Terminology - RAII vs. Scope Guard vs...? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-11 21:36 +0000
            Re: Terminology - RAII vs. Scope Guard vs...? Noah Roberts <roberts.noah@gmail.com> - 2012-04-11 16:07 -0700
              Re: Terminology - RAII vs. Scope Guard vs...? Juha Nieminen <nospam@thanks.invalid> - 2012-04-12 06:10 +0000
                Re: Terminology - RAII vs. Scope Guard vs...? Gareth Owen <gwowen@gmail.com> - 2012-04-12 18:18 +0100
                  Re: Terminology - RAII vs. Scope Guard vs...? Juha Nieminen <nospam@thanks.invalid> - 2012-04-13 04:52 +0000
                    Re: Terminology - RAII vs. Scope Guard vs...? Gareth Owen <gwowen@gmail.com> - 2012-04-13 06:59 +0100
                      Never using free() or realloc().  Destroying heaps.  @Jeff-Relf.Me - 2012-04-13 00:55 -0700
        Re: Terminology - RAII vs. Scope Guard vs...? Rui Maciel <rui.maciel@gmail.com> - 2012-04-11 21:28 +0100
          Re: Terminology - RAII vs. Scope Guard vs...? Noah Roberts <roberts.noah@gmail.com> - 2012-04-11 13:40 -0700
            Re: Terminology - RAII vs. Scope Guard vs...? Rui Maciel <rui.maciel@gmail.com> - 2012-04-12 02:27 +0100
              Re: Terminology - RAII vs. Scope Guard vs...? scott@slp53.sl.home (Scott Lurndal) - 2012-04-12 17:25 +0000
                Re: Terminology - RAII vs. Scope Guard vs...? Gareth Owen <gwowen@gmail.com> - 2012-04-12 19:21 +0100
              Re: Terminology - RAII vs. Scope Guard vs...? Noah Roberts <roberts.noah@gmail.com> - 2012-04-12 16:38 -0700
                Re: Terminology - RAII vs. Scope Guard vs...? Rui Maciel <rui.maciel@gmail.com> - 2012-04-13 11:02 +0100
            Re: Terminology - RAII vs. Scope Guard vs...? nick_keighley_nospam@hotmail.com - 2012-04-13 00:29 -0700
        Re: Terminology - RAII vs. Scope Guard vs...? nick_keighley_nospam@hotmail.com - 2012-04-13 00:14 -0700

Page 2 of 2 — ← Prev page 1 [2]

#15346 — Never using free() or realloc(). Destroying heaps. 

<PRE>
Re: Memory Management

I've never been tempted to use C++ "destructors".

I like creating a heap, allocating hundreds of thousands of blocks,
never using free() or realloc(), then destroying the heap.

From <A hRef="http://Jeff-Relf.Me/X.CPP">X.CPP</A>:

  LnP ReAllocTmp( Void⋅P B⁰, int Sz⁰, int Sz ) {

    Void⋅P  B = B⁰ ;
    if ( Sz > 0 && Sz > Sz⁰ )
      //  Allocate a larger block from a temporary heap.
      B = MallocTmp( Sz );

    if ( B⁰ && Sz⁰ > 0 )
      //  Move data to the new block.
      memmove( B, B⁰, Sz⁰ );
    
    return LnP( B );  }

[toc] | [prev] | [next] | [standalone]

#15299

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

[toc] | [prev] | [next] | [standalone]

#15301

On Apr 11, 1:28 pm, Rui Maciel <rui.mac...@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#15314

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

[toc] | [prev] | [next] | [standalone]

#15325

Rui Maciel <rui.maciel@gmail.com> writes:
>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.
>

While we didn't call it RAII, we used RAII techniques in an operating
system in 1989 (using Cfront 2.1).  I'm not sure when BS codified it.
We also used a class,  an instance of which was defined as an automatic
stack variable, which was used to clean up a partial fork() when the
fork failed partway through by using the destructor to free any resources
(memory, file descriptor tables, etc) when the fork failed simply by
returning from the fork implementation member function and letting the
destructor for the instance do the cleanup.

scott
//
//      This class implements a recovery mechanism for fork failures.
//
class tForkFailure
{
public:
        tProc           *procp;
        tLwp            *CrLwp;
        KnCap           *ChildCap;
        int             nlwp;
        int             total_lwp;

        int             ret;

        KnCap           *PActUI;
        boolean_t       rgn;
        boolean_t       semundo;
        boolean_t       file;

        tForkFailure(tProc *, tLwp *, KnCap *, int, int);
        ~tForkFailure();
};

//
//      Destructor: undo what fork has done upon failure.
//
tForkFailure::~tForkFailure()
{
        if (ret == 0) {
                return;
        }

        if (PActUI != NULL) {
                procp->Mem.Exit(ChildCap);
        }

                //
                // XXXKYS: the DeleteAll() needs to take 
                // into account that some of the LWPs
                // in the list may be zombies.
                //
        procp->LwpList.DeleteAll();

        if (rgn == B_TRUE) {
                procp->Rgn.ShmExit(CrLwp, procp);
        }

        if (semundo == B_TRUE) {
                procp->Undo.SemUnFork();
        }

        if (file == B_TRUE) {
                procp->File.ForkUndo();
        }

        procp->ProcRlim->rlFree(nlwp + 1);
        procp->ProcCred->CrFree(nlwp + 1);

        procp->UidQuota.FreeProc(B_TRUE, total_lwp, 1);
}

[toc] | [prev] | [next] | [standalone]

#15327

scott@slp53.sl.home (Scott Lurndal) writes:

> While we didn't call it RAII, we used RAII techniques in an operating
> system in 1989 (using Cfront 2.1).  I'm not sure when BS codified it.

"Design & Evolution of C++" (S16.5) suggests that BS and Andrew Koenig
described it at the C++ Conference in 1990, so it looks like you hit
upon it roughly contemporaneously.

[toc] | [prev] | [next] | [standalone]

#15333

On Apr 11, 6:27 pm, Rui Maciel <rui.mac...@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#15349

Noah Roberts wrote:

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

I don't believe anyone tried to make any of the claims you mentioned.  The 
point of this discussion is that, in spite of your claim, RAII is not a C++ 
idiom, but a techinque devised to help managing resources.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#15344

On Wednesday, April 11, 2012 9:40:47 PM UTC+1, Noah Roberts wrote:
> On Apr 11, 1:28 pm, Rui Maciel <rui.mac...@gmail.com> 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 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.

"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

[toc] | [prev] | [next] | [standalone]

#15343

On Wednesday, April 11, 2012 5:10:39 PM UTC+1, Noah Roberts wrote:
> On Apr 10, 2:36 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> > On Apr 10, 1:47 pm, Noah Roberts <roberts.n...@gmail.com> 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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web