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


Groups > comp.lang.c > #22560

Re: Design decisions

From jacob navia <jacob@spamsink.net>
Newsgroups comp.lang.c
Subject Re: Design decisions
Date 2012-06-22 23:58 +0200
Organization lccwin
Message-ID <js2pp5$t7c$1@speranza.aioe.org> (permalink)
References (4 earlier) <a80c870c-0427-4f04-bbd3-770d56b717de@cu1g2000vbb.googlegroups.com> <js1968$26c$1@speranza.aioe.org> <87sjdn8gm0.fsf@gmail.com> <js26e1$ct5$1@speranza.aioe.org> <a4k3q3FglkU3@mid.individual.net>

Show all headers | View raw


Le 22/06/12 22:44, Ian Collins a écrit :
> On 06/23/12 04:27 AM, jacob navia wrote:
>> Le 22/06/12 18:18, Gareth Owen a écrit :
>>> jacob navia<jacob@spamsink.net>  writes:
>>>
>>>> Very easy. Just use a pushdown stack. Each time you acquire a
>>>> mutex lock you push it in  the stack, each time you release it you
>>>> pop it.
>>>
>>> Which is, of course, precisely C++ exceptions give you for (almost)
>>> free.
>>>
>>>> If an exception occurs, you pop the whole mutex stack.
>>>
>>> Which is fine if *all* your resources are mutexes.  Again, if you have
>>> nested resources that must be acquired and released in precisely the
>>> correct order, everything gets a little more complicated.
>>>
>>
>> Maybe, depends on what you have in mind. In any case the unwinding of
>> the stack done by C++ is just that: stack unwinding and you can
>> simulate that with a generic stack without any big problems. Of course
>> it is a bit ofmore work for you but you do NOT pay for an
>> enormous complexity increase!
>
> The complexity in both case will be equal.  In your case the complexity
> has to be managed by the manually programmer, in the C++ case it is
> managed automatically by the compiler.
>


Sure, but that "aautomatic" managemengt by an incredibly complex
compiler has a price in difficulty of learning, understanding and using
all that machinery.

> The complexity becomes really hard to manage manually when the jump
> target is several layers up the call stack.
>

No, since it is conceptually simple: a stack. For each pointer that you
need to free/release whatever you add an opcode and a pointer. You push
that into the stack. It is very easy.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Design decisions jacob navia <jacob@spamsink.net> - 2012-06-21 22:19 +0200
  Re: Design decisions Andrew Cooper <amc96@cam.ac.uk> - 2012-06-21 21:43 +0100
  Re: Design decisions "BartC" <bc@freeuk.com> - 2012-06-21 22:02 +0100
    Re: Design decisions Gareth Owen <gwowen@gmail.com> - 2012-06-21 23:23 +0100
      Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-22 09:12 +0200
        Re: Design decisions Ian Collins <ian-news@hotmail.com> - 2012-06-22 19:44 +1200
          Re: Design decisions "Joe." <antelope3@news.net> - 2012-06-25 00:32 -0600
        Re: Design decisions gwowen <gwowen@gmail.com> - 2012-06-22 01:00 -0700
          Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-22 10:08 +0200
            Re: Design decisions Gareth Owen <gwowen@gmail.com> - 2012-06-22 17:18 +0100
              Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-22 18:27 +0200
                Re: Design decisions Ian Collins <ian-news@hotmail.com> - 2012-06-23 08:44 +1200
                Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-22 23:58 +0200
                Re: Design decisions Ian Collins <ian-news@hotmail.com> - 2012-06-23 10:21 +1200
                Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-23 02:13 +0200
                Re: Design decisions Ian Collins <ian-news@hotmail.com> - 2012-06-23 12:59 +1200
                Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-23 11:03 +0200
                Re: Design decisions Ian Collins <ian-news@hotmail.com> - 2012-06-23 21:52 +1200
                Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-23 12:32 +0200
                Re: Design decisions Gareth Owen <gwowen@gmail.com> - 2012-06-23 13:54 +0100
            Re: Design decisions "Joe." <antelope3@news.net> - 2012-06-25 00:36 -0600
          Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-22 10:42 +0200
            Re: Design decisions Gareth Owen <gwowen@gmail.com> - 2012-06-22 17:18 +0100
            Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-24 18:32 +0200
    Re: Design decisions James Kuyper <jameskuyper@verizon.net> - 2012-06-21 18:43 -0400
      Re: Design decisions "Joe." <antelope3@news.net> - 2012-06-25 00:40 -0600
    Re: Design decisions "Joe." <antelope3@news.net> - 2012-06-25 00:28 -0600
  Re: Design decisions "io_x" <a@b.c.invalid> - 2012-06-22 08:35 +0200
  Re: Design decisions Neil Cerutti <neilc@norwich.edu> - 2012-06-22 12:40 +0000
    Re: Design decisions gwowen <gwowen@gmail.com> - 2012-06-22 06:01 -0700
      Re: Design decisions Neil Cerutti <neilc@norwich.edu> - 2012-06-22 14:26 +0000
    Re: Design decisions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-22 14:01 +0100
    Re: Design decisions David Resnick <lndresnick@gmail.com> - 2012-06-22 06:13 -0700
  Re: Design decisions Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-22 19:05 +0200
  Re: Design decisions "Joe." <antelope3@news.net> - 2012-06-25 00:27 -0600

csiph-web