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

Groups > comp.programming > #1923

Re: functions as objects

Show all headers | View raw

On 7/8/2012 10:34 AM, BartC wrote:
>
>> say:
>> int x, y;
>> z=x+y; //type of x+y?
>>
>> in the usual semantics, x+y will always give int (and will wrap around on
>> overflow).
>>
>> this is not the case when a narrower and wider type are being added.
>>
>>
>> int x;
>> long y;
>> z=x+y; //type of x+y?
>>
>> where the usual rule would be to auto-promote to long in this case.
>
> My rule would be to ignore what's on the left of the assignment; the
> right-hand-size would be whatever "+" in "x+y" is defined as, usually (when
> you have static typing like this), addition of two N-bit values with an
> N-bit result.
>

actually, note:
the LHS was being ignored, it was the right-hand side of the + that was 
long, hence the type promotion.


> This result, possibly truncated from the true arithmetic answer, might
> then be widened to match the left-hand-side.
>
> The rationale was that I wanted the same behaviour with static and dynamic
> typing; with dynamic, you don't know the type of the left-hand-side; it
> might not even *have* a type! (Now however I'm not bothered; I accept that
> static and dynamic code can be different.)
>
> But also, using auto-promotion can give problems: imagine a highly complex
> nested expression of 100 int terms, the result being assigned to an int.
> Now assign the result instead to a long int, or a floating point
> variable; that auto-promotion will now propagate deeply into the
> expression, probably changing the result in half-a-dozen places.
>

it doesn't do this stuff dynamically, rather it *statically* figures out 
the assigned types and storage sizes of the values.


>> likewise goes for, say:
>> int x;
>> int128 y;
>> z=x+y; //type of x+y?
>>
>> which would likewise promote to int128.
>
> The trouble is that you need to have a good idea that x+y could overflow.
> Most of the time it won't, so doing 128-bit addition in 99% of cases is
> inefficient. And when you don't have a wide result type, it *will*
> overflow!
>

this isn't really considered an issue, since if the programmer writes 
'int128' for the type, the variables *will* use int128.

in the case where no large type is specified, then it will overflow 
silently.


>> byte/ushort/char exist, but are internally often just auto-promoted to
>> int
>
> I'm experimenting with doing actual arithmetic on 8- and 16-bit values,
> without promoting to at least 32-bits. But only really because those 8- and
> 16-bit opcodes exist on my machine, so they might as well be put to use;
> also the code could be shorter, and perhaps faster.
>

well, the issue is partly that this is the current typical behavior for 
C compilers, and it saves out on needing a lot of extra logic to deal 
with arithmetic on the byte and short types.

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

functions as objects bob <bob@coolfone.comze.com> - 2012-07-02 08:15 -0700
  Re: functions as objects Rui Maciel <rui.maciel@gmail.com> - 2012-07-02 17:42 +0100
  Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-03 14:56 -0500
    Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-04 09:28 +0200
      Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-04 10:08 -0500
        Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-04 18:12 +0200
          Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-04 14:02 -0500
            Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-04 22:20 +0200
              Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-04 19:42 -0500
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-05 11:30 +0200
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-05 10:33 -0500
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-06 10:50 +0200
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-06 08:32 -0500
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-06 16:45 +0200
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-06 10:48 -0500
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-07 21:28 +0200
                Re: functions as objects "BartC" <bc@freeuk.com> - 2012-07-08 16:33 +0100
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-08 18:20 +0200
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-08 16:27 -0500
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-09 09:35 +0200
                Re: functions as objects "BartC" <bc@freeuk.com> - 2012-07-09 09:48 +0100
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-09 11:40 +0200
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-09 11:02 -0500
                Re: functions as objects "BartC" <bc@freeuk.com> - 2012-07-08 16:34 +0100
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-08 16:11 -0500
                Re: functions as objects "BartC" <bc@freeuk.com> - 2012-07-08 23:35 +0100

csiph-web