Re: Memory and error management approaches

From	Ian Collins <ian-news@hotmail.com>
Newsgroups	comp.lang.c
Subject	Re: Memory and error management approaches
Date	2015-11-07 09:38 +1300
Message-ID	<da4hdvFjinnU1@mid.individual.net> (permalink)
References	(8 earlier) <d9t5scFs0krU2@mid.individual.net> <fg0qgc-mgq.ln1@wilbur.25thandClement.com> <n1dnm8$k1u$1@dont-email.me> <8737wjk1lw.fsf@gmail.com> <macvgc-dta.ln1@wilbur.25thandClement.com>

Show all headers | View raw

william@wilbur.25thandClement.com wrote:
> Gareth Owen <gwowen@gmail.com> wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>
>>> I will argue that point - it is not "just" syntactic sugar - it's
>>> extremely valuable syntactic sugar which renders inaccurate your claim
>>> that it "works just as well in C as in C++". That syntactic sugar makes
>>> it work a whole lot better in C++ than in C.
>>
>> I completely agree.  The key to RAII is not that Resource Acquistion Is
>> Initialization but its converse -- End-of-Life Is *Automatic* Resource
>> Release.
>
> If this were the key to RAII, then you wouldn't care whether acquisition
> happens in constructors. You could have a dozen objects on the stack, and
> initialize things whenever and where ever you wanted, scattered across
> various functions and methods. The _only_ thing that would matter is that
> all objects are collectable via automatic destructors.

What leads you to that conclusion?  At least in the context of C++, 
acquisition does not usually happen in a constructor, unless you 
consider passing the resource as a parameter to the constructor as 
acquisition?

Objects are often created as required, the key is that they are released 
in reverse order at the end of their "life".

>> You can fake the former easily in C ("no lazy initialisation") - the
>> converse is much much harder.  To release resources in C but you *have*
>> to do it all by hand (or use a GC, if the only resource you're
>> interested in is memory), which is absolutely not "works just as well in
>> C" unless you have unlimited programmers, unlimited patience or
>> unlimited time.
>
> In the presence of exceptions the value of automatic destructors is
> clear--they're absolutely essential to the coherency of the language. But
> RAII is more than automatic destructors as a solution to exceptions. A
> strict RAII discipline also tends to minimize the places where exceptions
> might occur, making control flow easier to reason about. This is why the
> methodology emphasizes constructors.

It is also key to the clean and safe use of early returns, which is 
where it would be beneficial to C if C had some form of automatic 
destructors.  RAII removes the last, all be it poor, justification for 
using goto!

> My point wrt C is that by following the pattern, in the majority of error or
> similarly exceptional cases the only local state you need to destroy
> explicitly is single object reference.
>
> 	error:
> 		foo_destroy(fp);
> 		return error;

I think that label alone disproves "works just as well in C"!

> Even if you're explicitly destroying several objects it's just as simple.
> This is because most objects can follow simple hierarchical ownership rules.
> And while the above is verbose, it's not even remotely complex. RAII
> _minimizes_ the complexity, often times dramatically. It's not about
> minimizing SLoC or boiler plate so much as it is minimizing control flow
> paths and number of states.
>
> For example, one of the biggest problems in managing errors is _testing_
> error paths. But by following an RAII discipline--suitably adjusted for C,
> such as permitting destructors to take NULL pointers--the overlap between
> error paths and normal program flow will be much greater, because they both
> rely on the same program sequence--the same destructor--to unwind state.
>
> Precisely because C doesn't have automatic destructors the _worth_ of
> following an RAII discipline can be _greater_ in C. If I give a $100 each to
> a millionaire and a pauper, to whom is that $100 worth more? The pauper. In
> a very meaningful sense, the payoff of RAII can be greater in C because it's
> relative poor in terms of high-level constructs. The marginal benefit can be
> greater.
>
> I realize from a C++ programmer's perspective my assertion is probably a
> "WTF?" moment. It's provocative. But you have to admit that, at a minimum,
> even outlining the ways that RAII _doesn't_ work in C is a useful mental
> exercise for improving the design of C applications.

I see your point above, but I don't agree that is shows RAII works just 
as well in C.  Yes it has benefits, but only as subset of the benefits 
in C++.

-- 
Ian Collins

Thread

Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 10:17 +0100
  Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-02 22:25 +1300
    Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 10:36 +0100
      Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-02 22:41 +1300
        Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 11:05 +0100
          Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 12:15 +0000
            Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 20:31 +0100
          Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 09:48 +1300
            Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 13:17 -0800
              Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 10:29 +1300
                Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 13:48 -0800
            Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 22:31 +0100
              Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 11:02 +1300
                Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 15:21 -0800
              Re: Memory and error management approaches <william@wilbur.25thandClement.com> - 2015-11-03 17:24 -0800
                Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-04 14:38 +1300
                Re: Memory and error management approaches <william@wilbur.25thandClement.com> - 2015-11-04 10:48 -0800
                Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-04 11:28 -0800
                Re: Memory and error management approaches James Kuyper <jameskuyper@verizon.net> - 2015-11-04 14:54 -0500
                Re: Memory and error management approaches Gareth Owen <gwowen@gmail.com> - 2015-11-06 07:50 +0000
                Re: Memory and error management approaches <william@wilbur.25thandClement.com> - 2015-11-06 11:40 -0800
                Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-07 09:38 +1300
                Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-06 20:55 +0000
                Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 02:23 -0800
                Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-07 11:29 +0000
                Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 04:18 -0800
                Re: Memory and error management approaches asetofsymbols@gmail.com - 2015-11-07 05:41 -0800
                Re: Memory and error management approaches asetofsymbols@gmail.com - 2015-11-07 06:27 -0800
                Re: Memory and error management approaches Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2015-11-07 18:20 +0100
                Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 10:28 -0800
                Re: Memory and error management approaches gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-07 19:01 +0000
                Re: Memory and error management approaches raltbos@xs4all.nl (Richard Bos) - 2015-11-10 16:14 +0000
                Re: Memory and error management approaches Gareth Owen <gwowen@gmail.com> - 2015-11-10 21:13 +0000
                Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-10 19:26 +0000
                Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-03 18:25 -0800
                Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-06 10:05 +0100
    Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 02:15 -0800
      Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 12:01 +0000
        Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 06:05 -0800
          Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 17:18 +0000
            Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 09:27 -0800
              Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 23:02 +0000
              Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 12:07 +1300
                Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 15:23 -0800
            Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 10:28 -0800
      Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 09:34 +1300
        Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 14:05 -0800
          Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 11:27 +1300
            Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-03 18:15 -0800

csiph-web