Octal and Binary Literals
Currently Eu does not allow literal octal or binary numbers to be specified
(except perhaps as a string passed to a decode function), and I wondered what
would everyone would consider to be the best way to allow such. At the same time,
I would like to solve the problem of not being able to specify "escape" chars in
strings.
Implementation should be based on the following, in order:
1: Unambiguity and Least Surprise
2: Zero impact on legacy code
3: Minimal performance impact
Legacy:
NN -- decimal, N is 0..9
#NN -- hex, N is 0..9, A..F, a..f
Notes: While the NNh, 0xNN, and #xNN cases shown below are not strictly
necessary (assuming we keep #NN) they may help with consistency.
Option 1: Use a Suffix character.
NNo -- octal, N is 0..7
NNh -- hex, N is 0..9, A..F, a..f
NNb -- binary, N is 0 or 1
Notes: the NNb case would need to be followed by a delimeter, ie in "1bh"
the 'b' does not terminate the token since it is followed by a valid
hex char, and is equal to "27".
This would probably yield the highest performance impact, simply
because you have to check for o/h/b after every number.
Option 2: Use the leading 0 trick from C.
NN -- decimal (first char is not 0)
0NN -- octal
0xNN -- hex
0bNN -- binary
Notes: this means that 012 == 10. Any legacy code with leading zeroes will
be broken.
Option 3: Use the 0X style notation.
0oNN -- octal
0xNN -- hex
0bNN -- binary
Notes: This would be my personal choice.
Option 4: As 0X, but use #.
#oNN -- octal
#xNN -- hex
Notes: There is no obvious way to specify binary numbers as the 'b' (and to
a lesser extent a 'd' for explicitly decimal) clash with legacy use.
This would probably yield the lowest performance impact, since the
only compiler changes are needed after it has detected a # character.
Options 2 and 3 occupy the middle ground, having to check for
leading 0.
It may also be sensible to allow a 'd' to explicitly state "this is decimal",
so that in option 1, NNd (with same delimeter note) is equal to NN, or in
option 2 and 3, 0dNN, but not apparently possible under option 4.
I have a need to specify octal numbers for an assembly project. I want to use
"bytewise octal" whereby each byte is represented by exactly 3 octal digits, ie
FFFFFFFF(hex) = 377377377377(octal).
Can anyone think of a problem with using "NNob", "0obNN", or "#obNN" for this?
If you take specific exception to that going into "official Eu", then please take
a moment to consider whether you could properly justify your objections and/or
what factors might lessen them.
For strings, I think the best option is "\#NN". I doubt there is much call for
octal codes anymore. I also think we should force it to be exactly two hex
digits, no more and no less. For example, suppose I want {7,'H','e','l',l',o'}
then I might code "\#07Hello". Any objections to that? Obviously someone is bound
to mention Unicode, so is there a sensible way to say "a two digit hex no" vs "a
four digit hex no" etc? Otherwise "\#0700000" becomes ambiguous, meaning either
{7,'0','0','0','0','0'} or {#700,'0','0','0'}.
Regards,
Pete
|
Not Categorized, Please Help
|
|
