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


Groups > comp.lang.c > #22569

Re: Design decisions

From Ian Collins <ian-news@hotmail.com>
Newsgroups comp.lang.c
Subject Re: Design decisions
Date 2012-06-23 12:59 +1200
Message-ID <a4kinoFglmU3@mid.individual.net> (permalink)
References (7 earlier) <js26e1$ct5$1@speranza.aioe.org> <a4k3q3FglkU3@mid.individual.net> <js2pp5$t7c$1@speranza.aioe.org> <a4k9f8FglmU2@mid.individual.net> <js31mt$dci$1@speranza.aioe.org>

Show all headers | View raw


On 06/23/12 12:13 PM, jacob navia wrote:
> Le 23/06/12 00:21, Ian Collins a écrit :
>> On 06/23/12 09:58 AM, jacob navia wrote:
>>> Le 22/06/12 22:44, Ian Collins a écrit :
>>>> On 06/23/12 04:27 AM, jacob navia wrote:
>>>>>
>>>>> 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.
>>
>> If you find
>>
>> struct ManageSomething
>> {
>>     Something thing;
>>
>>     ManageSomething( Something s ) : thing(s) {}
>>     ~ManageSomething() { release( thing ); }
>> };
>>
>> difficult to understand, I'd be worried.
>
> It is difficult to understand, maybe because "s" is undefined :-)
>
> ManageSomething(Something s) looks like a function call but probably
> isn't one since you are declaring a struct, so it must be a declaration
> of a constructor. Yes, and then a further function call (or similar)
> separated by a colon. Mmmm I have seen that sometimes in C++ code
> and "thing" is a "Something" so that must be a function call?
>
> Or not?
>
> You can be worried, I do not parse all that and I do not care actually
> to parse that.

Somewhat disingenuous coming from someone who claims to be paid to 
maintain C++ code don't you think?

>>>> 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.
>>
>> Easy, tedious, repetitive and error prone.  Isn't the normal
>> programmer's reaction to a tedious, repetitive and error prone problem
>> automation?
>>
>
> Yes. Up to 30% or more of space are now taken by tables describing the
> stack movements to the unwinding virtual machine that the C++ run time
> needs.

Now where did you dig up that "fact" from?  Automatic destruction works 
perfectly well without run time support.

> But this has no sense Ian. Keep C++. I will go on developing simple
> solutions to simple problems. A stack is a stack, and I prefer pushing
> the things to cleanup into a stack with:
 >
> pushCleanup( Opcode,pointer);
>
> each time I need to cleanup something, and then I just write:
>
> UnwindCleanupStack();
>
> and I am done. And I write pushCleanup() and Unwind once and I can
> use them again and again.

I prefer to let the compiler do the pushing and popping for me.  Lazy? 
maybe, but I know the compiler won't have a bad hair day and forget to 
pop something.

-- 
Ian Collins

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