>> You only get 710? :)  Most of them are precision warnings

>Ron, it is nearly useless to try to remove this because it all is a result
>of the macro DBL

DBL x = 2.0;

becomes

DBL x = (DBL) 2.0;

Is there anything unreasonable or dangerous about doing this?
I think it is worth keeping the MS compiler quiet, because sometimes
things like signed/unsigned, unused, uninitialised variable, actually
help solve problems.

Has anyone run POV through Purify, or Bounds Checker?

Post a reply to this message

Yes, but you'll still get errors for the Assign_SNGL_Vect macro... it
doesn't know if you're assigning from doubles or singles.

-Nathan

Nigel Stewart wrote:
> 
> >> You only get 710? :)  Most of them are precision warnings
> 
> >Ron, it is nearly useless to try to remove this because it all is a result
> >of the macro DBL
> 
> DBL x = 2.0;
> 
> becomes
> 
> DBL x = (DBL) 2.0;
> 
> Is there anything unreasonable or dangerous about doing this?
> I think it is worth keeping the MS compiler quiet, because sometimes
> things like signed/unsigned, unused, uninitialised variable, actually
> help solve problems.
> 
> Has anyone run POV through Purify, or Bounds Checker?

Post a reply to this message

In article <36c76403.0@news.povray.org> , "Nigel Stewart" 
<nig### [at] eisanetauNOSPAM> wrote:

> DBL x = 2.0;
>
> becomes
>
> DBL x = (DBL) 2.0;
>
> Is there anything unreasonable or dangerous about doing this?

It is unreasonable: DBL x = 2.0; is c acompletly legal and *well* readable
statement. DBL x = (DBL) 2.0 is less readable. Putting unnecessary code into
POV-Ray just to get rid of *one* compilers warnings is _not_ reasonable.

> I think it is worth keeping the MS compiler quiet, because sometimes
> things like signed/unsigned, unused, uninitialised variable, actually
> help solve problems.

Ever considered a different compiler? ;-)


    Thorsten

Post a reply to this message

