[OT] Re: Octal and Binary Literals

new topic     » topic index » view thread      » older message » newer message

FYI, I've tried this on Positive and simply cannot measue any performance hit
with any of the formats I tried, on a 150Mhz box compiling 14710 lines of code.
I've settled on the 0x style format. I've marked this [OT] since afaik it's never
going into Eu, not by my hand anyway.

CChris wrote:
> Why not simply:
> #(2)1110010101
> #(16)FFE4
> #(10)365
> #(8)755
Not a bad idea. Only I implemented eg 0(16)FFE4 instead, see below.

Matt Lewis wrote:
> 
> Pete Lomax wrote:
> > 
> > Implementation should be based on the following, in order:
> >   1: Unambiguity and Least Surprise
> >   2: Zero impact on legacy code
> >   3: Minimal performance overhead
> 
> We should put this up on the wall somewhere. :)
Have I just been framed?
> 
> > Option 3: Use the 0X style notation.
> >   0oNN	-- octal
> >   0xNN	-- hex
> >   0bNN	-- binary
> >  Notes: This would be my personal choice.
> 
> I like this.   Presumably, now we'd have 2 ways to specify hexadecimal.  
> What about using lowercase for hexadecimal numbers of this format?  
That is precisely what I have done. In Positive there are now 11 (eleven!)
uppercase ways to specify 255:
255, #FF, 0xFF, 0(16)FF, 0b11111111, 0(2)11111111, 0o377, 0ob377, 0(8)377,
0(10)255, and 0d255
and with case-variants:
#ff, #fF, #Ff, 0xff, 0xfF, 0xFf, 0(16)ff, 0(16)fF, 0(16)Ff
that makes 20 (twenty!) in total smile
Obviously no one program(mer) is likely to use all possible variants, but some
will fit nicer than others in different circumstances, and this may be
particularly useful when translating some C or whatever to Eu, expecially if it
contains some big hard-coded tables (though C-style octals will need the 'o'
inserting, nor have I allowed eg 0FFh et al).

I toyed with the idea of also allowing #xFF, #(16)FF etc but that really did
seem like overkill as well as raising the doubt whether eg #b1 meant 1 (ie
binary) or 177 (as #B1 does now). So I left # alone.

After several days I can still only think of one small (very small)
incompatibility:
procedure xx()
    puts(1,"hello\n")
end procedure
integer i
  i=0xx()

which will now need a space after the 0.

Thanks for replying,

Regards,
Pete

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu