Re: help with statistics library

On Thu, 26 Apr 2007 10:19:51 +0000, Richard Heathfield wrote:

Lionel B said:

On Thu, 26 Apr 2007 00:34:23 +0000, Jens Thoms Toerring wrote:

Richard Weeks <rweeks@xxxxxxxxxx> wrote:
http://members.shaw.ca/bystander/statsource.html

My first impression after a short look is that it looks rather
well-written and I so simply start with nit-picking:

[...]

4) There are a few instances where you cast where it isn't necessary.

<snip>

Just a nitpick of your nitpick: I tend to take the opposite view that
explicit casts are preferable to implicit casts, since they make the
intention of the code clearer (at the expense of some verbosity);

Just a nitpick of your nitpick of his nitpick: a cast is an explicit
conversion, so "implicit cast" is a contradiction in terms.

Doh! For "cast" read "conversion"

if I see:

double x,y;
int n;
/* lots of code */
y = x/n;

then I have to remind myself (with reference to the declaration of n)
that casting is taking place.

But it isn't! A conversion is taking place, sure, but there is no cast
here.

Ditto.

Furthermore, there is no need to worry about it, since the correct
result will be obtained anyway.

I don't think I even implied that omitting a cast would result in
incorrect code; simply that casts can make the intention of the code
somewhat more transparent to someone (me!) reading it.

Basically, if I *don't* see a cast where an implicit conversion is going
to happen, there's always in the back of my mind: "Did the programmer
realise that there's a conversion here? Is this what they intended? Did
they think about it?", whereas if I see a cast then I *know* the
programmer has thought about it.

The only conceivable issue is if the
type of x were to change (to an integer type) without a corresponding
change in y. If (and, I believe, *only* if) that were a possibility,
then, from a defensive programming perspective,

I hadn't even got round to mentioning the potential for error-proneness
of implicit conversions, but now that you bring it up...

either you should cast or (and, in my view, preferably) you could split
the division like this:

y = x;
y /= n;

in which case the division will be done using floating-point arithmetic.
I accept that my preference for this way of avoiding the cast might be
considered - um - eccentric. :-)

I'll accept that too ;-)

--
Lionel B
.

Relevant Pages

  • Re: Replies to Upcasting vs downcasting.
    ... I take this example to be a conversion cast, although I can see how it ... could be considered a downcast. ... and "widening conversion" to encompass both reference conversions and non-reference conversions. ... Java always requires a cast for a narrowing conversion. ...
    (comp.lang.java.programmer)
  • Re: Terminology : casting/conversion
    ... Is this an "explicit" cast? ... conversion even if the type of the expression is the ... Here are p & p2 are pointers but the compiler "implicitly" converts ... this parse tree is almost unconnected to the ...
    (comp.lang.c)
  • Re: Collections
    ... cast an abstract class into a derived class ... First remember that DirectCast is the Cast operator, while CType is the ... Conversion operator that will do a Cast if the cast is allowed. ... remember that Casting & Converting are separate ...
    (microsoft.public.dotnet.languages.vb)
  • Re: C variable retyping
    ... whose type is given by the cast. ... >an integer, no conversion is done, and c is used, within the ... In other words, you may take a pointer value, then use a cast to ... which is probably why the C99 folks decided to allow it ...
    (comp.lang.c)
  • Re: Function Pointers
    ... Just a heads-up - you don't need the cast. ... lossless conversion between void * and function pointers, ... I thought you couldn't have a generic function pointer like the 'void ... there is no generic function pointer type. ...
    (comp.lang.c)