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


Groups > comp.lang.c > #22546

Re: Design decisions

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

Show all headers | View raw


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!


> I guess you just have to use a double stack of function pointers / data
> pointers that get called in reverse order?
>

Not really. A generic stack using generic pointers prefixed by an opcode 
would suffice:

#define MUTEX 1
#define FILE_TO_CLOSE	2
#define OBSERVER_TO_FREE 3

typedef struct tagStackInfo {
	int opcode;
	void *data;
} StackUnwindInfo;

You push that, giving the opcode and the pointer (FILE MUTEX, whatever)
The unwind procedure acts given the opcode and closes the file, releases 
the mutex, or breaks the binding of the observer procedure.

NOTE:

This is C, not C++. The philosophy is that you do NOT rely in an
incredible complex compiler/runtime that nobody fully understands.
You rely on your own skills.

Unsatisfied?

Use C++, it is a great language!

>> This would require just a few lines more of code.
>
> Any chance of an example?
>

Well, pushing and popping from a stack is not that really complicated.

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