Code metrics

Am 11.03.2015 um 11:46 schrieb Reinhardt Behm:

> func((uint8_t)1); looks nasty.
>
> True, but at that place the compiler could have deduced, that there is no
> loss by truncation.

The compiler could deduce that, and most likely it does.  But a fully 
blown C source analysis tool (and that includes a compiler in -W all 
mode) may worry about more than what _it_ can deduce.  It may want to 
make sure that _you_ deduced correctly, too.

If you didn't spell out your wish down to the last detail, down to and 
including conversions which the compiler would have automatically 
performed anyway, the compiler can't know what you really wanted; it 
only sees what you wrote, not what you thought.

So in a really picky setting, the compiler has to get back to the coder 
to make sure that writing really does match intent.  It does that by 
emitting a diagnostic for every aspect of the code that's not 100% 
perfectly self-evident.

Don Y wrote:

> First thing you'll learn is how all those delightful,
> COMPILER-SPECIFIC enhancements now are *liabilities*!

There is a reason I try very hard not to use any compiler-specific
features in my source code.

I should probably make it a habit to occasionally attempt to build my
projects with alternative compilers, to ensure that I actually *have*
avoided compiler-specific features.

A friend of mine routinely builds his software with three different
compilers.  It certainly avoids compiler-specific features, but it also
explores the differences in the bugs in the different compilers. :-/

Greetings,

Jacob
-- 
�I'm perfectly happy with my current delusional system.�
                                           -- Mirabel Tanner

On 15-03-11 20:11 , Don Y wrote:
> On 3/11/2015 10:56 AM, Niklas Holsti wrote:
>>> Would you prefer the rampant automatic type conversion of, e.g.,
>>> Pascal?  :>
>>
>> I think Ada has the right solution here: a literal never has a type
>> itself; it
>> takes on the type expected in the context. So the literal 1 means the
>> mathematical, universal, integer "one", and is compatible with any other
>> integer type (as long as the value 1 is included in the range of that
>> type, of
>> course).
>
> I'm not sure even *that* "do the right thing" approach is 100% safe.
>
> Consider:   x = sqrt(6)
>
> Then, consider:  if (x == 6)
>
> (in both cases, x being a floating type!)

Ok, I did not explain fully. Integers, floats and strings are separate 
"type categories" in Ada, so although the literal 6 is compatible with 
any integer type, it is not compatible with a floating point type or a 
fixed point type. An Ada compiler would complain about the (Ada versions 
of) the above.

>     value := "1234" + 1

And also about that (assuming that you have not written your own 
operator "+" with a suitable profile (string + integer, returning 
whatever type "value" has).

Character literals like 'c' and string literals like "1234" are also 
type-flexible, like integer literals, in that they take on an 8-bit, 
16-bit, or 32-bit-per-character encoding depending on the context.

> What would you *expect* the values of each variable to be?
>     x, y: int = 5;
> vs.
>     int x, y = 5;

I'm not quire sure what you are asking, there. The former declaration 
resembles Ada, in which both x and y are initialised to the value 5. The 
latter is C, where only y is initialised to 5.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Hi Niklas,

On 3/11/2015 3:44 PM, Niklas Holsti wrote:
> On 15-03-11 20:11 , Don Y wrote:
>> On 3/11/2015 10:56 AM, Niklas Holsti wrote:
>>>> Would you prefer the rampant automatic type conversion of, e.g.,
>>>> Pascal?  :>
>>>
>>> I think Ada has the right solution here: a literal never has a type
>>> itself; it
>>> takes on the type expected in the context. So the literal 1 means the
>>> mathematical, universal, integer "one", and is compatible with any other
>>> integer type (as long as the value 1 is included in the range of that
>>> type, of
>>> course).
>>
>> I'm not sure even *that* "do the right thing" approach is 100% safe.
>>
>> Consider:   x = sqrt(6)
>>
>> Then, consider:  if (x == 6)
>>
>> (in both cases, x being a floating type!)
>
> Ok, I did not explain fully. Integers, floats and strings are separate "type
> categories" in Ada, so although the literal 6 is compatible with any integer
> type, it is not compatible with a floating point type or a fixed point type. An
> Ada compiler would complain about the (Ada versions of) the above.

Sorry, I wasn't commenting on Ada, specifically.  Merely trying to indicate
how "do the right thing" can still be misleading.

>>     value := "1234" + 1
>
> And also about that (assuming that you have not written your own operator "+"
> with a suitable profile (string + integer, returning whatever type "value" has).
>
> Character literals like 'c' and string literals like "1234" are also
> type-flexible, like integer literals, in that they take on an 8-bit, 16-bit, or
> 32-bit-per-character encoding depending on the context.

Again, I'm trying to point out that people coming from different backgrounds
could "see" such an operation in very different ways -- based on past
experiences.

>> What would you *expect* the values of each variable to be?
>>     x, y: int = 5;
>> vs.
>>     int x, y = 5;
>
> I'm not quire sure what you are asking, there. The former declaration resembles
> Ada, in which both x and y are initialised to the value 5. The latter is C,
> where only y is initialised to 5.

And, again...  :>

Limbo is closely related to C (same pedigree).  I.e., you could "get the gist
of" a Limbo program without fully understanding its syntax.  You might
likely consider the two statements (above) to be roughly equivalent when,
in fact, they are subtly different.

Our expectations belie our past experiences.  Hence, you read what you *want*
instead of what is actually *written*.

Hi Jacob,

On 3/11/2015 3:00 PM, Jacob Sparre Andersen wrote:
> Don Y wrote:
>
>> First thing you'll learn is how all those delightful,
>> COMPILER-SPECIFIC enhancements now are *liabilities*!
>
> There is a reason I try very hard not to use any compiler-specific
> features in my source code.

IME, this is usually a win -- unless you live in a narrowly defined
application domain (same tools "forever", etc.)

> I should probably make it a habit to occasionally attempt to build my
> projects with alternative compilers, to ensure that I actually *have*
> avoided compiler-specific features.
>
> A friend of mine routinely builds his software with three different
> compilers.  It certainly avoids compiler-specific features, but it also
> explores the differences in the bugs in the different compilers. :-/

Somewhat "of necessity" (convenience?), I routinely (i.e., during the
course of any given week) expose my code to  4 or 5 different compilers
in different hosted environments.  I keep my "live" code on a box that
is up 24/7/365.  I can access it there and compile/debug under gcc/gdb.

Or, mount that filesystem on a Windows host and use a Windows-hosted
"native" compiler/debugger (e.g., Borland, MS, etc.).

Or, mount it on a Solaris (SPARC) host and generate objects for that
enviroment.

Or, use a cross-compiler/IDE and compile it for the desired target.

As a result, I see how different compilers react (complain!) to my code;
see different data encodings (endian-ness, floating point formats, etc.);
etc.

By routinely rotating through these different toolchains (host and target
environments), I see what I am possibly doing "non-portably" soon enough
to correct my style (I am largely a creature of habit and use the same
stanzas repeatedly in my code, etc.) before I've got too much invested
to make corrections "painful" (which, if you believe people to be lazy,
suggests I will opt for some OTHER way to avoid making the "necessary"
corrections).