"Thorsten Froehlich" <tho### [at] trfde> wrote:
> By the time when cluttering code with unnecessary macros is considered
> better code, I am going to jump out of the window!

By "better quality code" I mean the code that

1) generates less worning messages and thus

2) is less likely to fail.

As to the first point, I consider this a big virtue by itself -- at the very
least helping to spot warnings issued for actually buggy code. I for one
always use a custom POV-Ray compile, with my own additions, and mind you: it
is a real pain dealing with all those 3.5 changes that generate so many
warnings.

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... For instance, you cannot write a RIFF chunk ID like you do, you
have t use FOURCCs. Well, as far as I can tell (and I know you good enough
by now), at this point you would argue about the "broken format of a broken
OS", and "general inability to provide portable solutions for binary
formats", right? Then consider writing/reading text files:

  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.

Post a reply to this message

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

Thorsten Froehlich <tho### [at] trfde> wrote:
> It only generates warnings on broken compilers.

  Are you doing thus simply to taunt me?

  It seems impossible for you to understand that 'abcd' produces a different
value depending on the platform you are compiling to.
  If you, for example, read four bytes from a file to an integer and then
compare it with 'abcd', the result will depend on the platform the program
is compiled for.
  Thus, since you are probably writing code with is not portable across
platforms, it's your code which is broken and the warning is relevant.

  Putting the camera inside a non-hollow object in povray is perfectly
legal, yet povray warns about it. Does this mean that povray is broken?
No, it means that povray warns you that you might be doing something which
has unexpected results.
  This is exactly the same case as with the 'abcd' warning. It might be legal,
but it has a certain probability of not working as you expect in a different
platform than yours.

  POV-Ray does it. Why can't gcc do it?

  I kindly asked you before to stop that insulting behaviour, but you won't
do it. That starts to be rather irritating.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3d99c15b@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>  Are you doing thus simply to taunt me?

By now I am repeating it to tease you...

>   It seems impossible for you to understand that 'abcd' produces a different
> value depending on the platform you are compiling to.

No, I just fail to see is how this can possible cause a problem if the value
never leaves or enters the program.  If you can demonstrate that this, which
is the only way it is even useful in POV-Ray, can cause any problem, please
go ahead.  But don't criticize code for something it isn't even doing.
Maybe you should check what the code is doing with it...

    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

Thorsten Froehlich <tho### [at] trfde> wrote:
> No, I just fail to see is how this can possible cause a problem if the value
> never leaves or enters the program.  If you can demonstrate that this, which
> is the only way it is even useful in POV-Ray, can cause any problem, please
> go ahead.  But don't criticize code for something it isn't even doing.
> Maybe you should check what the code is doing with it...

  So what you are saying is that since POV-Ray does not use the multichar
constants in the wrong way, then they should remove that warning from gcc?
  Have you ever thought that POV-Ray is not the only program in the world?

  When I deliberately put a camera inside a non-hollow object, POV-Ray still
warns me about it, even though I am not doing anything wrong nor illegal.
I still don't see how this warning makes POV-Ray broken.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3d99ceb2@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>> No, I just fail to see is how this can possible cause a problem if the value
>> never leaves or enters the program.  If you can demonstrate that this, which
>> is the only way it is even useful in POV-Ray, can cause any problem, please
>> go ahead.  But don't criticize code for something it isn't even doing.
>> Maybe you should check what the code is doing with it...
>
>   So what you are saying is that since POV-Ray does not use the multichar
> constants in the wrong way, then they should remove that warning from gcc?
>   Have you ever thought that POV-Ray is not the only program in the world?

No, I said a compiler should not warn about correct code, which can be found
in millions of other programs as well.  If some people don't know C well
enough they deserve to be burned by their own mistakes.  The compiler should
not help me with thinks I know by default.  I said this before, didn't I?

So please, please, please, stop twisting my words around to claim things
they neither say directly nor can possibly say indirectly between the lines.

