Resource Acquisition Is Initialization Naming
Rob Stewart
something in their ctor and undo it in their dtor
_Excursion_Classes_. In a private email, Bjarne Stroustrup said
he didn't think that name captured the behavior sufficiently, but
neither does "resource acquisition is initialization" (since it
doesn't mention the undoing part). There have been, no doubt,
other names especially for certain applications of the idiom, but
I know of no single name for the idiom.
Consequently, I'd like to once and for all (wishful thinking?)
establish a name for this idiom that is evocative of their
behavior, yet simple. Opinions?
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Francis Glassborow
<donot...@giage.com> writes
>Consequently, I'd like to once and for all (wishful thinking?)
>establish a name for this idiom that is evocative of their
>behavior, yet simple. Opinions?
Personally I am quite happy with 'Resource acq...' and think it does
much better than your alternative but if you want another idea how
about:
Resource management by object.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Siemel B. Naran
>For many years, I've called the classes whose objects do
>something in their ctor and undo it in their dtor
>_Excursion_Classes_. In a private email, Bjarne Stroustrup said
>he didn't think that name captured the behavior sufficiently, but
>neither does "resource acquisition is initialization" (since it
>doesn't mention the undoing part). There have been, no doubt,
>other names especially for certain applications of the idiom, but
>I know of no single name for the idiom.
std::pair<
resource acquisition is initialization
resource de-acquisition is de-initialization
>;
:)
--
--------------
siemel b naran
--------------
Ken Bloom
--
"THE WALL does as much disservice to the people who are
on it does to the people who aren't"
Francis Glassborow <fra...@robinton.demon.co.uk> wrote in message
news:pJwPODAw...@robinton.demon.co.uk...
> In article <38B69675...@giage.com>, Rob Stewart
> <donot...@giage.com> writes
> >Consequently, I'd like to once and for all (wishful thinking?)
> >establish a name for this idiom that is evocative of their
> >behavior, yet simple. Opinions?
>
> Personally I am quite happy with 'Resource acq...' and think it does
> much better than your alternative but if you want another idea how
> about:
>
> Resource management by object.
>
>
That doesn't quite imply that it should be done in c'tors/d'tors.
Ken Bloom
Rob Stewart <donot...@giage.com> wrote in message
news:38B69675...@giage.com...
> For many years, I've called the classes whose objects do
> something in their ctor and undo it in their dtor
> _Excursion_Classes_. In a private email, Bjarne Stroustrup said
> he didn't think that name captured the behavior sufficiently, but
> neither does "resource acquisition is initialization" (since it
> doesn't mention the undoing part). There have been, no doubt,
> other names especially for certain applications of the idiom, but
> I know of no single name for the idiom.
>
> establish a name for this idiom that is evocative of their
> behavior, yet simple. Opinions?
acquisition is construction, disposal is destruction
Daniel T.
<fran...@robinton.demon.co.uk> wrote:
>In article <38B69675...@giage.com>, Rob Stewart
><donot...@giage.com> writes
>>Consequently, I'd like to once and for all (wishful thinking?)
>>establish a name for this idiom that is evocative of their
>>behavior, yet simple. Opinions?
>
>Personally I am quite happy with 'Resource acq...' and think it does
>much better than your alternative but if you want another idea how
>about:
>
>Resource management by object.
And the objects themselves could be called resource managers... I like =
it.
Francis Glassborow
<ken...@forfree.at> writes
>> Resource management by object.
>>
>>
>That doesn't quite imply that it should be done in c'tors/d'tors.
>
Resources are objects.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Ken Hagan
news:89cm5s$7pe$1...@nntp9.atl.mindspring.net...
> That doesn't quite imply that it should be done in c'tors/d'tors.
It doesn't. My own reasons for disliking the RAII phrase is that it focuses
exclusively on the construction of the object, whereas the benefit of the
idiom derives exclusively from the carefully defined destruction. Saying
"resource acquisition is initialisation" precisely misses the point.
I like "resources are objects".
Tim Butler
...ooo and don't forget the Janitor metaphor -- succinct and evocative.
http://hpsalo.cern.ch/TaligentDocs/TaligentOnline/DocumentRoot/1.0/Docs/book
s/WM/WM_140.html#HEADING165
-tim
Tim Butler
I like
Objects own resources (instead of Objects are resources)
Object lifetime controls resource aquisition.
Who says you can't take it with you?
Tom Payne
> For many years, I've called the classes whose objects do
> something in their ctor and undo it in their dtor
> _Excursion_Classes_.
We need a metaphorical term for objects of such classes, one that
implies leaving things as they were found, perhaps "conservative".
> In a private email, Bjarne Stroustrup said he didn't think that name
> captured the behavior sufficiently,
Agreed.
> but neither does "resource acquisition is initialization" (since it
> doesn't mention the undoing part).
Right. "Acquisition is initialization" is a slogan, not a descriptive
term.
> There have been, no doubt, other names especially for certain
> applications of the idiom, but I know of no single name for the
> idiom.
Right, e.g., lock grabber/releaser objects are often called
"sentries."
> Consequently, I'd like to once and for all (wishful thinking?)
> establish a name for this idiom that is evocative of their
> behavior, yet simple. Opinions?
Good luck. (One of my most difficult tasks as a teacher of computer
science is to try to make sure that students are exposed to the
full range of metaphors and terms for each concept that I teach.)
Tom Payne
Michiel Salters
>
> I like
> Objects own resources (instead of Objects are resources)
> Object lifetime controls resource aquisition.
>
> Who says you can't take it with you?
>
> -tim
Isn't this exception-unsafe?
If objects own resources :
class resources_owner
{
int* resource1;
int* resource2;
public:
resources_owner() { resource1 = new int; resource2 = new int; }
~resources_owner() { delete resource1; delete resource2; }
}
Say either 'resource1 = new int' or 'resource2 = new int' throws.
What happens? There is no way we can prevent a memory leak. We've
got no idea which one threw.
Turning the resources into objects (using auto_ptr<>s) solves
the problem.
Michiel Salters
Pierre Baillargeon
>
> Rob Stewart <donot...@giage.com> wrote:
> > For many years, I've called the classes whose objects do
> > something in their ctor and undo it in their dtor
> > _Excursion_Classes_.
>
> We need a metaphorical term for objects of such classes, one that
> implies leaving things as they were found, perhaps "conservative".
>
I took my cues from the auto_ptr temlate and call such classes
auto-something. For example auto_file, auto_lock, etc.
This name as conotation that things are done automatically (acquisition,
release, exception safety), and recalls the fact that the behavior is
like auto variables.
But the link with acquisition/init, etc is thin. We nned an acronym...
Acquisition Un TOnstructor -> AUTO. Hum... almost.
Acquistion/Unacquisition Totally Object-oriented -> AUTO, better?
Pierre Baillargeon
>
> Rob Stewart <donot...@giage.com> wrote:
> > For many years, I've called the classes whose objects do
> > something in their ctor and undo it in their dtor
> > _Excursion_Classes_.
>
> We need a metaphorical term for objects of such classes, one that
> implies leaving things as they were found, perhaps "conservative".
>
Right after my last posting, I thought about the following longer
acronym:
Acquisition/Unacquisition TOtally MAnaged Through Initialization/Cleanup
yields AUTOMATIC. Yeah!
Rob Stewart
>
> On 25 Feb 2000 21:38:55 -0500, Rob Stewart <donot...@giage.com> wrote:
>
> >For many years, I've called the classes whose objects do
> >something in their ctor and undo it in their dtor
> >he didn't think that name captured the behavior sufficiently, but
> >neither does "resource acquisition is initialization" (since it
> >other names especially for certain applications of the idiom, but
> >I know of no single name for the idiom.
>
> resource acquisition is initialization
> resource de-acquisition is de-initialization
> >;
>
> :)
Thanks for your help Siemel! What would we do without you? :0)
(Note that I also asked for a simple, yet evocative name.)
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Rob Stewart
>
> "Ken Bloom" <ken...@forfree.at> wrote in message
> news:89cm5s$7pe$1...@nntp9.atl.mindspring.net...
> > That doesn't quite imply that it should be done in c'tors/d'tors.
>
> It doesn't. My own reasons for disliking the RAII phrase is that it focuses
> exclusively on the construction of the object, whereas the benefit of the
> idiom derives exclusively from the carefully defined destruction. Saying
> "resource acquisition is initialisation" precisely misses the point.
>
> I like "resources are objects".
Unfortunately, it isn't always about resources. A common use of
this idiom is to change a mouse pointer to an hourglass during a
long process and reset it afterward. There is no resource being
acquired from, nor returned to a pool. Instead, the state of
something is being changed then restored.
That is why I like "excursion class." It is broader.
Rob Stewart
>
> Rob Stewart <donot...@giage.com> wrote in message
> news:38B69675...@giage.com...
> > For many years, I've called the classes whose objects do
> > something in their ctor and undo it in their dtor
> > _Excursion_Classes_. In a private email, Bjarne Stroustrup said
> > he didn't think that name captured the behavior sufficiently, but
> > neither does "resource acquisition is initialization" (since it
> > doesn't mention the undoing part). There have been, no doubt,
> > other names especially for certain applications of the idiom, but
> > I know of no single name for the idiom.
> >
> > establish a name for this idiom that is evocative of their
> > behavior, yet simple. Opinions?
> acquisition is construction, disposal is destruction
What about the "simple" part? Do we call it an ACDD class?
Rob Stewart
>
> ...ooo and don't forget the Janitor metaphor -- succinct and evocative.
>
> http://hpsalo.cern.ch/TaligentDocs/TaligentOnline/DocumentRoot/1.0/Docs/book
> s/WM/WM_140.html#HEADING165
Well, you apparently weren't serious in suggesting the idea, but
"Janitor" isn't half bad. Unfortunately, it only connotes the
cleanup (dtor) part; that's the opposite of "resource acquisition
is initialization."
Rob Stewart
>
> Rob Stewart <donot...@giage.com> wrote:
> > Consequently, I'd like to once and for all (wishful thinking?)
> > establish a name for this idiom that is evocative of their
> > behavior, yet simple. Opinions?
>
> science is to try to make sure that students are exposed to the
> full range of metaphors and terms for each concept that I teach.)
Yes, but we have names for other common things. Iterators are
wide ranging in capabilities and implementation, but one term
covers them all. Patterns can be applied to things to document
their role (consider Memento, and Template Method).
I'm hoping we can settle on something reasonable and bring it
into common parlance to establish it as the normal term. I've
found using "excursion class" a simple moniker to immediately
convey the purpose of a class to my coworkers. We understand the
purpose of such a class immediately with that term. Surely
there's something the C++ community can agree on for this
purpose.
Ross Smith
>
> I like
> Objects own resources (instead of Objects are resources)
> Object lifetime controls resource aquisition.
>
> Who says you can't take it with you?
Now that you mention it, I quite like the idea of calling it the "can't
take it with you" idiom. :-)
--
Ross Smith <ros...@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
"So that's 2 T-1s and a newsfeed ... would you like clues with that?"
-- Peter Da Silva
Tim Butler
> >
> > I like
> > Objects own resources (instead of Objects are resources)
Michiel Salters wrote in message
>
> Isn't this exception-unsafe?
>
> If objects own resources :
>
> class resources_owner
> {
> int* resource1;
> int* resource2;
> public:
> resources_owner() { resource1 = new int; resource2 = new int; }
> ~resources_owner() { delete resource1; delete resource2; }
> }
I was not advocating any specific implementation, especially the
example of intentionally defective code that you provided.
I think you are bringing up two issues:
1. My use of the word "owns" as opposed to "is-a"
2. Using plural object-s own plural resource-s.
First issue 1:
> Turning the resources into objects (using auto_ptr<>s) solves
> the problem.
>
Indeed it does. But I consider an auto_ptr to be an object that
"owns" a resource (namely a block of memory)
not the object that is the resource.
I just like the word "owns" because it expresses a responsiblity for
managing a separate object. You can transfer ownership, you can transfer
a reference to an owned object, or both.
So "owns" is different than "is-a".
For issue 2 (multiple resources):
I prefer to limit a single object owning only a single resource,
but it is still possible for a single object to own multiple resources
-- directly or indirectly.
In your example with auto_ptrs, class resources_owner owns the allocated
memory indirectly because its subobjects own the resources. I prefer that.
class resources_owner could also manage multiple resources directly:
// not preferred but safe (also not compiled :)
resources_owner()
:resource1(0), resource2(0)
try
{ resource1 = new int; resource2 = new int;}
catch(...)
{ delete resource1; delete resource2;
throw;
}
}
Sorry if I am belaboring the point, but it seemed that you might have been
asking for that much precision.
I imagine we are on the same page.
-tim
Anders Pytte
<sal...@lucent.com> wrote:
Tim Butler wrote:
>
> I like
> Objects own resources (instead of Objects are resources)
> Object lifetime controls resource aquisition.
>
> Who says you can't take it with you?
>
> -tim
Isn't this exception-unsafe?
If objects own resources :
class resources_owner
{
int* resource1;
int* resource2;
public:
resources_owner() { resource1 = new int; resource2 = new
int; }
~resources_owner() { delete resource1; delete resource2; }
}
Say either 'resource1 = new int' or 'resource2 = new int' throws.
What happens? There is no way we can prevent a memory leak. We've
got no idea which one threw.
Turning the resources into objects (using auto_ptr<>s) solves
the problem.
Another solution follows:
class resource_owner
{
int* resource1;
int* resource2;
public:
resource_owner() : resource1(NULL), resource2(NULL)
try { resource1 = new int; resource2 = new int; }
catch(...) { delete resource1; delete resource2; }
~resources_owner() { delete resource1; delete resource2; }
}
I agree using auto_ptr is prefereable, but they are an example of what Tim
Butler described, I think.
Anders.
--
Anders Pytte Milkweed Software
192 Cemetery Road Voice: (802) 586-2545
Craftsbury VT 05628 Internet: and...@milkweed.com
Mika Moilanen
Michiel> Isn't this exception-unsafe?
Michiel> If objects own resources :
Michiel> class resources_owner
Michiel> {
Michiel> int* resource1;
Michiel> int* resource2;
Michiel> public:
Michiel> resources_owner() { resource1 = new int; resource2 = new int; }
Michiel> ~resources_owner() { delete resource1; delete resource2; }
Michiel> }
Michiel> Say either 'resource1 = new int' or 'resource2 = new int'
Michiel> throws.
You probably meant "if 'resource2 = new int' throws" because an
exception in the case of the former statement doesn't cause a leak.
--
Best Regards,
Mika
----------------------------------------------------------
mika.m...@shire.ntc.nokia.com phone: +358-0-511-23587
Nokia Networks, PO box 320, FIN-00045 NOKIA GROUP, Finland
----------------------------------------------------------
John B. Williston
wrote:
>Consequently, I'd like to once and for all (wishful thinking?)
>establish a name for this idiom that is evocative of their
>behavior, yet simple. Opinions?
I've always found RAII to be a misnomer for several reasons as well.
Personally, I've referred to RAII in a number of ways. For example,
"resource allocation wrapping", "safe resource acquisition and
release", "resource grab, hold and release", "scoped resource
management".
If you made me choose today, however, I would suggest something
entirely new. What is arguably the most "famous" example of such a
technique? In my estimation it is the auto_ptr. If it is established
that this is an "auto" pointer, then why not an "auto resource"?
John
___ ___
\ \ __ / / Williston Consulting
\ \/ \/ / __________ makes software worth buying.
\ /\ / / _______/
\_/ \_/ / / http://home.zyan.com/~wc
/ /_______ w...@zyan.com
/__________/
Hyman Rosen
> Well, you apparently weren't serious in suggesting the idea, but
> "Janitor" isn't half bad. Unfortunately, it only connotes the
> cleanup (dtor) part; that's the opposite of "resource acquisition
> is initialization."
How about "Butler"? The butler takes your hat and coat when you come in,
and gives them back to you when you leave. And the butler did it :-)
Francis Glassborow
<donot...@giage.com> writes
>Unfortunately, it isn't always about resources. A common use of
>this idiom is to change a mouse pointer to an hourglass during a
>long process and reset it afterward. There is no resource being
>acquired from, nor returned to a pool. Instead, the state of
>something is being changed then restored.
>
>That is why I like "excursion class." It is broader.
I understand your point but the term does not sing to me. And I think
your example is something different from resources even if their is a
concept that encapsulates both.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Lisa Lippincott
But Rob Stewart <donot...@giage.com> offers this objection:
> Unfortunately, it isn't always about resources. A common use of
> this idiom is to change a mouse pointer to an hourglass during a
> long process and reset it afterward. There is no resource being
> acquired from, nor returned to a pool.
I'd think you'd question whether that really is a use of the
idiom in question -- after all, the original question was about
resources.
But, to make a more interesting point, there is indeed a resource
being managed here. The control over the display of the cursor
is a resource requiring management. As proof, I can attest to being
annoyed by programs which mismanage it.
I favor "resources are objects," and the companion slogan
"there are more resources than you think."
--Lisa Lippincott
Ken Bloom
news:sbp4gu...@corp.supernews.com...
>
> I like
> Objects own resources (instead of Objects are resources)
> Object lifetime controls resource aquisition.
>
> Who says you can't take it with you?
>
> -tim
That's the best I've heard yet!!!
Bjarne Stroustrup
Francis Glassborow <fra...@robinton.demon.co.uk> writes:
> In article <38BED4CC...@giage.com>, Rob Stewart
> <donot...@giage.com> writes
> >Unfortunately, it isn't always about resources. A common use of
> >this idiom is to change a mouse pointer to an hourglass during a
> >long process and reset it afterward. There is no resource being
> >acquired from, nor returned to a pool. Instead, the state of
> >something is being changed then restored.
> >
> >That is why I like "excursion class." It is broader.
>
> I understand your point but the term does not sing to me. And I think
> your example is something different from resources even if their is a
> concept that encapsulates both.
It is not easy to find descriptive names for techniques. People who think
that they have found "short and intuitive names" for non-trivial techniques
are usually fooling themselves by never having tested that "intuition"
outside their own local culture.
"resource acquisition is initialization" isn't snappy, but when I coined
it, the technique was new so that no single-word name would have served.
By now, "resource acquisition is initializations" appears in hundreds of
thousands of copies of books and articles. That alone is a reason not to
confuse the issue by introducing 3 or 4 alternatives.
- Bjarne
Bjarne Stroustrup - http://www.research.att.com/~bs
ka...@gabi-soft.de
|> "resource acquisition is initialization" isn't snappy, but when I
|> coined it, the technique was new so that no single-word name would
|> have served. By now, "resource acquisition is initializations"
|> appears in hundreds of thousands of copies of books and
|> articles. That alone is a reason not to confuse the issue by
|> introducing 3 or 4 alternatives.
I agree concerning the current status, but there are two problems:
- The expression doesn't really correspond to idea being considered.
For example, the acquisition of the resource in auto_ptr is not in
the initialization (constructor), and in principle could have
occured much earlier. The key to the idiom is actually "resource
liberation is finalization".
- The expression would result in some pretty awkward type names.
Auto_ptr doesn't really say much, but how many people are prepared
to have to type in "resource_acquisition_is_initialization_ptr" at
each use?
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Jonas Nordin
> For many years, I've called the classes whose objects do
> something in their ctor and undo it in their dtor
> _Excursion_Classes_. In a private email, Bjarne Stroustrup said
> he didn't think that name captured the behavior sufficiently, but
> neither does "resource acquisition is initialization" (since it
> doesn't mention the undoing part). There have been, no doubt,
> other names especially for certain applications of the idiom, but
> I know of no single name for the idiom.
>
> Consequently, I'd like to once and for all (wishful thinking?)
> establish a name for this idiom that is evocative of their
> behavior, yet simple. Opinions?
>
How about "Unwind-Restore"? (cf. the "unwind-protect" special form from
Common LISP.)
Or at least something with the wonderful word "unwind" in it?
/Jonas Nordin
Rob Stewart
>
> I like Ken Hagan's suggestion "resources are objects."
>
> But Rob Stewart <donot...@giage.com> offers this objection:
> > this idiom is to change a mouse pointer to an hourglass during a
> > long process and reset it afterward. There is no resource being
> > acquired from, nor returned to a pool.
>
> idiom in question -- after all, the original question was about
> resources.
As I was the one raising the "original question," I can claim
foul here. Allow me to quote my original post:
<quote>
For many years, I've called the classes whose objects do
something in their ctor and undo it in their dtor
_Excursion_Classes_. In a private email, Bjarne Stroustrup said
he didn't think that name captured the behavior sufficiently, but
neither does "resource acquisition is initialization" (since it
doesn't mention the undoing part). There have been, no doubt,
other names especially for certain applications of the idiom, but
I know of no single name for the idiom.
Consequently, I'd like to once and for all (wishful thinking?)
establish a name for this idiom that is evocative of their
behavior, yet simple. Opinions?
</quote>
My original reason for raising the issue was that I didn't think
the de facto standard name captured the behavior or range of this
idiom precisely because it was resource-specific.
> But, to make a more interesting point, there is indeed a resource
> being managed here. The control over the display of the cursor
> is a resource requiring management. As proof, I can attest to being
> annoyed by programs which mismanage it.
There is no resource being acquired such as when allocating
memory on the free store. The implementation of such a class
might store a pointer or handle to some resource, so in that
sense there is a resource involved. However, the normal notion
of resource is that of a file, or memory, etc., wherein the
"resource acquisition is initialization" object acquires,
represents, and manages the resource. That is, if the new mouse
pointer needed representation and management, then it would be
acquired, used, then released, and would fit in the "R A I I"
mold. The notion of changing the pointer then restoring it is
different. There is no exposed resource to be manipulated and
released.
> I favor "resources are objects," and the companion slogan
> "there are more resources than you think."
I don't think the term is sufficiently broad.
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Rob Stewart
>
> Rob Stewart <donot...@giage.com> writes:
> > Well, you apparently weren't serious in suggesting the idea, but
> > "Janitor" isn't half bad. Unfortunately, it only connotes the
> > cleanup (dtor) part; that's the opposite of "resource acquisition
> > is initialization."
>
> How about "Butler"? The butler takes your hat and coat when you come in,
> and gives them back to you when you leave. And the butler did it :-)
It's a little cutesy, but it does connote the right sorts of
things. I don't know if anyone else will buy it, but I'd use it.
Rob Stewart
>
> On 25 Feb 2000 21:38:55 -0500, Rob Stewart <donot...@giage.com>
> wrote:
>
> >establish a name for this idiom that is evocative of their
> >behavior, yet simple. Opinions?
>
> Personally, I've referred to RAII in a number of ways. For example,
> "resource allocation wrapping", "safe resource acquisition and
> release", "resource grab, hold and release", "scoped resource
> management".
>
> If you made me choose today, however, I would suggest something
> entirely new. What is arguably the most "famous" example of such a
> technique? In my estimation it is the auto_ptr. If it is established
> that this is an "auto" pointer, then why not an "auto resource"?
I don't want to tie this to just resources, so "auto class" might
work. In certain domains, however, there may already be an Auto
class, so this may not be great.
In another post, Hyman Rosen suggested "Butler class." That
doesn't seem to have the same potential for name clashes and does
evoke the "does things for you" and "cleans up after you" sorts
of ideas. What do you think of that?
Francis Glassborow
<donot...@giage.com> writes
>In another post, Hyman Rosen suggested "Butler class." That
>doesn't seem to have the same potential for name clashes and does
>evoke the "does things for you" and "cleans up after you" sorts
>of ideas. What do you think of that?
Well, I do not know how well this crosses the Atlantic but if we want to
go down this kind of route we could have 'batman classes'. No not the
super-hero but in the context of an Officer's batman:) Or we could call
them 'restoration classes' because their task is to return things to the
status quo. The RAII term actually refers to a subset of this concept
and we could say that RAII is a kind of restoration class.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Rob Stewart
>
> Rob Stewart <donot...@giage.com> :
>
> > For many years, I've called the classes whose objects do
> > something in their ctor and undo it in their dtor
> > _Excursion_Classes_. In a private email, Bjarne Stroustrup said
> > he didn't think that name captured the behavior sufficiently, but
> > neither does "resource acquisition is initialization" (since it
> > doesn't mention the undoing part). There have been, no doubt,
> > other names especially for certain applications of the idiom, but
> > I know of no single name for the idiom.
> >
> Common LISP.)
> Or at least something with the wonderful word "unwind" in it?
That isn't quite right, as "unwind" and "restore" both refer to
the dtor action. However, it makes me think of winding a clock
and then of the clock's pendulum swinging back and forth. How
about "pendulum class"?
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Rob Stewart
>
> In article <38C3CBEA...@giage.com>, Rob Stewart
> <donot...@giage.com> writes
> >In another post, Hyman Rosen suggested "Butler class." That
> >doesn't seem to have the same potential for name clashes and does
> >evoke the "does things for you" and "cleans up after you" sorts
> >of ideas. What do you think of that?
Did you have something against "butler class" or are you just not
entirely satisfied with it?
> Well, I do not know how well this crosses the Atlantic but if we want to
> go down this kind of route we could have 'batman classes'. No not the
> super-hero but in the context of an Officer's batman:) Or we could call
> them 'restoration classes' because their task is to return things to the
> status quo. The RAII term actually refers to a subset of this concept
> and we could say that RAII is a kind of restoration class.
I'm afraid I don't understand "batman," even from the information
you gave, so I guess it doesn't cross the Atlantic well.
"Restoration" only covers the latter half of the equation, rather
like RAII covers only the first half. I'm interested in
something that suggests both the "doing" and the "undoing".
That's why I thought "excursion class" worked -- an excursion is
"a movement outward and back or from a mean position" (from
www.m-w.com). It evoked both parts of the action.
"Butler" suggests the idea of management and helping, so while it
doesn't convey the same "out and back" concept, it isn't bad.
Tom Payne
> "Restoration" only covers the latter half of the equation, rather
> like RAII covers only the first half. I'm interested in
> something that suggests both the "doing" and the "undoing".
> That's why I thought "excursion class" worked -- an excursion is
> "a movement outward and back or from a mean position" (from
> www.m-w.com). It evoked both parts of the action.
> "Butler" suggests the idea of management and helping, so while it
> doesn't convey the same "out and back" concept, it isn't bad.
'Restoration' suggests undoing what has been done, though perhaps
by some other entity.
'Conservative' suggests no consumption (or creation) of any resource.
'Stealthy' suggests no tracks of any kind.
But I'm not really keen on any of these. ;-)
Tom Payne
Dean Roddey
auto-cleanup type of class. I have janitor classes for many purposes, and
they are very useful in an exception oriented world.
--------------------------
Dean Roddey
The CIDLib Class Libraries
Charmed Quark Software
dro...@charmedquark.com
http://www.charmedquark.com
"Give me immortality, or give me death"
Hendrik Schober
> In my CIDLib Frameworks, I use the term 'janitor' for any scope based
> auto-cleanup type of class. I have janitor classes for many purposes, and
> they are very useful in an exception oriented world.
"auto cleanup"?
Schobi
--
bitb...@gmx.de is never read
I'm hschober at gmx dot de
John B. Breckenridge
> "Restoration" only covers the latter half of the equation, rather
> like RAII covers only the first half. I'm interested in
> something that suggests both the "doing" and the "undoing".
> That's why I thought "excursion class" worked -- an excursion is
> "a movement outward and back or from a mean position" (from
> www.m-w.com). It evoked both parts of the action.
Since we're calling it RAII, it reminds me that Ra II was the name
of the papyrus boat used by Thor Heyerdahl to cross the Atlantic
in 1970, in an effort to prove that the Egyptians could have
migrated to South America.
Unfortunately, he was not interested in round trips, but otherwise
Ra II would have been a good enough term already, since it was all
about delivering resources from one place to another. Perhaps
"expedition" classes would connote the necessary grandeur
lacking in "excursion."
Christopher Eltschka
[...]
> As I was the one raising the "original question," I can claim
> foul here. Allow me to quote my original post:
>
> <quote>
> For many years, I've called the classes whose objects do
> something in their ctor and undo it in their dtor
> _Excursion_Classes_. In a private email, Bjarne Stroustrup said
> he didn't think that name captured the behavior sufficiently, but
> neither does "resource acquisition is initialization" (since it
> doesn't mention the undoing part). There have been, no doubt,
> other names especially for certain applications of the idiom, but
> I know of no single name for the idiom.
>
> Consequently, I'd like to once and for all (wishful thinking?)
> establish a name for this idiom that is evocative of their
> behavior, yet simple. Opinions?
> </quote>
>
> My original reason for raising the issue was that I didn't think
> the de facto standard name captured the behavior or range of this
> idiom precisely because it was resource-specific.
What about: "Undo on destruction"?
auto_ptr undoes the allocation (by deallocation), the cursor
class undoes the hour glass cursor. (Although auto_ptr isn't
really a RAII class IMHO, since it neither allocates the
ressource, nor necessarily deallocates it - it can pass it on
to another auto_ptr instead -, so it's indeed a simple
ressource _managing_ class).
Another name may be "bracket objects" because they are used
for bracketing some action (RAII objects are automatic objects
and therefore constructed/destructed in a stack-like manner).
Francis Glassborow
<donot...@giage.com> writes
>I'm afraid I don't understand "batman," even from the information
>you gave, so I guess it doesn't cross the Atlantic well.
OK. It is one of those things which those of us divided by a common
language have to watch.
>
>"Restoration" only covers the latter half of the equation, rather
>like RAII covers only the first half. I'm interested in
>something that suggests both the "doing" and the "undoing".
>That's why I thought "excursion class" worked -- an excursion is
>"a movement outward and back or from a mean position" (from
>www.m-w.com). It evoked both parts of the action.
Yes, but not really with the right flavour for me. The advantage of
restoration is that in order to restore you must know what has to be
restored whereas RAII says nothing about why you are using it.
Restoration also includes things other than resource acquisition. To me
RAII is a subset of restoration classes. The term says what it means,
its purpose is to restore something when it is finished with, be that
the screen colours, a hook into the OS or some memory.
>
>"Butler" suggests the idea of management and helping, so while it
>doesn't convey the same "out and back" concept, it isn't bad.
Yes, Butler is more about 'managing' but still does not really sing to
me. If we keep thinking about it we may come up with an adequate brader
term.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Dean Roddey
> > auto-cleanup type of class. I have janitor classes for many purposes,
and
> > they are very useful in an exception oriented world.
> > Dean Roddey
>
> "auto cleanup"?
>
Anything that you want to do on a scoped basis, has to be undone or 'cleaned
up' when you exit that scope. By using these 'janitorial' objects, it
happens automatically when you exit the scope, no matter how you exit,
either by exception or return or just falling through it.
So it would be something like this:
void TFoo::SomeMethod()
{
// Temporarily change the __bState member to true while we are in here
TBoolJanitor janState(&__bState, kCIDLib::True);
// Now, no matter how we get out, __bState will be set back to its
former state
}
That's basically the idea behind all of them. CIDLib has them for all of the
fundamental types, for thread priority, for text stream format, for mutexes
and semaphores and events and critical sections, for dynamically allocated
objects (array and non-array), for enumerated values (that one is
templatized), and so on.
-------------------------
Dean Roddey
The CIDLib Class Libraries
Charmed Quark Software
dro...@charmedquark.com
http://www.charmedquark.com
"Give me immortality, or give me death"
nmus...@my-deja.com
initialization" is an idiom that has such a wide applicability that it
probably means something slightly different to each person.
To me RAII conveys two different notions: first there is a C++ idiom
(possibly applicable also to different languages) where an action is
performed in a class's constructor and the reverse is performed in its
destructor. This is a safer alternative to a scheme where an
"initialize" and a "finalize" member functions are supplied, to be
called respectively before and after every other activity performed on
the object. In this context we could call it something like "Implicit
Initialization & Finalization".
This idiom can be used to implement a design pattern, which is the other
side of the problem, where an object controls an external entity or
resource, and the object state directly models the state of the
resource. We could call this pattern "Direct Model". Note that this
pattern doesn't necessarily require II&F to be implemented: one could
always provide an acquire/release function member pair.
Best regards,
Nicola Musatti
Sent via Deja.com http://www.deja.com/
Before you buy.
Owen Wengerd
>Yes, Butler is more about 'managing' but still does not really sing to
>me. If we keep thinking about it we may come up with an adequate brader
>term.
I'll offer up "steward" as a broader variant of "butler" which also
denotes more responsibility. I personally am satisfied with "manager" for
my use. :)
--
Owen Wengerd
President, ManuSoft ==> http://www.manusoft.com
VP Americas, CADLock, Inc. ==> http://www.cadlock.com
Rob Stewart
>
> Rob Stewart wrote:
>
> > Consequently, I'd like to once and for all (wishful thinking?)
> > establish a name for this idiom that is evocative of their
> > behavior, yet simple. Opinions?
> >
> > the de facto standard name captured the behavior or range of this
> > idiom precisely because it was resource-specific.
>
> What about: "Undo on destruction"?
That fails to describe the "do on construction" aspect. That is,
it has the reverse problem of RAII.
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Jonathan Lundquist
Francis' side of the big pond. I was hoping it would come out in
on-topic conversation.
On 9 Mar 2000 08:02:18 -0500, Francis Glassborow
<fra...@robinton.demon.co.uk> wrote:
>In article <38C50F28...@giage.com>, Rob Stewart
><donot...@giage.com> writes
>>I'm afraid I don't understand "batman," even from the information
>>you gave, so I guess it doesn't cross the Atlantic well.
>
>OK. It is one of those things which those of us divided by a common
>language have to watch.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Rob Stewart
>
> I think that the problem lays in the fact that "resource acquisition is
> initialization" is an idiom that has such a wide applicability that it
> probably means something slightly different to each person.
That's at the heart of my problem. RAII, when taken for what it
says, applies to resource acquisition. It implies, but doesn't
reveal, that it releases the resource when finished.
But the notion of doing something in the ctor and undoing it in
the dtor is broader than resource management. It can include
changing the background color of the screen, managing a database
transaction, etc. These don't mean resources to me. The word
resources connotes to me something like a file, some memory, a
database table, a mutex, etc. It doesn't include the screen
color, for example.
According to http://www.m-w.com, the applicable definition of
"resource" is:
1 a : a source of supply or support : an available means --
usually used in plural b : a natural source of wealth or revenue
-- often used in plural c :
computable wealth -- usually used in plural d : a source of
information or expertise
Screen color is a property or state, not a resource.
Consequently, a class that sets the screen color in its ctor and
restores the original screen color in its dtor is not acquiring a
resource during initialization (and, by implication, releasing it
during destruction), so RAII doesn't adequately describe it.
> To me RAII conveys two different notions: first there is a C++ idiom
> (possibly applicable also to different languages) where an action is
> performed in a class's constructor and the reverse is performed in its
> destructor. This is a safer alternative to a scheme where an
Due to the phrase "resource acquisition" in RAII, it doesn't
connote that to me.
> the object. In this context we could call it something like "Implicit
> Initialization & Finalization".
>
> This idiom can be used to implement a design pattern, which is the other
> side of the problem, where an object controls an external entity or
> resource, and the object state directly models the state of the
> resource. We could call this pattern "Direct Model". Note that this
> pattern doesn't necessarily require II&F to be implemented: one could
> always provide an acquire/release function member pair.
And that is quite separate from what I want to name.
Let me also hasten to add that I'm not advocating that we
eliminate RAII as a moniker for classes that do precisely that.
I'd like to find a term that subsumes but doesn't obviate RAII.
(That is, I'd like to find a more general term that includes RAII
as a special case.)
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Rob Stewart
>
> Francis:
>
> >Yes, Butler is more about 'managing' but still does not really sing to
> >me. If we keep thinking about it we may come up with an adequate brader
> >term.
>
> I'll offer up "steward" as a broader variant of "butler" which also
> denotes more responsibility. I personally am satisfied with "manager" for
> my use. :)
Yes, a steward manages something on your behalf. That loses the
"housekeeping" notion implied by "butler", however.
"Manager" is quite vague and broad. It doesn't connote -- to me
at least -- the specific do/undo behavior I'm looking to
describe. However, I'll concede that neither do "butler" or
"steward". (Let me hasten to add that "excursion" still
describes the in/out, do/undo behavior to me!)
Francis Glassborow
<ow...@manusoft.com> writes
> I'll offer up "steward" as a broader variant of "butler" which also
>denotes more responsibility. I personally am satisfied with "manager" for
>my use. :)
Now 'steward' seems a little more like what I would like.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Rich Churcher
> Way off topic I know, but I'm *still* curious what batman is on
> Francis' side of the big pond. I was hoping it would come out in
> on-topic conversation.
A batman is an officer's manservant, in british military parlance.
Lays out the uniform, shines the boots, serves the tea/gin, etc. As
opposed to a robin, which is a small bird with a red breast.
--
Cheers,
Rich.
Pete Becker
>
> Way off topic I know, but I'm *still* curious what batman is on
> Francis' side of the big pond. I was hoping it would come out in
> on-topic conversation.
>
According to the OED, a batman is "a man in charge of a bat-horse and
its load." Now you know.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)
Francis Glassborow
<j...@sssonline.com> writes
>Way off topic I know, but I'm *still* curious what batman is on
>Francis' side of the big pond. I was hoping it would come out in
>on-topic conversation.
A batman is an 'other rank' person assigned to an officer in the Army to
act as his 'servant' or in more modern terms a personal assistant. By
looking after such things as getting uniforms cleaned etc. a batman
allowed the officer to focus on strategy and tactics etc.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Ken Dyck
> How about "Butler"? The butler takes your hat and coat when you come
in,
> and gives them back to you when you leave. And the butler did it :-)
To me, though, a butler's responsiblities extend beyond just taking
people's hats and coats. How about "Coat-check girl"? (Ya, I know it's
not quite gender-neutral)
Ken
Sent via Deja.com http://www.deja.com/
Before you buy.
{This appears to be drifting off-topic --mod}
nmus...@my-deja.com
Acquisition & Release". I use the term implicit as in the "Implicit
Initialization & Finalization" idiom I described in my previous post, to
indicate the fact that the user of such a class does not have to
explicitly call function members in order to perform resource
acquisition and/or release. An alternative could be "Acquisition is
construction, release is destruction", or AICRID.
Best regards,
Nicola Musatti
Sent via Deja.com http://www.deja.com/
Before you buy.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Tom Leete
>
> Owen Wengerd wrote:
> >
> > Francis:
> >
> > >Yes, Butler is more about 'managing' but still does not really sing to
> > >me. If we keep thinking about it we may come up with an adequate brader
> > >term.
> >
> > denotes more responsibility. I personally am satisfied with "manager" for
> > my use. :)
>
> "housekeeping" notion implied by "butler", however.
>
> "Manager" is quite vague and broad. It doesn't connote -- to me
> at least -- the specific do/undo behavior I'm looking to
> describe. However, I'll concede that neither do "butler" or
> "steward". (Let me hasten to add that "excursion" still
> describes the in/out, do/undo behavior to me!)
>
May I offer "Renter"?
A Renter takes control of a property from an Owner or
Manager. The Renter returns it at the end of the lease,
after settling debts and cleaning house.
Classes which leak resources may then be said to 'flit'.
Tom
Rob Stewart
>
> If I understood you correctly I would suggest "Implicit Resource
> Acquisition & Release". I use the term implicit as in the "Implicit
> Initialization & Finalization" idiom I described in my previous post, to
> indicate the fact that the user of such a class does not have to
> explicitly call function members in order to perform resource
> acquisition and/or release. An alternative could be "Acquisition is
> construction, release is destruction", or AICRID.
IRAR is a better term for Stroustrup's RAII since it covers the
acquisition *and* release portions and indicates that the actions
are implicit. However, I don't want to tie the general term to
resources, as I've mentioned in other articles. Besides, I'm
hoping for is a catchier term.
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
nmus...@my-deja.com
Best regards,
Nicola Musatti
Sent via Deja.com http://www.deja.com/
Before you buy.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Rodgers
news:wMmZvGAXoPy4Ew$1...@robinton.demon.co.uk...
> >denotes more responsibility. I personally am satisfied with "manager"
for
> >my use. :)
>
[Repost: my first attempt at this post seems to have disappeared into
the ether.]
Or what about a Jeeves class? That seems to me to be the ultimate in
responsibility for returning things to the status quo, even when things
get in a mess. :-)
Mark
Andy Glew
It's always seemed to me that the resource acquisition is
pretty explicit, since it is bound to a scoped variable.
So:
Explicitly Acquire Resources
Implicitly Release Resources
EARIRR
or maybe just
"Resources bound to a scoped variable"
{"Managed resources"? "Owned resources"? -mod/hps}
David Leon
part, how about Resource "Ownership is Lifetime "(ROILT?).
Or better yet: "Lifetime Is Resource Ownership" (LIRO), So you can have Liro
objects, write a Liro class for your resource, etc.
Also, somebody mentioned Sentry is used for synchronization. Maybe extending
that to a Resource Sentry?
Personally, I'm a fan of the auto_*. But auto might be too overloaded. Liro
and Sentry sound good to me though. (Not like I count :-)
Have a nice day
David Leon
Rob Stewart
>
> > "Acquire and Release (Resources) Implicitly"; Harry for friends :-)
Cute, but see below.
> It's always seemed to me that the resource acquisition is
> pretty explicit, since it is bound to a scoped variable.
That's not so. std::auto_ptr doesn't acquire its resource; it
just releases it. Creating an automatic variable doesn't mean
its ctor acquires a resource -- or does anything, for that
matter.
> Explicitly Acquire Resources
> Implicitly Release Resources
>
> EARIRR
>
> or maybe just
>
> "Resources bound to a scoped variable"
>
> {"Managed resources"? "Owned resources"? -mod/hps}
Hello? Is anybody out there?
I keep asking that we find something that fits more than just
resource management. I've given definitions and examples
illustrating uses of the do/undo behavior that show that this
applies to more than resources. I don't think anyone disputed
those remarks. Therefore, PLEASE look for names that include but
*transcend* resources. That is the major point of my original
post, and the reason I like "Excursion Classes" and some of the
other suggestions in this thread.
(Of course, if you can make a good case that we should just
consider everything a resource, including the examples I gave,
then I'll give up on the "transcend resources" part that's stuck
in my craw.)
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Rob Stewart
>
> Francis Glassborow <fra...@robinton.demon.co.uk> wrote in message
> news:wMmZvGAXoPy4Ew$1...@robinton.demon.co.uk...
> > In article <ZLPx4.85$Ln2...@cletus.bright.net>, Owen Wengerd
> > <ow...@manusoft.com> writes
> > > I'll offer up "steward" as a broader variant of "butler" which also
> > >denotes more responsibility. I personally am satisfied with "manager"
> for
> > >my use. :)
> >
> > Now 'steward' seems a little more like what I would like.
>
> responsibility for returning things to the status quo, even when things
> get in a mess. :-)
I've heard the name Jeeves, and now it is a stereotypical name
for a butler, but is there a more specific connotation of the
name you're implying? If so, I don't know it. Lacking that, I'm
not sure that saying something is a "Jeeves" class is an
improvement over saying it is a "Steward" or "Butler" class.
(BTW, I'm not sure I like "Steward" so well. I keep typing
"Stewart"!)
Christopher Eltschka
>
> Since "Resource adquisition is initialization" doesn't capture the release
> part, how about Resource "Ownership is Lifetime "(ROILT?).
Remove the "Ressource" and abbreviate "Lifetime" with just one
letter, and you get OIL ;-)
>
> Or better yet: "Lifetime Is Resource Ownership" (LIRO), So you can have Liro
> objects, write a Liro class for your resource, etc.
But that's something else. Given that a non-existant object
cannot own anything, this phrase actually says "the ownership
cannot be released or given to another object". Well, most
OIL objects are also LIRO objects, but look at auto_ptr.
[...]
Barry Wallis
> Mark Rodgers wrote:
[...]
> > Or what about a Jeeves class? That seems to me to be the ultimate in
> > responsibility for returning things to the status quo, even when things
> > get in a mess. :-)
>
> I've heard the name Jeeves, and now it is a stereotypical name
> for a butler, but is there a more specific connotation of the
> name you're implying? If so, I don't know it. Lacking that, I'm
> not sure that saying something is a "Jeeves" class is an
> improvement over saying it is a "Steward" or "Butler" class.
The original Jeeves was the prototypical butler to Bertie Wooster (both were
characters created by P. G. Wodehouse). Jeeves' function in life was to fix
up the messes into which Wooster was constantly entangling himself )see
http://www.amazon.com/exec/obidos/search-handle-form/103-8789872-5819826 for
further info).
--
Barry L. Wallis, Senior Systems Engineer
Science Applications International Corporation
4161 Campus Point Court
San Diego, CA 92121
_____
"In all labor there is profit, but mere talk leads to poverty."
- King Solomon
John G Harris
Wallis <m...@mine.com> writes
<snip>
>The original Jeeves was the prototypical butler to Bertie Wooster (both were
>characters created by P. G. Wodehouse). Jeeves' function in life was to fix
>up the messes into which Wooster was constantly entangling himself )see
>http://www.amazon.com/exec/obidos/search-handle-form/103-8789872-5819826 for
>further info).
Let's get our analogies straight :-)
Jeeves was a valet, or "gentleman's gentleman", not a butler.
A butler serves a family. He supervises the family dinner, and cleans
the family silver. A valet does not.
A valet serves one gentleman. He cooks breakfast for him if needed and
cleans his shoes. A butler does not.
Really, I don't think either job includes tidy disposal of his employer,
though there was one Wodehouse story ...
John
--
John Harris
mailto:jo...@jgharris.demon.co.uk
Mark Rodgers
> for a butler, but is there a more specific connotation of the
> name you're implying?
Jeeves was valet (or "gentleman's personal gentleman") to one
Bertie Wooster in the books by P.G. Wodehouse. Bertie was forever
getting in a mess, and Jeeves could always be relied on to return
things to the status quo. This preservation of the status quo
even extended to such things as eliminating items in poor taste
from Bertie's wardrobe, and ensuring Bertie remained a bachelor.
It is this ability to return things to their former state (release
resources) even when things get in a mess (an exception is thrown)
that struck me as very like RAII. As Bertie says in _Carry on,
Jeeves_, "I gave up trying to run my own affairs within a week of
his coming to me." Similarly, I gave up trying to release my one
resources within a week of discovering RAII.
Mark
Rob Stewart
>
> It is this ability to return things to their former state (release
> resources) even when things get in a mess (an exception is thrown)
> that struck me as very like RAII. As Bertie says in _Carry on,
> Jeeves_, "I gave up trying to run my own affairs within a week of
> his coming to me." Similarly, I gave up trying to release my one
> resources within a week of discovering RAII.
This analogy is apt, but apparently not well known. We can
change that, of course, by using it and adding a FAQ defining it.
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Hendrik Schober
> [...]
> Hello? Is anybody out there?
Yes. (It's a busy thread, after all! ;^) )
> I keep asking that we find something that fits more than just
> resource management. I've given definitions and examples
> illustrating uses of the do/undo behavior that show that this
> applies to more than resources. I don't think anyone disputed
> those remarks. Therefore, PLEASE look for names that include but
> *transcend* resources. That is the major point of my original
> post, and the reason I like "Excursion Classes" and some of the
> other suggestions in this thread.
I'm not that good in English, but I'll have another try:
Since it's already discovered that not only RAII misses
the second part of the pattern, but also at least one very
important examply ('auto_ptr<>') doesn't even aquire a
resource itself, we should focus on this second part.
So how about something using the "undo" that you mentioned
above? "Automatic undo"? (Clumsy, isn't it?)
> (Of course, if you can make a good case that we should just
> consider everything a resource, including the examples I gave,
> then I'll give up on the "transcend resources" part that's stuck
> in my craw.)
I'm pretty sure one could argue for everything to be a
resource.
> Robert Stewart | rob-at-giage-dot-com
Schobi
--
bitb...@gmx.de is never read
I'm hschober at gmx dot de
Francis Glassborow
<pedw...@dmapub.dma.org> writes
>Given the Jeeves analogy, of returning to the status quo, I'd go for that
>one. (Is there a political science term for what an ascending political
>party does? How they spend their term just reverting the previous party's
>changes, thereby going back to the status quo? We could use that term,
>if doing so won't be gratuitously cynical.)
I rather like the Jeeves proposal. RAII would be one example of a
Jeeves class, but things like changing and restoring screen colours
would be another.
>
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pierre Baillargeon
>
> I rather like the Jeeves proposal. RAII would be one example of a
> Jeeves class, but things like changing and restoring screen colours
> would be another.
>
The problem I see with Jeeves:
1. The meaning is very cultural-dependent. I had no idea who Jeeves was.
I believe it is somewhat a UK thing.
2. Let's not forget that a good word must provoke the association in the
"word" -> RAII direction, while I feel that most propositions have
emerged from the RAII -> "word" direction. I feel that the idea of
butler does convey the pattern, even though the pattern may elicit such
an association.
3. The main point of RAII is actually the destructor releasing the
resource. After all, the pattern emerged, partly, as a way of writing
exception safe code. Also, many RAII classes actually do nothing in
their constructor. auto_ptr is an example, and most of my own classes
are pretty much like it.
So, taking those three points in consideration, what proposed word fits
best? My feeling go toward "Janitor". But I also believe that auto_ptr
created a precedent, and I intend to stick with the "auto" prefix until
something really compelling comes along.
David Leon
Pierre Baillargeon wrote in message <38D8E2A8...@artquest.net>...
>
>3. The main point of RAII is actually the destructor releasing the
>resource. After all, the pattern emerged, partly, as a way of writing
>exception safe code. Also, many RAII classes actually do nothing in
>their constructor. auto_ptr is an example, and most of my own classes
>are pretty much like it.
Then how about "Finally" classes, since many people would understand this
meaning directly and the whole point seems to be to make up for C++'s lack
of a finally keyword.
On a related topic: (I didn't find this in a FAQ anywhere)
-Why doesn't C++ provide finally? It cannot be that hard to implement since
destructors are called in a hidden finally block anyway. Even though some of
these RAII classes do make sense (auto_ptr is a pointer, i.e. it is
something), some just seem like hacks to make sure that things get cleaned
up (like returning the screen to its previous color strikes me as an action,
not an object). In this cases, a finally block would be more elegant.
-Is C++ ever going to provide finally? It seems that people are seeing the
need for it. Is this something that could be revised into the standard?
Thanks
David Leon
Francis Glassborow
<p...@artquest.net> writes
>So, taking those three points in consideration, what proposed word fits
>best? My feeling go toward "Janitor". But I also believe that auto_ptr
>created a precedent, and I intend to stick with the "auto" prefix until
>something really compelling comes along.
Once someone has had Wooster's Jeeves explained the idea generally
sticks (and it works in many cultures). You are not tempted to replace
it with a job title from your own culture (though mentally you may think
Jeeves is a kind of... -- whatever fits in your culture). The problem
with terms like 'butler' or 'janitor' is that they are culturally
specific. Even if the same word is used in several English speaking
countries they will have different connotations. If someone has never
come across Jeeves in literature they will ask for an explanation,
having had it they will almost certainly remember it and probably
appreciate the humour. To my mind that is the best form of 'jargon', it
makes sense when you understand but if you do not understand you will
ask.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pierre Baillargeon
>
> I feel that the idea of
> butler does convey the pattern, even though the pattern may elicit such
> an association.
>
To clarify this, a "not" should be inserted. The sentence should read:
"I feel that the idea of butler does **not** convey the pattern, even
though the
pattern may elicit such an association."
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Hyman Rosen
> Then how about "Finally" classes, since many people would understand this
> meaning directly and the whole point seems to be to make up for C++'s lack
> of a finally keyword.
This seems quite backwards to me. C++ existed many years before Java did,
so Java's finally keyword is clearly there to make up for its lack of
destructors.
Rob Stewart
>
> "Rob Stewart" <donot...@giage.com> schrieb im Newsbeitrag news:38D140D9...@giage.com...
> > [...]
> > Hello? Is anybody out there?
>
> Yes. (It's a busy thread, after all! ;^) )
Thanks. You're right. I was just getting frustrated that no one
was addressing the issues I was raising!
> > I keep asking that we find something that fits more than just
> > resource management. I've given definitions and examples
> > illustrating uses of the do/undo behavior that show that this
> > applies to more than resources. I don't think anyone disputed
> > those remarks. Therefore, PLEASE look for names that include but
> > *transcend* resources. That is the major point of my original
> > post, and the reason I like "Excursion Classes" and some of the
> > other suggestions in this thread.
>
> I'm not that good in English, but I'll have another try:
> Since it's already discovered that not only RAII misses
> the second part of the pattern, but also at least one very
> important examply ('auto_ptr<>') doesn't even aquire a
> resource itself, we should focus on this second part.
> So how about something using the "undo" that you mentioned
> above? "Automatic undo"? (Clumsy, isn't it?)
But that focuses on only the latter half (by your own admission),
which is the opposite problem. I'm looking for a name for the
whole enchilada. That doesn't preclude specialized subsets, of
course.
The biggest problem is that to undo something, you must do it
first. Consequently, auto_ptr is a unique animal among the type
I'm trying to classify. It assumes you give it something for
which a specific release operation is required. That suggests it
belongs to the "Auto Delete" or "Deleter" group of classes.
> > (Of course, if you can make a good case that we should just
> > consider everything a resource, including the examples I gave,
> > then I'll give up on the "transcend resources" part that's stuck
> > in my craw.)
>
> I'm pretty sure one could argue for everything to be a
> resource.
Give it a go!
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Rob Stewart
>
> Francis Glassborow wrote:
> >
> > I rather like the Jeeves proposal. RAII would be one example of a
> > Jeeves class, but things like changing and restoring screen colours
> > would be another.
>
> The problem I see with Jeeves:
>
> 1. The meaning is very cultural-dependent. I had no idea who Jeeves was.
> I believe it is somewhat a UK thing.
This is certainly a problem, but it isn't too difficult to
overcome. Something more universal would be better, but what?
> 2. Let's not forget that a good word must provoke the association in the
> "word" -> RAII direction, while I feel that most propositions have
> emerged from the RAII -> "word" direction. I feel that the idea of
> butler does convey the pattern, even though the pattern may elicit such
> an association.
The "Excursion Class" idea includes the idea of a round trip.
However, in a specialized subcategory, one could conceive of a
one-way ticket, hence only the ctor does something or only the
dtor does something. IOW, RAII is concerned with getting and
releasing a resource -- despite the name -- so it fits the
pattern. auto_ptr is only concerned with releasing a resource,
so it is a member of a subcategory in which only the dtor does
something.
> 3. The main point of RAII is actually the destructor releasing the
> resource. After all, the pattern emerged, partly, as a way of writing
> exception safe code. Also, many RAII classes actually do nothing in
> their constructor. auto_ptr is an example, and most of my own classes
> are pretty much like it.
I disagree. RAII, as the name implies, is concerned with
"Resource Acquisition."
> So, taking those three points in consideration, what proposed word fits
> best? My feeling go toward "Janitor". But I also believe that auto_ptr
> created a precedent, and I intend to stick with the "auto" prefix until
> something really compelling comes along.
If auto_ptr is the pattern, then it only applies to the release
in the dtor type of class. That is a subset of the classes I'm
trying to name. In fact, neither "Janitor" nor "Auto" (if
auto_ptr is the archetype for "Auto") fit RAII because they
connote only the cleanup (undo) part of the equation. (A typical
janitor may actually be responsible to set up things as well as
clean afterward, so "Janitor" may fit better than it first struck
me.)
Biju Thomas
>
> Once someone has had Wooster's Jeeves explained the idea generally
> sticks (and it works in many cultures). You are not tempted to replace
> it with a job title from your own culture (though mentally you may think
> Jeeves is a kind of... -- whatever fits in your culture). The problem
> with terms like 'butler' or 'janitor' is that they are culturally
> specific. Even if the same word is used in several English speaking
> countries they will have different connotations. If someone has never
> come across Jeeves in literature they will ask for an explanation,
> having had it they will almost certainly remember it and probably
> appreciate the humour. To my mind that is the best form of 'jargon', it
> makes sense when you understand but if you do not understand you will
> ask.
>
I never knew who/what Jeeves was. (I never read any P.G. Wodehouse
works. Never heard anybody mentioning his works as significant or great.
Of course, I am not such an avid reader of novels, got better things to
do, like reading newsgroups.)
After reading the posts here giving 'Jeeves' the best-name-for-RAII
award, it doesn't stick with me.
So,
--votesForJeeves;
Out of the names proposed so far, the best one I liked was
bracket-classes. Mainly because it has an immediate connection to C++
syntax and the way RAII works.
--
Biju Thomas
Gerhard Menzl
> -Why doesn't C++ provide finally? It cannot be that hard to implement
> since destructors are called in a hidden finally block anyway. Even
> though some of these RAII classes do make sense (auto_ptr is a
> pointer, i.e. it is something), some just seem like hacks to make sure
> that things get cleaned up (like returning the screen to its previous
> color strikes me as an action, not an object).
Actions modelled as objects are a perfectly common OO idiom, especially
in C++. Functors play a prominent role in the C++ Standard Library, for
exmaple. I don't see what is wrong with a ScreenChanger class.
> In this cases, a finally block would be more elegant.
I don't think so.
> -Is C++ ever going to provide finally? It seems that people are seeing
> the need for it. Is this something that could be revised into the
> standard?
I hope not. In my opinion, the finally idiom is inferior to RAII classes
because it requires the user to code the clean-up code manually, every
time a resource is used. With RAII, on the other hand, you code it once
in the destructor, and clean-up is performed automatically, by benign
intervention of the compiler. This is much less error-prone. Just
compare this piece of client code:
void X::f ()
{
ScreenChanger sc (blue);
//...
}
to this one:
void X::f ()
{
ScreenColour oldcolour;
try
{
oldcolour = ChangeScreenColour (blue);
// ...
}
finally
{
ChangeScreenColour (oldcolour);
}
}
and tell me which is cleaner, safer, and allows you to focus on whatever
//... stands for.
"finally" would have been a godsend in C, but C++ has destructors and
RAII, which take automation one step further.
Gerhard Menzl
Hendrik Schober
> [...]
> > So how about something using the "undo" that you mentioned
> > above? "Automatic undo"? (Clumsy, isn't it?)
>
> But that focuses on only the latter half (by your own admission),
> which is the opposite problem. I'm looking for a name for the
> whole enchilada. That doesn't preclude specialized subsets, of
> course.
>
> The biggest problem is that to undo something, you must do it
> first. Consequently, auto_ptr is a unique animal among the type
> I'm trying to classify. It assumes you give it something for
> which a specific release operation is required. That suggests it
> belongs to the "Auto Delete" or "Deleter" group of classes.
I don't think the name should reflect ressource
aquisition. That's because I don't think auto_ptr
is so special. I see it as an important pattern:
Aquisition of resources is often more complicated
than releasing. You need different numbers of
different arguments and maybe you have to pick
among several aquisition possibilities. OTOH
releasing a ressource is commonly a simple task.
Given that it's easier to have RAII classes that get
the ressources passed to their ctor and perform only
the second part.
> > I'm pretty sure one could argue for everything to be a
> > resource.
>
> Give it a go!
Give me an example of something that can be done by
RAII, but isn't a ressource.
> Robert Stewart | rob-at-giage-dot-com
Schobi
--
bitb...@gmx.de is never read
I'm hschober at gmx dot de
Graham Borland
> Consequently, I'd like to once and for all (wishful thinking?)
> establish a name for this idiom that is evocative of their
> behavior, yet simple. Opinions?
Roadie.
They unload the tour bus and set up all your gear before the gig, and
disassemble and pack it all again afterwards.
--
Graham Borland Picsel Technologies Ltd
gra...@picsel.com Glasgow, Scotland
Barry Wallis
[...]
>(A typical
> janitor may actually be responsible to set up things as well as
> clean afterward, so "Janitor" may fit better than it first struck
> me.)
Oh, you mean a Stage Manager class. :-) In theater a SM is responsible for
making sure all the props are set up before the scene and put away afterward
(if there are enough people in the company the SM will actually manage them
so they do the work).
John B. Williston
>If you made me choose today, however, I would suggest something
>entirely new. What is arguably the most "famous" example of such a
>technique? In my estimation it is the auto_ptr. If it is established
>that this is an "auto" pointer, then why not an "auto resource"?
After reading all the posts in response to my own suggesting 'butler',
'Jeeves', 'finally', etc., I still don't see what's wrong with my own
suggestion. Why not 'auto-resource'? It has a precedent in the C++
pantheon already (viz., auto_ptr), and seems less of a fanciful
departure than any of these other suggestions.
The only complaint I've seen thus far that seems legitimate is that
this idiom may be used for things other than resources. This may be
true, but I would respond along two lines. First, as I review my own
code, I find nowhere that the idiom is employed and does not involve
resources. And second, the current widely-known name (RAII) refers
explicitly to resources; since I have seen no complaint about RAII
being too specific to resources, and since my own suggestion could be
taken as having its roots in the semi-canonical name, I see no reason
to grant the complaint much force.
At any rate, I still think auto_resource is the best suggestion I've
seen thus far (grin).
John
___ ___
\ \ __ / / Williston Consulting
\ \/ \/ / __________ makes software worth buying.
\ /\ / / _______/
\_/ \_/ / / http://home.zyan.com/~wc
/ /_______ w...@zyan.com
/__________/
Andrei Alexandrescu
I've been reading this thread for a long time and I couldn't find a killer
name for the idiom.
I definitely don't like Jeeves, stewar(d|t), butler. The sheer fact that
they have to be explained dismisses them.
I disagree that the constructor is important. An RAII class that does
something in the constructor and nothing in the destructor is not an RAII
class, period. Could be replaced with one function call. In RAII, it's
fundamental for calls to be paired.
Of course I'll add my 2c, right?
IMHO acquisition is NOT the fundamental part of the idiom. For many classes
it's done externally. Think of auto_ptr, as someone else noted.
What's fundamental is that an undo function is queued following C++
invariants regarding object destruction.
I use in my code a Reminder class that, on the contrary, deals only with
destruction:
FILE* text = std::fopen("ISO+IEC+14882-1998.pdf", "r");
Reminder closeText(std::fclose, text);
void* buffer = std::malloc(1024);
Reminder freeBuffer(std::free, buffer);
I don't even need a specialized class FileWrapper that holds a pointer to
the FILE etc. I'd find it awkward to wrap every single CRT/API pair of
function calls in a class.
So I think a better search for a name should put emphasis on the destructor
part, not at the constructor part. Like: "Destructors Free Resources".
Andrei
John B. Breckenridge
> in the dtor type of class. That is a subset of the classes I'm
> trying to name. In fact, neither "Janitor" nor "Auto" (if
> auto_ptr is the archetype for "Auto") fit RAII because they
> janitor may actually be responsible to set up things as well as
> clean afterward, so "Janitor" may fit better than it first struck
> me.)
I think the concept to stress is "Put everything back the way you found it."
What's the buzzword they use for "Take only memories, leave only footprints"
hikers? Something like Zero Environmental Impact.
Thomas Matelich
> Pierre Baillargeon wrote:
> >
> > Francis Glassborow wrote:
> > >
> > > I rather like the Jeeves proposal. RAII would be one example of a
> > > Jeeves class, but things like changing and restoring screen colours
> > > would be another.
> >
> > The problem I see with Jeeves:
> >
> > 1. The meaning is very cultural-dependent. I had no idea who Jeeves was.
> > I believe it is somewhat a UK thing.
>
> This is certainly a problem, but it isn't too difficult to
> overcome.
Another thing to overcome is (unfortunately) whenever I hear Jeeves, I think
of ask.com and their insipid commercials.
This is probably a little weak but here goes anyway. Body and Soul. The
body is our class, the soul is the resource. Upon creation, the body gets,
or is imparted with, a soul. Upon destruction, the soul is released or
destroyed. Most of the religious and secular beliefs can be tweaked to work
with this. Nicely we refer to the amount of time a body (and an object) is
around as a lifetime. And if you want to further classify it, things which
destroy their souls are sinners, and things which release their souls are
<Holy War guard, I just calls 'em as I believes 'em> Christians. If that
offends you ignore it. The only part I don't like is the name Body and Soul,
can you think of a synonym? Organic Objects?
--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sose...@usa.net
tmat...@zetec.com
Mr Anonymous
>I'm looking for a name for the whole enchilada.
Rob,
I don't think there is any need to create a special
name for them - they are just objects.
By definition, all objects have a lifecycle. The
lifecycle in this case is usually bound to that of
it's parent object or function.
Objects are normally well-behaved citizens.
If they aquire resources, then they must give
them back when they are destroyed, or else
hand over responsibility to another like-minded
object.
If a statement to this effect was in the C++
standard, then perhaps they could be called
"Conforming Objects" or
"Well-behaved Objects" ?
Cheers,
Mr Anonymous.
David Leon
>"David Leon" <dzl...@yahoo.com> writes:
>> Then how about "Finally" classes, since many people would understand this
>> meaning directly and the whole point seems to be to make up for C++'s
lack
>> of a finally keyword.
>
>This seems quite backwards to me. C++ existed many years before Java did,
>so Java's finally keyword is clearly there to make up for its lack of
>destructors.
Alright, alright. I forgot I'm talking to picky people :-)
If the C++ comunity objects to using "finally" as it comes from Java (I'm
not much of a Java person either), then how about "Tilde" classes (You know
from the tilde in the destructors)
Besides, even if a finally-like costruct is added to C++, it doesn't have to
use the finally keyword (so as not to add another to the language). You
could do something like try{ ... } ~try { ...} etc. Where ~try is your
finally block. (and this wouldn't break code since no existing code has ~try
in it, whereas it might have finally)
Anyway, Tilde/Finally would only apply to classes that do only destrcution,
but don't allocate resources (see other posts in this thread). So it would
be a special case of a auto_*/Jeeves/Janitor/excursion/Liro/OIL/Lifetime
binder/Lifetime something/whatever.
I guess the big question is: What exactly is RAII? does it include:
-Allocating resources? (At initialization? During its lifetime?)
-Deallocating resources on destruction?
-Yielding resources? (get/reset/etc)
-Resources? Or just cleanup in general?
Depending which combination of the above you want, you get a different name.
Which one is the general case?
David Leon
Mark Rodgers
> > 1. The meaning is very cultural-dependent. I had no idea who
> > Jeeves was. I believe it is somewhat a UK thing.
>
> This is certainly a problem, but it isn't too difficult to
I don't think it is true at all. After all, I proposed it and I
am as far from the UK as it is possible to get on this planet! :-)
Initially I proposed the name only in jest, but that changed when
Francis Glassborow raised a very valid point. Whereas words like
"butler" and "janitor" are language and culture specific, ("janitor"
sounds _so_ American to my ears - we prefer "caretaker"), a proper
noun rises above that. It doesn't require translation into other
languages, so can be used by anyone. The name could equally be sourced
from American, French, Japanese, or whatever literature instead, and
we could still all use it.
So I think "Jeeves" _is_ universal whereas "janitor" definitely is
not. Once the name is explained, I think the idea would stick, and
it is somewhat less dry than the alternatives I have seen presented
so far.
[This reminds me of "Cheshire Cat" classes. Has that phrase died
out?]
Mark
Ian Knowles
>... I'm looking for a name for the
>whole enchilada. That doesn't preclude specialized subsets ...
I think that the one name for both a standard RAII class and the
auto_ptr variation is going to very difficult - what do think about
the following two?
"Lender" (i.e. the user of a Lender class instance is "borrowing"
something)
"Finalizer" (this might also appeal to the Java fans ;)
Regards,
Ian Knowles (remove the .nospam to reply)
Andy Glew
> > the need for it. Is this something that could be revised into the
> > standard?
>
> I hope not. In my opinion, the finally idiom is inferior to RAII classes
I agree: finally is considerably less powerful than RAII / undo class objects
that manage resources via scoping.
Also, historically, finally clauses preceded C++. Several Pascal/Simula
derived minor languages had finally clauses.
Another big problem with finally clauses is that they clutter the code,
if many resources are being managed.
For example:
{
auto_ptr<X> r1 = acquire_resource1();
code1;
auto_ptr<X> r2 = acquire_resource2();
code12;
auto_ptr<X> r3 = acquire_resource3();
code3;
}
How should you code the finally blocks for this?
Some people do:
{
try {
X* r1 = acquire_resource1();
code1;
}
finally {
release_resource1();
}
try {
X* r2 = acquire_resource2();
code2;
}
finally {
release_resource2();
release_resource1();
}
try {
X* r3 = acquire_resource3();
code3;
}
finally {
release_resource3();
release_resource2();
release_resource1();
}
}
I hope that you can see the problem caused by signals
or other events happening between the blocks. To be safe,
you must nest:
{
try {
X* r1 = acquire_resource1();
code1;
try {
X* r2 = acquire_resource2();
code2;
try {
X* r3 = acquire_resource3();
code3;
}
finally {
release_resource3();
}
}
finally {
release_resource2();
}
}
finally {
release_resource1();
}
}
and even this has potential problems,
Neither of the finally solutions is concise.
The "finally"oach had been tried by many languages
for years before C++. While it works in limited situations,
it is not general; it was not general enough to catch on.
If finally is adopted by C++, it will have to be considered
a "training wheel", and advanced C++ books will have to
deprecate finally, described how finally code can be converted
to RAII code.
John Potter
<andre...@hotmail.com> wrote:
: I've been reading this thread for a long time and I couldn't find a killer
: name for the idiom.
Agreed. The idiom has a very good name. It is a practice not a class.
Trying to give a name to things which are used in an idiom may be the
problem with this thread. What is the following structure called?
int x;
while (cin >> x)
doSomethingWith(x);
As opposed to
for (cin >> x; cin; cin >> x)
doSomethingWith(x);
As opposed to
cin >> x;
while (cin) {
doSomethingWith(x);
cin >> x;
}
: I disagree that the constructor is important. An RAII class that does
: something in the constructor and nothing in the destructor is not an RAII
: class, period. Could be replaced with one function call. In RAII, it's
: fundamental for calls to be paired.
:
: IMHO acquisition is NOT the fundamental part of the idiom. For many classes
: it's done externally. Think of auto_ptr, as someone else noted.
:
: What's fundamental is that an undo function is queued following C++
: invariants regarding object destruction.
Agreed. RAII involves initializing an object to dispose of a resource
at the point in time when it is acquired. If the object also acquires
the resource, it is just a normal object and RAII moves into the
internals of the class.
: I use in my code a Reminder class that, on the contrary, deals only with
: destruction:
:
: FILE* text = std::fopen("ISO+IEC+14882-1998.pdf", "r");
: Reminder closeText(std::fclose, text);
: void* buffer = std::malloc(1024);
: Reminder freeBuffer(std::free, buffer);
:
: I don't even need a specialized class FileWrapper that holds a pointer to
: the FILE etc. I'd find it awkward to wrap every single CRT/API pair of
: function calls in a class.
Yes.
: So I think a better search for a name should put emphasis on the destructor
: part, not at the constructor part. Like: "Destructors Free Resources".
Or, just leave things alone. The name says exactly what the idiom does.
John
Andrei Alexandrescu
news:HGUC4.55837$3b6.2...@ozemail.com.au...
> "Lender" (i.e. the user of a Lender class instance is "borrowing"
> something)
:o[
> "Finalizer" (this might also appeal to the Java fans ;)
:o)
I like the "Finalizer" idea, especially because I see the idiom as being
much more concerned with scoped destruction, than with resource acquisition.
I will rename Reminder to Finalizer. Look how cool it is:
FILE* text = std::fopen("ISO+IEC+14882-1998.pdf", "r");
Finalizer closeText(std::fclose, text);
void* buffer = std::malloc(1024);
Finalizer freeBuffer(std::free, buffer);
You can either Commit() a Finalizer object, or Dismiss() it - if you decide
you want to take over the ownership of the resource. If you don't Dismiss()
it, its destructor does a Commit().
About "Jeeves". I don't agree with Mark Rodgers. I think Jeeves is way too
cultural specific. Whenever I hear Jeeves, I think of nothing else but
ask.com. I didn't read anything about that guy Jeeves, and I doubt a
non-negligible part of the programming community did.
Let me be a bit more specific: I don't like Jeeves. Jeeves is out. No
Jeeves. Jeeves sucks. Jeeves must be shot to death. Jeeves must be stoned. I
don't negotiate about Jeeves. Let's make Jeeves just a bad memory of this
newsgroup. Please found The Anti-Jeeves Commitee. :o)
Andrei
Phil Edwards
Graham Borland <gra...@picsel.com> wrote:
+ Rob Stewart wrote:
+ > Consequently, I'd like to once and for all (wishful thinking?)
+ > establish a name for this idiom that is evocative of their
+ > behavior, yet simple. Opinions?
+
+ Roadie.
+
+ They unload the tour bus and set up all your gear before the gig, and
+ disassemble and pack it all again afterwards.
Thus opening up a whole new realm of descriptive terms for bugs in those
kinds of classes. "Dude, your roadie class was stoned again when it tried
to pack up the tour bus. Some memory got left behind outside the arena."
Luck++;
Phil
(So, what's a "groupie" idiom do to the code?)
Michiel Salters
> Ian Knowles <i...@who.net.nospam> wrote in message
> :o)
> I like the "Finalizer" idea, especially because I see the idiom as being
> much more concerned with scoped destruction, than with resource acquisition.
> I will rename Reminder to Finalizer. Look how cool it is:
> FILE* text = std::fopen("ISO+IEC+14882-1998.pdf", "r");
> Finalizer closeText(std::fclose, text);
> void* buffer = std::malloc(1024);
> Finalizer freeBuffer(std::free, buffer);
Does this work?
I take it you want to use a pointer to a standard library function?
I can't parse the first argument any other way. However, I believe
there was a rule you couldn't take the address of a function in the
standard library, because you didn't know its signature, because
implementors might add defaulted arguments.
(But you might get away with ::free, because a valid C program
must be able to use that address. )
Looks like one of those "nice if it worked, but is doesn't" ideas,
unfortunately.
Michiel Salters
Hendrik Schober
> [...]
> "Finalizer" (this might also appeal to the Java fans ;)
I vote for this!
It is easy to understand and doesn't need a lot
of explanation. It is also easy to remember. And
it focusses on this part of the pattern which
IMHO is the most important. (That's what the whole
thing was invented for, after all.)
> Regards,
> Ian Knowles (remove the .nospam to reply)
Schobi
--
bitb...@gmx.de is never read
I'm hschober at gmx dot de
Hendrik Schober
> [...] Look how cool it is:
>
> FILE* text = std::fopen("ISO+IEC+14882-1998.pdf", "r");
> Finalizer closeText(std::fclose, text);
> void* buffer = std::malloc(1024);
> Finalizer freeBuffer(std::free, buffer);
>
> you want to take over the ownership of the resource. If you don't Dismiss()
> it, its destructor does a Commit().
I've seen these guys mentioned before.
What makes me wonder is how you pass different
types to what seems to be a ctor without
specifying a template arg to what seems to be
a class.
> [...]
> Let me be a bit more specific: I don't like Jeeves. Jeeves is out. No
> Jeeves. Jeeves sucks. Jeeves must be shot to death. Jeeves must be stoned. I
> don't negotiate about Jeeves. Let's make Jeeves just a bad memory of this
> newsgroup. Please found The Anti-Jeeves Commitee. :o)
Seems like this group is a place to brush up
my English... ;^>
> Andrei
John B. Williston
wrote:
>Roadie.
>
>They unload the tour bus and set up all your gear before the gig, and
>disassemble and pack it all again afterwards.
Obviously, you've never experienced roadies... (grin)
John
___ ___
\ \ __ / / Williston Consulting
\ \/ \/ / __________ makes software worth buying.
\ /\ / / _______/
\_/ \_/ / / http://home.zyan.com/~wc
/ /_______ w...@zyan.com
/__________/
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
<mark.r...@xtra.co.nz> writes
>[This reminds me of "Cheshire Cat" classes. Has that phrase died
>out?]
For some reason people want to seek names that immediately transmit
concepts without any explanation. IMO this is deeply flawed. Something
with an entirely obvious connotation to me will have an entirely
different obvious connotation to someone else. We already have far too
much jargon based on this.
Cheshire Cat works universally once the idea has been explained, but
Pimple does not (it requires that the reader understands English and ca
parse it as P(ointer to)impl(ementation). Compiler Firewall is even
worse because it needs explanation and even then could well be used to
refer to other idioms designed to prevent leakage of information to the
compiler.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation