cbruce wrote:There are no negative integer literals.
This is correct for C/C++. But,
do we really have to do, the same *nonsense* in FB?IMHO, implicit behaviour, should always be *explicitly* changeable.
Here: with the suffixed (explicit) *type definition*, of the literal.
My case, which led to *discovery* of the *type conversion* was:
- wanting to code a *universal* data-type, with overloaded initializers (no OOP!)
- OK, with the following types:
- Boolean (funny, accepts the -1, aka: TRUE), assignes 1 byte only!
- [U]Integer (ptr size, of compiler, '%' with negative values: no problem!)
- [U]LongInt ('ll' with negative values: no problem!)
- Single / Double (using 'f' or 'd', after literal)
- String (behind the scenes: a sized ZString)
NOK only, with negative LONG.
With a temporary LONG (negative literal = assigned value), easily fixed ...
Also working, by using an assigned type specific variable, are:
- [U]Byte / [U]Short (here: the suffixes (forcing) are missing) and finally:
- [U]Long (here, the 'l' should do its job, IMHO, regardless of value)
(Otherwise, a 4 byte negative LONG is *impossible*, with FBC 64!)