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

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

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

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

Contents

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

Page 1 of 2  [1] 2  Next page →

#15277 — Terminology - RAII vs. Scope Guard vs...?

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

[toc] | [next] | [standalone]

#15278

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

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.

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

#15291

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

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

#15296

On Apr 11, 9:10 am, Noah Roberts <roberts.n...@gmail.com> wrote:
> On Apr 10, 2:36 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Apr 10, 1:47 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>
> > > So RAII is when you make it so that the acquisition of a resource is
> > > tied to the initialization of a scope-based variable that cleans up
> > > said resource when it's destroyed.
>
> > RAII is more than that. It's the way of coding in which you ensure
> > that all resources
> > 1- have an owner whose destructor will free the resource, or
> > 2- be on the stack (or a global or some other "root" of the ownership
> > tree).
>
> > In other words, RAII is the way of coding in which at every step of
> > the program, if you have a resource that needs to be freed, you can
> > identify an object whose destructor will free it, or the resource is
> > an object on the stack (or a global, etc.).
>
> > This all assumes, of course, that you have a cycle-free ownership
> > graph. This works amazingly well for almost all cases. Sure, you can
> > invent some corner cases where this ownership tree approach isn't a
> > good option, but that's beside the point. RAII is the default for
> > writing good code.
>
> > Scope Guards are mere utility classes to help facilitate writing in
> > the RAII style.
>
> Well, I'd disagree with you on that and so does most if not all of the
> documentation on the subject; all that I've seen at any rate.  It is
> true that using the RAII idiom as policy is a good policy decision, at
> least in my opinion (not everyone's), but it's still an idiom rather
> than a philosophy.  It can form a part of a philosophic framework
> though.
>
> http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

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

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

I think it's fair to say my initial post has equivalent meaning to
that quote from wiki.

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

#15300

On Apr 11, 12:28 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> On Apr 11, 9:10 am, Noah Roberts <roberts.n...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Apr 10, 2:36 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
>
> > > On Apr 10, 1:47 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>
> > > > So RAII is when you make it so that the acquisition of a resource is
> > > > tied to the initialization of a scope-based variable that cleans up
> > > > said resource when it's destroyed.
>
> > > RAII is more than that. It's the way of coding in which you ensure
> > > that all resources
> > > 1- have an owner whose destructor will free the resource, or
> > > 2- be on the stack (or a global or some other "root" of the ownership
> > > tree).
>
> > > In other words, RAII is the way of coding in which at every step of
> > > the program, if you have a resource that needs to be freed, you can
> > > identify an object whose destructor will free it, or the resource is
> > > an object on the stack (or a global, etc.).
>
> > > This all assumes, of course, that you have a cycle-free ownership
> > > graph. This works amazingly well for almost all cases. Sure, you can
> > > invent some corner cases where this ownership tree approach isn't a
> > > good option, but that's beside the point. RAII is the default for
> > > writing good code.
>
> > > Scope Guards are mere utility classes to help facilitate writing in
> > > the RAII style.
>
> > Well, I'd disagree with you on that and so does most if not all of the
> > documentation on the subject; all that I've seen at any rate.  It is
> > true that using the RAII idiom as policy is a good policy decision, at
> > least in my opinion (not everyone's), but it's still an idiom rather
> > than a philosophy.  It can form a part of a philosophic framework
> > though.
>
> >http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
>
> I'm sorry. I don't understand what point you are trying to make.

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

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

#15315

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

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

#15329

On Apr 11, 1:29 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> On Apr 11, 12:28 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Apr 11, 9:10 am, Noah Roberts <roberts.n...@gmail.com> wrote:
>
> > > On Apr 10, 2:36 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
>
> > > > On Apr 10, 1:47 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>
> > > > > So RAII is when you make it so that the acquisition of a resource is
> > > > > tied to the initialization of a scope-based variable that cleans up
> > > > > said resource when it's destroyed.
>
> > > > RAII is more than that. It's the way of coding in which you ensure
> > > > that all resources
> > > > 1- have an owner whose destructor will free the resource, or
> > > > 2- be on the stack (or a global or some other "root" of the ownership
> > > > tree).
>
> > > > In other words, RAII is the way of coding in which at every step of
> > > > the program, if you have a resource that needs to be freed, you can
> > > > identify an object whose destructor will free it, or the resource is
> > > > an object on the stack (or a global, etc.).
>
> > > > This all assumes, of course, that you have a cycle-free ownership
> > > > graph. This works amazingly well for almost all cases. Sure, you can
> > > > invent some corner cases where this ownership tree approach isn't a
> > > > good option, but that's beside the point. RAII is the default for
> > > > writing good code.
>
> > > > Scope Guards are mere utility classes to help facilitate writing in
> > > > the RAII style.
>
> > > Well, I'd disagree with you on that and so does most if not all of the
> > > documentation on the subject; all that I've seen at any rate.  It is
> > > true that using the RAII idiom as policy is a good policy decision, at
> > > least in my opinion (not everyone's), but it's still an idiom rather
> > > than a philosophy.  It can form a part of a philosophic framework
> > > though.
>
> > >http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
>
> > I'm sorry. I don't understand what point you are trying to make.
>
> The point I'm trying to make is that RAII is just one idiom.  It's a
> technique that can be used as part of a coding policy.  It isn't
> itself a policy as you claim.  It also isn't the only valid policy and
> might not be a good fit for every project.  It would actually fit
> rather poorly in a project that used allocation pools for example.

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

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

#15334

On Apr 12, 2:31 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:

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

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

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

Before you go saying it's the same thing...it's not:
http://en.wikibooks.org/wiki/More_C%2B%2B_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.

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

#15335

On 13.04.2012 01:48, Noah Roberts wrote:
> On Apr 12, 2:31 pm, Joshua Maurice<joshuamaur...@gmail.com>  wrote:
>
>> Ok. Sorry. This is now an unintentional argument over definitions
>> ("philosophy" and "idiom" and "policy"). The argument is not terribly
>> interesting. I am glad we are otherwise in agreement.
>
> Except that you claimed that scope guards are a kind of RAII that that
> does not appear to be the case.  They are *similar*, in that they both
> use the destructor to cause something to happen when scope is exited,
> but not the same.  RAII for one clearly means that we're acquiring a
> resource as we initialize an object...that is the fundamental part of
> scope based creation/destruction events that makes something RAII.
> Scope guards don't necessarily do that nor are they necessarily about
> any resource at all...they might just print a message if you don't
> tell them not to.
>
> Thus my question remains and you've done little but serve to distract
> the conversation.  When talking about these different things, and it's
> important that they have different terms because they are in fact
> different, what do you call something that's sort of like a scope
> guard but does not have a backout...in other words you never release
> it.
>
> Before you go saying it's the same thing...it's not:
> http://en.wikibooks.org/wiki/More_C%2B%2B_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

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

#15338

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

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

-miles

-- 
「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]

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

#15345

On 13.04.2012 03:57, Miles Bader wrote:
> "Alf P. Steinbach"<alf.p.steinbach+usenet@gmail.com>  writes:
>> The Wikipedia article is written by someone who doesn't understand a
>> thing, and who treats obvious things as significant.
>>
>> It's very annoying with such wanna-be academics.
>
> 'cause, you know, c.l.c++ is SO MUCH BETTER...

Considering that Andrei (but unfortunately not Petru Marginean), one of 
the authors of the original ScopeGuard article, used to be here, and 
considering that he's evidently not been over there, yes.

That's the beauty of free speech (like clc++), as opposed to editorial 
dictatorship over content (wikipedia or e.g. Stack Overflow), namely 
that incorrect statements do not live long in an arena of free speech.

And there are still some experts frequenting this group.

But I think you meant that sarcastically.

Still, it's good that people say what they mean, even if it's expressed 
as sarcasm, for only that way can they and others learn.


Cheers & hth.,

- Alf

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

#15348

Miles Bader wrote:

> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>> The Wikipedia article is written by someone who doesn't understand a
>> thing, and who treats obvious things as significant.
>>
>> It's very annoying with such wanna-be academics.
> 
> 'cause, you know, c.l.c++ is SO MUCH BETTER...

In my opinion it is undoubtedly better, just for the fact that ideas can be 
openly discussed (it's the purpose of a newsgroup) and therefore unfounded 
claims don't tend to get a free pass. 

With wikipedia, some people tend to read the article without a drop of 
critical thinking.  So, it's possible that, for example, if you edit the 
article on Swedish monarchs to include Elvis, before you know it you have 
people claiming that "love me tender" is Sweden's national anthem.  And why? 
Because wikipedia, that's why.  If it's written there then it must be true.

On a side note, some people tend to complain about how pedantic some 
discussions end up being on comp.lang.c++.  Yet, the effective use of a 
programming language is tied to the knowledge on how it actually works. 
Whether we like it or not this means being aware of how a number of minute 
details do affect how the language works.  If no attention is paid to these 
minute details then we might not really know how and why a language feature 
works, and as a consequence we might not really know what we are doing.  
With this, bad things can happen, and often do.  So, while some people refer 
to pedantry, in the context of a technical discussion, as an undesirable 
character, it is in fact the exact opposite, as it is an effective way to 
bet deeper insight into this technology.


Rui Maciel

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

#15351

Rui Maciel <rui.maciel@gmail.com> writes:
>>> It's very annoying with such wanna-be academics.
>> 
>> 'cause, you know, c.l.c++ is SO MUCH BETTER...
>
> In my opinion it is undoubtedly better, just for the fact that ideas can be 
> openly discussed (it's the purpose of a newsgroup) and therefore unfounded 
> claims don't tend to get a free pass. 

Sure, the feeling of freedom is great ... but c.l.c++ certainly doesn't
have any shortage of annoying wannabe academics...

-miles

-- 
Any man who is a triangle, has thee right, when in Cartesian Space,
to have angles, which when summed, come to know more, nor no less,
than nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]

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

#15353

On Apr 13, 6:18 am, Miles Bader <mi...@gnu.org> wrote:
> Rui Maciel <rui.mac...@gmail.com> writes:
> >>> It's very annoying with such wanna-be academics.
>
> >> 'cause, you know, c.l.c++ is SO MUCH BETTER...
>
> > In my opinion it is undoubtedly better, just for the fact that ideas can be
> > openly discussed (it's the purpose of a newsgroup) and therefore unfounded
> > claims don't tend to get a free pass.
>
> Sure, the feeling of freedom is great ... but c.l.c++ certainly doesn't
> have any shortage of annoying wannabe academics...
>
> -miles
>

Holy fuck has this newsgroup gone downhill!

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

#15302

On Wed, 2012-04-11, Joshua Maurice wrote:
> On Apr 11, 9:10 am, Noah Roberts <roberts.n...@gmail.com> wrote:
...
>> http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
>
> I'm sorry. I don't understand what point you are trying to make. From
> the wiki page: [...]

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

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#15307

On Apr 11, 2:36 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Wed, 2012-04-11, Joshua Maurice wrote:
> > On Apr 11, 9:10 am, Noah Roberts <roberts.n...@gmail.com> wrote:
> ...
> >>http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
>
> > I'm sorry. I don't understand what point you are trying to make. From
> > the wiki page: [...]
>
> Please be a bit careful when quoting that WP page. Every time I've
> checked it, it has been too confused to be useful.  E.g. dozens of
> people trying to prove /their/ favorite language has RAII, too.

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

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

#15318

Noah Roberts <roberts.noah@gmail.com> wrote:
> On Apr 11, 2:36 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> On Wed, 2012-04-11, Joshua Maurice wrote:
>> > On Apr 11, 9:10 am, Noah Roberts <roberts.n...@gmail.com> wrote:
>> ...
>> >>http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
>>
>> > I'm sorry. I don't understand what point you are trying to make. From
>> > the wiki page: [...]
>>
>> Please be a bit careful when quoting that WP page. Every time I've
>> checked it, it has been too confused to be useful.  E.g. dozens of
>> people trying to prove /their/ favorite language has RAII, too.
> 
> Yeah, I noticed that when I looked at the c2g or whatever page.  Some
> person was on there saying it was just "finalization" and compared it
> to Java's finally block.  Uh...NO!

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

  It is what allows, for example, to return objects by value from functions,
give them to functions as value parameters and to have RAII even in the
heap (as long as the container structure is allocated and deallocated
appropriately, the contained objects will follow the RAII rules). I don't
think any of this is something that can be implemented with that gcc
extension nor in languages like Java.

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

#15324

Juha Nieminen <nospam@thanks.invalid> writes:

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

I don't think that's an unreasonable distinction. Clearly, copying
semantics have to be well defined for any RAII-like
resource-management-through-ownership idiom/scheme/philosophy to work,
but you don't need C++ copy/assignment.

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.

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

#15341

Gareth Owen <gwowen@gmail.com> wrote:
> You could define 
> 
> * a language that forces copyable object to have a java-like
>  user-provided clone() for all objects, and no implicit copying or
>  assignment for user defined types (just as many C++ polymorphic
>  classes do)
> * or a language where every object acted like std::shared_ptr 
> * or even (god forbid) a language where every object acted like
>  std::auto_ptr
> 
> and still have RAII, just as long as you had destruction when the last
> reference vanished.

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

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

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

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

#15342

Juha Nieminen <nospam@thanks.invalid> writes:

> Gareth Owen <gwowen@gmail.com> wrote:
>> You could define 
>> 
>> * a language that forces copyable object to have a java-like
>>  user-provided clone() for all objects, and no implicit copying or
>>  assignment for user defined types (just as many C++ polymorphic
>>  classes do)
>> * or a language where every object acted like std::shared_ptr 
>> * or even (god forbid) a language where every object acted like
>>  std::auto_ptr
>> 
>> and still have RAII, just as long as you had destruction when the last
>> reference vanished.
>
>   I suppose you could, but then you would be seriously hindering the
> flexibility and efficiency of the language. 

Oh, undeniably. It would be a pretty terrible general purpose language -
although the first one isn't massively removed from Java (which is why
Java containers sucked for so long). 

But it might be a useful tool in certain domains, and you could still
use exceptions to provide error handling, coupled with RAII to provided
deterministic resource management.  

RAII is a necessary condition for a language not to suck, but its not
sufficient. :)

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web