>> DBL x = 2.0;
>> becomes
>> DBL x = (DBL) 2.0;
>>
>> Is there anything unreasonable or dangerous about doing this?
>
>It is unreasonable: DBL x = 2.0; is c acompletly legal and *well* readable
>statement. DBL x = (DBL) 2.0 is less readable.

    But the meaning is more precise.  I think the benefit of clarity and
    portability outweigh your concern - but that's entirely my opinion.

    While the first line says "I want 2.0 assigned to x", the second says
    "I knowingly want 2.0 converted to a DBL, and assigned to x".

    For example, if you use a float as an intermediate result, treat it as a
    double later, and wonder why you're not getting the expected precision -
    the explicit cast will be something of a clue.  Your preference is
    to be oblivious to truncation.

    It's a fine point, but I think it is more than just a platform/compiler
    quirk - in this case Microsoft have done something for a sound
    technical reason.  (I wish they'd do so more often!)

Post a reply to this message

In article <36c7a4da.0@news.povray.org> , "Nigel Stewart" 
<nig### [at] eisanetauNOSPAM> wrote:

>>> DBL x = 2.0;
>>> becomes
>>> DBL x = (DBL) 2.0;
>>>
>>> Is there anything unreasonable or dangerous about doing this?
>>
>>It is unreasonable: DBL x = 2.0; is c acompletly legal and *well* readable
>>statement. DBL x = (DBL) 2.0 is less readable.
>
>But the meaning is more precise.  I think the benefit of clarity and
>portability outweigh your concern - but that's entirely my opinion.

Hmm, there are no (and as far as I know have never been) portability
problems with floating point type casting. While I is might sometimes be
useful to do so in code like

SNGL sfp = 2.0;
DBL dfp = 8.0;
sf = (SNGL)(spf * dfp);

doing it for DBL x = (DBL) 2.0 is not only less readable, but even
redundant! It is defined in the ISO C++ standard that a type float value
will be *implicitly* converted to a type double value without loss of
precision. If you suggest doing DBL x = (DBL) 2.0 why not doing the same for
short x = (short)5, or long y = (long)7 because the native type of 5 and 7
would is assumed to be int by some compiler...
My opinion (and those who wrote the ISO C++ standard) is that writing
explicit conversion in these cases is redundant.

>While the first line says "I want 2.0 assigned to x", the second says
>"I knowingly want 2.0 converted to a DBL, and assigned to x".

I am wondering: What is the type of "2.0" for you? For me its type is the
largest floating point type supported by the implementation.

>For example, if you use a float as an intermediate result, treat it as a
>double later, and wonder why you're not getting the expected precision -

Yes, then you will have to check manually *every* cast because your compiler
can no longer tell you where the implicit conversion is happening! The goal
is to use as few casts as necessary, and casting *is* dangerous,for example
signed char f;
f = (signed char)(180); // Assumes sizeof(signed char) == 1 !!!
will no longer show an (optional) compiler warning because you explicitly
*forced* the compiler to do this while you have a chance to find the problem
writing
signed char f;
f = 180;

>the explicit cast will be something of a clue.  Your preference is
>to be oblivious to truncation.

No, as the example above shows, it does exactly the opposite!

>It's a fine point, but I think it is more than just a platform/compiler
>quirk - in this case Microsoft have done something for a sound
>technical reason.  (I wish they'd do so more often!)

Well, most compilers have this, but then they have it as an *option*, they
don't force these warnings!
And  my opinion is that *standard* (Microsoft also worked in the ISO C++
commitee) behaviour should not show warnings by default. Doing so is a
misleading bug.


    Thorsten

Post a reply to this message

>>It's a fine point, but I think it is more than just a platform/compiler
>>quirk
>
>Well, most compilers have this, but then they have it as an *option*, they
>don't force these warnings!

    One man's bug is another man's feature.  As I recall your objection -
    "Just because MS VC complains, doesn't mean we should fix it"
    If you're not using MS VC, why complain about the behavior of it?

    I think it is appropriate to be explicit about floating point
    truncation in the context of numerically sensitive code.
    To me, an explicit cast indicates a "Yes I'm sure I want
    to do this", to you it's a nuisance.  I've found that paranoid
    warnings actually help avoid problems later on - why do
    you insist that making use of this information is
    "non-standard" or that the compiler is "buggy" for doing
    so?

    I am not advocating "automatic explicit casting" as your
    example may suggest.  I like to see code compiling clean
    on different platforms.  I don't mind having to dot my
    i's and crossing my t's to appease each different compiler,
    it actually reveals something about the maturity and
    philosophy of the compiler.

    It sounds like we're both arguing from experience,
    from different perspectives.  You're pointing to
    the standard treatment of floats and doubles in
    the context of implicit casting.  I'm pointing to the
    (pragmatic) benefit of identifying bugs early.
    We like to make different trade-offs.

    And uh, I think we both need to keep in mind that this
    argument is pretty academic.  It doesn't bother me
    greatly enough to upset a fellow povray developer,
    or get them offside.  So, if you're feeling that I'm a total
    heretic for not agreeing with you, let me know and
    I'll argue less strongly.. :-)  I 99% agree with everything
    you say anyway!

Post a reply to this message

"Nigel Stewart" <nig### [at] eisanetauNOSPAM> writes:
[...]
> 
> Has anyone run POV through Purify, or Bounds Checker?

Yes. I've made some tests with purify on Sun Solaris. There weren't any 
errors reported. In my opinion, this is an amazing quality for software.
Of course, I could only test a small subset of the POV-Ray features. 

By the way, I have found some problems with the isosurface patch. One has 
been fixed by Suzuki Ryoichi. Unfortunately, some other errors appear only in 
very large scenes (i.e. hundreds of parametric surfaces).

Thomas

-- 
http://www.fmi.uni-konstanz.de/~willhalm

Post a reply to this message

>If you suggest doing DBL x = (DBL) 2.0 why not doing the same for
>short x = (short)5, or long y = (long)7 because the native type of 5 and 7
>would is assumed to be int by some compiler...


Ahhh...  Here is our misunderstanding.  You interpret me as saying
that you should never rely on implicit casting.  My meaning is that
you need to be careful about implicit casting of floats and doubles.

Post a reply to this message

In article <36c7e6b6.0@news.povray.org> , "Nigel Stewart" 
<nig### [at] eisanetauNOSPAM> wrote:

> Ahhh...  Here is our misunderstanding.  You interpret me as saying
> that you should never rely on implicit casting.  My meaning is that
> you need to be careful about implicit casting of floats and doubles.
>
> And uh, I think we both need to keep in mind that this
> argument is pretty academic.  It doesn't bother me
> greatly enough to upset a fellow povray developer,
> or get them offside.  So, if you're feeling that I'm a total
> heretic for not agreeing with you, let me know and
> I'll argue less strongly.. :-)  I 99% agree with everything
> you say anyway!

Yes, that is true. I have no problem with your argument nor with the way you
are arguing. (And I hope you don't have a problem with my style either :-)
It is just that we disagree in when some casts are useful and when a
compiler should notify the programmer by default when implicity casts are
used.


    Thorsten

Post a reply to this message

On Sun, 14 Feb 1999 19:53:29 -0600, Thorsten Froehlich wrote:
>In article <36c76403.0@news.povray.org> , "Nigel Stewart" 
><nig### [at] eisanetauNOSPAM> wrote:
>
>> DBL x = 2.0;
>>
>> becomes
>>
>> DBL x = (DBL) 2.0;
>>
>> Is there anything unreasonable or dangerous about doing this?
>
>It is unreasonable: DBL x = 2.0; is c acompletly legal and *well* readable
>statement. DBL x = (DBL) 2.0 is less readable. Putting unnecessary code into
>POV-Ray just to get rid of *one* compilers warnings is _not_ reasonable.
>
>> I think it is worth keeping the MS compiler quiet, because sometimes
>> things like signed/unsigned, unused, uninitialised variable, actually
>> help solve problems.
>
>Ever considered a different compiler? ;-)

Ever run PC-Lint against POV?  I haven't tried yet, but in my experience
with real code, it's far more picky than Visual C++ is.

Post a reply to this message