Re: Strange - a simple assignment statement shows error in VC++ but
works in gcc !
On 7 Apr., 12:55, James Kuyper <jameskuy...@verizon.net> wrote:
David Schwartz wrote:
[snip]
So, a person who writes a cast to shut up a warning, without
understanding that the resulting conversion will have consequences he
wasn't aware of, can be said to have intended that those consequences occ=
ur?
I am stepping sideways into this discussion, so forgive me if I have
missed some of the finer points.
First, I must state that so far I am mostly on the side of David
Schwartz. If a compiler comes with a warning, we have to first decide
if that warning is or could be reasonable. If we find the warning
reasonable, we redesign the code in order to make the warnings
disappear, and if the warning is unreasonable, we find a way to
disable it (or throw the compiler away ;-)).
The principle is that our code should compile clean.
But I also have a very strong dislike for conversions, and one of the
rules - at least in C - should be that you do not have any conversion
that is not accompagnied by a comment. If this simple and good rule is
adhered to, none of the problems mentioned in this discussion would
surface.
[snip]
Simply put, it reduces the possible cases. There is, without the cast,
one possible case that is not the case -- that the programmer had no
idea there was a conversion and therefore never considered its safety.
The cast rules out this case.
Every one of the cases I was referring to involved a cast written by a
programmer who had no idea that there was a conversion (or at least,
that it was a conversion with non-trivial consequences), and who
therefore had not in fact considered whether or not it was safe.
These problems would be determined during codereview, and the
programmer would learn that he would need to know his tools better
before writing any more code.
The cases I summarized are
clear counter-examples to that assertion, and the frequency with which
I've seen such things belies that implication.
They are not counter-examples. If a programmer writes '(unsigned) j'
he is vouching for the safety of the cast, just as when he writes any
code he is vouching for it. Just because he was mistaken in doing so
doesn't change the fact that he did so.
If someone signs a document he does not understand, and it contains
assertions that he would have disagreed with, had he understood them,
does this mean that he now agrees with those assertions? Writing his
signature on the document does not magically change his mind to match
the words of that document.
But he is not just signing the document - he has a lawyer (the code
reviewer) holding his hands. Even in places where you don't really
review code you should review code from the programmers that you do
not know.
Similarly, inserting a cast in code does not magically change the
developers intention to match what will actually happen. A convention of
inserting casts only when you are willing to vouch for their safety does
not magically bring people into conformance with that convention who
wrote their code without being aware of it, or without a desire to
conform to it. I do not defend the competence of these programmers; I
merely point out that they do exist, and code written by such people has
to be dealt with occasionally.
[snip]
In the typical data path for my programs, data is read from a file into
objects with typedefs associated with the HDF library like float32. It
is then passed to the SDP Toolkit library which requires that they have
the type PGSt_double (it is not essential that you know what those
libraries are; it is sufficient that you understand that they are third
party libraries that define platform-dependent typedefs for the types
used in the library's interfaces). For some purposes, the data is passed
to C standard library functions which require that it be of type
'double'. When all processing is complete, the data is written to the
output file with the type float32 again.
Yuck!
That's a minimum of three casts for every piece of data flowing through
the program. One of the first things I did when I became responsible for
these programs was to rearrange it so that the minimum was actually
achieved; the original code performed at least twice the minimum number
of conversions. It's not uncommon for half the lines that refer to a
give piece of data to involve converting it from one type to another.
That's not true in the science code, but actual science code constitutes
only about 10% of my programs; the remaining 90% is involved with
pushing data around from one place to another.
I don't understand why all these standard conversions have to take
place using basic conversion functions. In your case (and being bound
to C), I would have small ideomatic functions do the conversion
instead - validating range in debug mode. That would result in only
six total conversions being performed.
/Peter