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

N

Noah Roberts

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....
}
};
 
J

Joshua Maurice

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

Noah Roberts

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
 
J

Joshua Maurice

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

Rui Maciel

Noah said:
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
 
N

Noah Roberts

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

Noah Roberts

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

Noah Roberts

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!
 
R

Rui Maciel

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

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).
It's just a technique whereby you can achieve that.


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
 
R

Rui Maciel

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
 
J

Juha Nieminen

Noah Roberts said:

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

Joshua Maurice

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

Noah Roberts

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

Noah Roberts

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

Alf P. Steinbach

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
 
M

Miles Bader

Alf P. Steinbach said:
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
 
J

Juha Nieminen

Gareth Owen said:
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.)
 
G

Guest

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

sounds a good defintion
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?
 
G

Guest

[basic defintion of RAII]
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.

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

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top