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

Groups > comp.lang.c > #22567

Re: Design decisions

Show all headers | View raw

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. You like C++Ian, go ahead, it is a GREAT language when
you dedicate 50% of your memory space (brain memory space I mean) to
memorizing by heart all the fine points of a language that has no rules
but a "tradition" that you must also learn by heart.

Googling around I find
http://www.cplusplus.com/forum/beginner/4124/
where "Initializer lists" are explained and it should mean that
the constructor of "ManageSomething" will be passed "Something"
that will initialize "thing" to the passed parameter "s".

Why that?

Because it can save the call to the default constructor. OK.
And why I should learn all that?

I do not care, I like a language with LESS syntax, with LESS
complexity.

If you do not use initializer lists this can happen:

MyClass::MyClass( const std::string& s1, const std::string& s2 )
{
    string1 = s1;
    string2 = s2;
}

1. std::string default constructor is called to default construct string1;
2. std::string default constructor is called to default construct string2;
3. std::string assignment operator is called to assign s1 to string1;
4. std::string assignment operator is called to assign s2 to string2.

With initializer lists there are only two extra function calls
"by using an initializer list, you are telling the compiler that instead 
of calling the default constructor for string1 and string2 it can 
instead call the copy constructor, which means only two function calls 
instead of four."

BIG PROGRESS.

Ian, go ahead and keep C++. It is a great language but for people
outside its scope it looks like an abomination came true.

> I guess at some time in the past, our distant ancestors found wheels
> complex, but they sure beat pushing things along the ground.  Developing
> technical solutions to repeating problems is what we do.
>

Sure, sure, and then somebody invented square wheels and all people
but some die hards cried GREAT!

SQUARE WHEELS that can climb up the stairs instead of just
rolling around. They are our "BETTER WHEELS".

And everybody started using those. Cars bumped horribly, the ride was
awful but... PROGRESS IS PROGRESS cried the crowd.

And then came a "solution to the bumping problem" proposed by the square
wheels people: a new motor would push down and up the carriage
automatically so that the passangers did not felt the square wheels.

And now really everybody was happy: fuel consumption skyrocketed but
that was a small hardware problem that got pushed beneath the rug.

:-)



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

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.

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