>   When I deliberately put a camera inside a non-hollow object, POV-Ray still
> warns me about it, even though I am not doing anything wrong nor illegal.
> I still don't see how this warning makes POV-Ray broken.

Well, POV-Ray will not and cannot function as expected.  So yes, it should
probably issue an error message...

    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

I think compiler warnings is an issue where no agreement is
possible.  I have worked for nearly 10 years with a group of
about 20 software developers.  They use a tool called
flexlint to scrub their C++ code.  They are a relatively
tight nit group, but I listened to them argue over this rule
and that rule for years.  They eventually dropped into a
voting system - some having larger votes - whenever deciding
to add or remove a check. This didn't make everyone happy
but things got done faster.

When communicating in non-native languages I try to remember
not to assume much emotional meaning in what is said.  It is
difficult enough to communicate with a person you know well,
in your native tongue and with them standing in front of
you.  Communication in a space like a newsgroup, in a second
language, with cultural differences - it is easy to end up
with everyone shouting into space.

Every one of you involved in this discussion is technically
competent. There are a thousand ways to roll a stone.

Post a reply to this message

In article <3D9A0B14.3082321F@attglobal.net>,
 "William F. Pokorny" <pok### [at] attglobalnet> wrote:

> Every one of you involved in this discussion is technically
> competent. There are a thousand ways to roll a stone.

Actually, there are infin...oh, never mind.

;-)

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> No, I said a compiler should not warn about correct code

  As I have said earlier, you are constantly confusing warnings with
error messages.

  Please read my lips: A warning is not an error message.

  Do you understand what does that mean?

  Error messages are issued when the code is incorrect. An error message
stops the compilation.
  When the code is correct, but suspicious, a warning can be issued. A
warning does not stop the compilation.
  Do you understand the difference between these two things?

  So what you are saying is wrong: Warning *must* warn about correct code,
and correct code alone. If incorrect code would only generate a warning,
that would be wrong. Incorrect code must generate an error.

  You also seem to fail to understand *why* warnings exist in the first
place.

> Well, POV-Ray will not and cannot function as expected.  So yes, it should
> probably issue an error message...

  Wrong. If there is no media nor fog in the scene, POV-Ray can function
correctly and moreover *does* function correctly. There's nothing wrong
in putting the camera inside an object. It's not an error and thus issuing
an error would be wrong.
  The point is that it can have some side-effects which are unexpected if
the scene uses fog or media and thus the warning is relevant.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

ABX <abx### [at] abxartpl> wrote:
> #define FOURCHARS_TO_INT(c1,c2,c3,c4) \

  Just to clarify things:

  I completely agree with Thorsten that this is bad. You should not make
ugly hacks in order to avoid a warning which you *know* is irrelevant for
the code in question. I completely oppose this suggestion.
  If you can get rid of a warning in a way that: a) does not actually
modify the actual code, but simply adds extra unambiguating syntax to
it (such as extra parentheses to unambiguate an expression) and b) makes
the code cleaner and clearer, then it may be ok to do it.
  However, if you are going to actually modify how the code works just
to get rid of an irrelevant warning, and the resulting code is uglier,
clumsier and even more dangerous, then that's definitely a no-no.

  So I fully agree with Thorsten with this.

  However, what I strongly disagree with is that gcc is somehow "broken"
or is a bad compiler because of this warning.
  The warning may be irrelevant in *this specific case*, ie. the POV-Ray
code, but that does not mean it's *always* irrelevant in all cases which
exist in the world.
  I also disagree with the idea that a compiler should not issue any
warnings about code which is correct according to the C++ syntax definition.
The fact that a piece of code is syntactically correct does not mean that
it works ok. That's exactly what warnings are for: To inform you that
the piece of code you just wrote might not work as you want. The warning
might be irrelevant in some cases, but it still can be of great aid in
many cases.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message