Thorsten,

I am becoming increasingly upset with you attiude towards other programmers.
"Ignorance", "broken compilers", etc. is all I hear most of the time. I have
been professionally programming for more than 12 years, and have developed 2
commercial compilers among other stuff. So the word "ignorance" is not what
I would like to hear in a responce to a viable suggestion.

I demand that you soften your stance.

Wake up, Thorsten. You're part of the POV-Ray community, but you're starting
to ignore all but the most trivial inputs. And this starts to worry me a
lot, since the POV-Ray is seamingly completely in your hands.

I could defend each and every my point; at the very least, as viable
alternatives -- but this is becoming almost impossible, as you are becoming
increasingly hostile. I prefer to listen rather than to speak, but on all
those few occations that I spoke, you appeared to be deaf (your right, so
it's OK :-) and offensive. Previously, I used to just give up (although
always have had more to say to defend my point) and just save my nerves...
but this time it just gone too far.

Could you pleas just "discuss", and not "explain" as you always do?

ABX has provided a better-style alternative to your code. I seconded that,
and gave my reason why I really think this code is a BETTER QUALITY code (==
following what is often referred to as "good programming habits"). NOT more
or less "correct" / "broken" etc. given its CURRENT use in POV-Ray. The
integer values of sequences like (('a'<<8)|'b') are NOT implementation
dependent AS LONG as we stick with ASCII (i.e. the only implementation
dependent things are integer values of 'a' and 'b'). With multi-character
constants, endianness comes into play as well.

I can reword my point this way: if you use multi-character constants, then
integer value of the constant depends upon BOTH character values and
endianness of the target machine. If you use defines (similar to FOURCCs),
then integer value (NOT internal representation of that value!) of the
expression depends upon JUST character values. Therefore, I consider the
latter code of a better quality. And if two compilers both use ASCII for
character representation (and have at least 32-bit longs, of course), then
yes, the read/write code I quoted is portable, even regardless of the
endianness of the target platform. How many C/C++ compilers out there are
not using ASCII codes for alphanumeric characters these days? What
compilers/environments were you talking about?

If you do believe some/all of my points are not valid, I would be glad to
hear from you. But PLEASE be more specific and less personal.

Regards,
Vadim.

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3d998790$1@news.povray.org...
> In article <3d9980e2$1@news.povray.org> , "Vadim Sytnikov"
<syt### [at] rucom>
> wrote:
>
> > 1) generates less warning messages and thus
>
> It only generates warnings on broken compilers.  If the compiler you use
is
> broken, the solution is to switch to a compiler which is not broken or to
> workaround the broken compiler by disabling the particular warning by
hand.
>
> > 2) is less likely to fail.
> <snip>
> > As to the second... Thorsten, believe it or not, compiler writers are
not
> > idiots. Not all of them. There ARE cases when simple multi-character
> > constants would not work, while #defines or similar means would rectify
the
> > situation...
>
> No, this is nonsense.  They do work as specified everywhere!
>
> Your example is yet again one of those reading data from disk misuse
cases.
> Maybe you do not understand that "implementation defined" is exactly what
> you show?  It does not even have to work when using two compilers on the
> same platform.  An "implementation" is a single compiler on a single
> platform.
>
> Maybe you have not noticed, but POV-Ray neither reads nor writes
> multicharacter constants.  It does not because that behavior is
> implementation defined.  So there is absolutely nothing wrong and nothing
> that can ever break anywhere either.
>
> >   unsigned long prog = FOURCHARS_TO_INT('A','B','C','D');
> >   fprintf(outfile," %lu", prog);
> >   ...
> >   fscanf(infile," %lu",&prog);
> >   if( prog==FOURCHARS_TO_INT('A','B','C','D')) { ... }
> >
> > This code would work ACROSS MOST platforms. While alternative (your)
> > approach would fail if files are to be transferred between e.g. PCs and
old
> > Macs (with their Motorola 68k BE CPUs). And even if we are to port it to
> > some EBCDIC-based dinosaur, we still can just modify the macro
definition
> > accordingly, not every piece of code dealing with constants. So the code
is
> > MORE portable and thus BETTER. Please note: not "absolutely portable and
> > thus the BEST", but still worth trying.
>
> I am not really sure if I should be upset or offended by such ignorance as
> this issue has already been discussed and explained well in this thread.
> Please read the whole thread first before repeating something already
> discussed.  If you don't want to read the whole thread, please stop adding
> noise to the discussion.
>
>
>     Thorsten
>
>
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: tho### [at] trfde
>
> Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message