Re: Memory and error management approaches

Message-ID	<macvgc-dta.ln1@wilbur.25thandClement.com> (permalink)
From	<william@wilbur.25thandClement.com>
Subject	Re: Memory and error management approaches
Newsgroups	comp.lang.c
References	(7 earlier) <6b3ogc-uob.ln1@wilbur.25thandClement.com> <d9t5scFs0krU2@mid.individual.net> <fg0qgc-mgq.ln1@wilbur.25thandClement.com> <n1dnm8$k1u$1@dont-email.me> <8737wjk1lw.fsf@gmail.com>
Date	2015-11-06 11:40 -0800

Show all headers | View raw

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.

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

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;

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.

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