C/C++ is not my native platform so playing with patches is not trivial thing
for me. I have (partially) learned it long time ago and now use it only for
POV patching. I'm changing various sourcefiles but I have not natural skill to
select which warning is important. So to extract my own I started to fix
sources to avoid all "built-in" warnings when -Wall setting is used with gcc
3.1 (under DJGPP in my case). I know this effort is nothing becouse POV will
be rewritten but I do it for my knowledge and comfort of compiling. I do all
changes patch-like method controlled with definitions like "#define
AVOID_TYPE_CONVERSION_WARNINGS_PATCH" in frame.h. But I have met two warnings
I can't fix (perhaps there is more but I'm currently did 50% of files). I
looking for help in fixing those warnings:

1. "aggregate has a partly bracketed initializer"

It is reported for line 105 of file_pov.cpp. This line closes definition of
gPOV_File_Extensions array. There is correct number of entries in array
initializer. There is correct number of closing } for {. I have tried to
replace for example every line like:
  { ".jpg",  ".JPG",  ".jpeg", ".JPEG" }, // POV_File_Image_JPEG 
with line like
  { { ".jpg" },  {".JPG"},  {".jpeg"}, {".JPEG"} }, // POV_File_Image_JPEG 
and then compiler reported error instead of warning (sorry, can't recall it's
content here). So how to remove this warning ?

2. "multi-character character constant"

It is reported for some header files like for example povms.h (lines 192-215).
There is a note about this warning in gnu gcc documentation: "Usually they
indicate a typo in the user's code, as they have implementation-defined
values, and should not be used in portable code." Portable code? Hmm, so how
to fix this ?

I have additional platform specific question. I can't write warnings of
compiler with gcc under djgpp to file with simple redirection
  gcc ... > file.txt
It creates file.txt but warnings are outputted to the screen. Is it general
rule for gcc or just problem of djgpp port ? Is there switch in options like
for POV ? I can't find anything like this in documentation. And sorry, I'm not
unixer at all.

ABX

Post a reply to this message

In article <28gtou4t56f843790s28f5r236q80k3boi@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> warnings when -Wall setting is used with gcc

Using all gcc warning is pointless.  Gcc supports 8 and 16 bit platforms,
and many warnings the frontend will emit make a lot of sense when developing
for an embedded processor, but they just waste your time on desktop or
server system.

In particular the implicit type conversion warnings are the biggest nonsense
in both gcc and VC because C as well as C++ explicitly define which implicit
type conversions exist and how they behave.  It is obvious that a compiler
should not warn about perfectly legal and well behaving code by default.  If
it does it tries to enforce a certain style of programming the compiler
developer seems to prefer, but in this case it fails the basic usability
requirement of all software, which is the a machine should never be the
master of a human!

Of course, setting the maximum warning level changes this rule (it should
then warn about everything it can detect), but such a thing does not belong
into the default warning set, but the all warning set (gcc and VC warn by
default about this incorrectly).

In particular important is that explicit conversions, if used incorrectly to
get rid of compiler warnings can degrade performance (because you could be
tempted to first bit-mask integers for example).

On the other hand the compilers do fail miserably to detect truly
non-portable and dangerous code like that in the octree.cpp, also it is well
within their theoretical power to detect such code with little overhead in
their dataflow analysis module...

> 1. "aggregate has a partly bracketed initializer"

No idea what it is complaining about.  The code is perfectly legal.

> 2. "multi-character character constant"

These are nonsensical compiler warnings for perfectly legal and portable
code as long as the platform being used has 32 bit or bigger ints.  As
POV-Ray will not run on 16 bit processors, you can just disable those
warnings, like the compiler developers should have done in the first place
when the target code is for a platform whose ints (or other variable sizes)
can hold the data without problems.

    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

On Mon, 23 Sep 2002 10:51:19 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> In particular the implicit type conversion warnings ...

Thanks for your whole note.

> > 1. "aggregate has a partly bracketed initializer"
>
> No idea what it is complaining about.  The code is perfectly legal.

So I will try ask in gcc/djgpp related forums. Perhaps it is some bug.

> > 2. "multi-character character constant"
>
> you can just disable those warnings

I did that quickly.

ABX

Post a reply to this message

On Mon, 23 Sep 2002 10:27:42 +0200, ABX <abx### [at] abxartpl> wrote:
> I can't write warnings of compiler with gcc under djgpp to file

I can, http://www.delorie.com/djgpp/doc/utils/utils_7.html for others.

ABX

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Using all gcc warning is pointless.

  I tend to disagree.

  In our project, which I'm working, we have (at this moment) 71695 lines of
code in 359 source files. We get 0 warnings when compiling with the flags
"-Wall -W -pedantic -ansi". I don't remember making any compromises in order
to keep gcc happy.
  So it's perfectly possible to avoid the warnings.

> In particular the implicit type conversion warnings are the biggest nonsense
> in both gcc and VC because C as well as C++ explicitly define which implicit
> type conversions exist and how they behave.

  You seem to misinterpret the idea behind the warning.
  Yes, the standard defines how explicit conversions work. However, the
idea behind the warning is that converting from a bigger type to a smaller
type loses information and when this is done implicitly, it's often a mistake
from the part of the coder (ie. the coder didn't notice that he is assigning
for example a double to an integer, thus losing information, which could
result in the code not working).
  What gcc is doing is to recommend you to make the conversion explicit.
That has absolutely no effect in performance, as it's converted to the
exact same code internally, and it makes your code more clear: You are
kind of "documenting" that you are indeed making the conversion deliberately
and that it's not just a programming mistake, and most importantly, it's like
a comment to someone reading your code that "note: there's a conversion done
here". The reader doesn't have to wonder if you just made a mistake there or
you are doing it on purpose.
  Of course the most important use of this warning is when you actually make
the mistake and the compiler warns you and then you can fix it, instead of
wondering why your code doesn't work.

  I see nothing wrong with this.

>  It is obvious that a compiler
> should not warn about perfectly legal and well behaving code by default.

  You seem to think that a warning is the same thing as an error.
  If the code is perfectly legal, then the compiler must not issue an error,
naturally. However, I see nothing wrong in the compiler issuing warnings on
suspicious code, which may be a mistake from the part of the programmer.
  For example, this is perfectly legal:

void foo()
{
  do_something;
  return;
  do_something_else;
}

  However, that looks quite suspicious. The last command is never executed
(and the compiler will most probably just optimize it away). However, it's
quite improbable that the programmer made that deliberately (what's the
point in writing code which is clearly never executed?).
  Of course with code that is as straightforward as that it's pretty obvious.
However, with more complicated code, with many ifs etc, it might not be
as obvious that a certain part is never executed, and thus it's most probably
a programming mistake. The warning is quite useful.

  Warnings are not about the code being legal or illegal. It's about helping
the user with suspicious-looking code.
  Warnings have often helped me catching mistakes at compilation time, which
is a great help.

  Don't bother telling me that a warning has never helped you catching a
mistake, because I won't believe it.

> In particular important is that explicit conversions, if used incorrectly to
> get rid of compiler warnings can degrade performance (because you could be
> tempted to first bit-mask integers for example).

  Even if someone would make that needless bit-mask, any modern compiler
is probably so smart that it will optimize it away.

  Even though many times compilers are quite poor at optimizing some things,
in other cases they are surprisingly clever. For example, I once tested a
code like this:

(with a, b and c being unsigned ints):

  a = (b<<c)|(b>>(32-c));

  When I looked at the asm code generated by the compiler, to my surprise
it had compiled that complicated statement as one single rotation command,
instead of making a substraction, two shifts and an or.

>> 2. "multi-character character constant"

> These are nonsensical compiler warnings for perfectly legal and portable
> code as long as the platform being used has 32 bit or bigger ints.  As
> POV-Ray will not run on 16 bit processors, you can just disable those
> warnings, like the compiler developers should have done in the first place
> when the target code is for a platform whose ints (or other variable sizes)
> can hold the data without problems.

  Are you sure that there may not be a problem with endianess when using
multi-character constants?
  For example, consider a code like this:

FILE* infile = fopen(...);
int fileID;
fread(&fileID, 4, 1, infile);
if(fileID != 'RIFF') { error("Wrong file type"); }

  Will that work in a high-endian/low-endian system?

  If it does not work, then the warning is very useful.

-- 
#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

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

>   What gcc is doing is to recommend you to make the conversion explicit.
> That has absolutely no effect in performance, as it's converted to the
> exact same code internally, and it makes your code more clear: You are
> kind of "documenting"

Why should a compiler force the programmer to bloat the code?  If those who
specified the standards had intended to prevent implicit conversions they
could have done so.  It is not the compiler writers job to second-guess
those who made the standard nor those who write code following the standard.

As I pointed out, it is good to have such a warning available, just like
many other warnings; but this does not imply that legal code should cause
any warning.

let me show this by a different example:  Does gcc issue a warning if I call
a function inside the argument list of another function, for example
"foo1(foo2(),foo3(),5)"?  My guess would be no seeing many people make such
a mistake by having foo2 and foo3 depend on some order.

I assume you agree with me that here not only something implicit is going
on, but also something implementation defined.  Yet there is no warning, or
maybe in the latest gcc versions there is...?

So, why warn for the well-defined implicit conversion but not for the much
more dangerous function call? -- I already answered this as it is the
compiler writers personal opinion that all conversions should be explicit.
That is fine, but as the standard does not cover this the compiler is
issuing the warning incorrectly if, and only if, it was not requested to
issue this warning by the programmer.

> You seem to think that a warning is the same thing as an error.

Please quit this nonsense.

>  Are you sure that there may not be a problem with endianess when using
> multi-character constants?

Yes.

> FILE* infile = fopen(...);
> int fileID;
> fread(&fileID, 4, 1, infile);
> if(fileID != 'RIFF') { error("Wrong file type"); }
>
>  Will that work in a high-endian/low-endian system?

Your example by itself is incorrect because writing any type to a file is
specified to be implementation defined.  It has nothing to do with a
multicharacter constant.  It will fail if you write for example the integer
1234567 to a file as well.  Obviously the compiler does not warn you about
specifying integers.  And nobody claimed a multicharacter-constant is a
string, expect I missed that so far!

Again you are claiming something to be suspicious which is well-defined
within the standard.  If the compiler writers do not like multi-character
constants, that is again their personal opinion.

Those who specified the standards, which, as I should add, have been
extensively peer-reviewed, simply did something this particular compiler
writer does not like.  That does not entitle the compiler writer to let the
compiler issue a warning by default.

To clarify my point:
* By default a compiler should only issue warnings if some assumption made
by the program is ambigious by the standard specification itself (there are
several such cases).
* A compiler should offer additional warnings for all logical program it can
detect.
* The compiler writer has to assume the user of the compiler is a
professional just like he is and knows what he is doing.  The compiler
writer may not try to teach the compiler user by default.


    Thorsten


PS:  The correct terms are Little Endian and Big Endian.

____________________________________________________
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:
> Why should a compiler force the programmer to bloat the code?

  You are still acting like a warning was an error. The compiler is not
forcing you to do anything.

  And if you want to avoid "bloating the code", then don't use comments at
all and write everything with the minimal amount of whitespace.
  Writing extra code is not always bad, but can be all the contrary. If it
makes the code more clear, then it's good.

>  If those who
> specified the standards had intended to prevent implicit conversions they
> could have done so.  It is not the compiler writers job to second-guess
> those who made the standard nor those who write code following the standard.

  I don't understand why you deliberately misread what I said. I didn't
say that the compiler is preventing implicit conversions. I said that if
an implicit conversion is losing information, then that can be a programming
mistake and the compiler is warning about it.
  The compiler does not warn about converting from a smaller type to a
larger one. Why? (Reading your text one would get the impression that
it warns about those as well.)

> As I pointed out, it is good to have such a warning available, just like
> many other warnings; but this does not imply that legal code should cause
> any warning.

  Now I don't understand. First you say that it's good to have the warning
available, and immediately after that you say that it should not be issued.
Which is it?

> let me show this by a different example:  Does gcc issue a warning if

  I know that gcc does *not* warn about many things it should, and I could
list quite many things here if I wanted. However, I don't see how that is
relevant to the question that gcc *does* warn about some other things.

  I don't understand the ideology "if it doesn't warn about this, it shouldn't
warn about anything at all".

>> FILE* infile = fopen(...);
>> int fileID;
>> fread(&fileID, 4, 1, infile);
>> if(fileID != 'RIFF') { error("Wrong file type"); }
>>
>>  Will that work in a high-endian/low-endian system?

> Your example by itself is incorrect because writing any type to a file is
> specified to be implementation defined.

  I fail to see where does that code write anything to a file.

  But as you say, that code is not good, and the compiler warning about it
is only a good thing, don't you think?
  You are saying that the compiler should not warn about that (because it
will not warn if you compare the int you read from the file with a constant,
because that's just way too difficult for the compiler to catch).

> * The compiler writer has to assume the user of the compiler is a
> professional just like he is and knows what he is doing.  The compiler
> writer may not try to teach the compiler user by default.

  I am a professional. I make mistakes. The compiler has sometimes helped me
finding them.

-- 
#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

On Mon, 23 Sep 2002 13:58:15 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> As I pointed out, it is good to have such a warning available, just like
> many other warnings; but this does not imply that legal code should cause
> any warning.

I did not mean to start another war in the cream of our small society. My
intention was to remove some obvious typos. For example: there is a lot of
calls to compile_instruction() function in fncode.cpp where fourth parameter
is 0. But for some strange reason three of them use 0.0 instead of 0. I can't
call it 'favourite coding style' becouse other calls clearly shows this
favourite style. I think one thing is legal code, second is legal, clean and
consistent code. Just two cents from amatour C programmer.

ABX

Post a reply to this message

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

>>  If those who
>> specified the standards had intended to prevent implicit conversions they
>> could have done so.  It is not the compiler writers job to second-guess
>> those who made the standard nor those who write code following the standard.
>
>   I don't understand why you deliberately misread what I said. I didn't
> say that the compiler is preventing implicit conversions. I said that if
> an implicit conversion is losing information, then that can be a programming
> mistake and the compiler is warning about it.

No, you said "What gcc is doing is to recommend you to make the conversion
explicit." and I never said what you imply, so this is pointless.

In any case, I don't have the time to waste in another game with you trying
to turn my words around until they say something you don't like.  I said
what I said and it is very clear, if you don't understand it, so be it.

I am leaving this discussion here, simply ignoring the rest of your post.

    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

In article <gr0uoucgievsj2oa80j8cuqner7e9j7ean@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> there is a lot of
> calls to compile_instruction() function in fncode.cpp where fourth parameter
> is 0. But for some strange reason three of them use 0.0 instead of 0

Oh, this is easy.  It so happens that the constant table defines the
constant at array locaction "0" to be zero and the constant at array
locaction "1" to be one.  For maximum clarity, replace it with
"POVFPU_AddConstant(0.0)", which will have the same effect.

    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

On Mon, 23 Sep 2002 15:51:04 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> Oh, this is easy.  It so happens that the constant table defines the
> constant at array locaction "0" to be zero and the constant at array
> locaction "1" to be one.  For maximum clarity, replace it with
> "POVFPU_AddConstant(0.0)", which will have the same effect.

Is this replacement for all 0 and/or 0.0 ? Does this influence only parsing
time?

ABX

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> ignoring the rest of your post.

  A lesson in politeness?

-- 
#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

In article <687uouc7i1dtlqjjj2coji4lq7d2a7ej9s@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> Is this replacement for all 0 and/or 0.0 ? Does this influence only parsing
> time?

For the 0.0 only.  It does not really influence parsing time.

    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

Warp <war### [at] tagpovrayorg> wrote in news:3d8f1f72@news.povray.org

> Thorsten Froehlich <tho### [at] trfde> wrote:
>> ignoring the rest of your post.
>   A lesson in politeness?

it's quite sad to see flame-war beetween, as I see, good programers ;)

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
> it's quite sad to see flame-war beetween, as I see, good programers ;)

  Differing opinions is one source of progress, I think.
  If everyone would think in the exact same way, then there would be
a lot less room for innovation.

-- 
#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

On Mon, 23 Sep 2002 10:51:19 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:

>In article <28gtou4t56f843790s28f5r236q80k3boi@4ax.com> , ABX 
><abx### [at] abxartpl>  wrote:
>
> > warnings when -Wall setting is used with gcc
>
> Using all gcc warning is pointless.

But somehow I did it :-)
I have now warning-free version of sources. And now I can say what I changed -
warnings were mostly generated with additions/changes introduced in 3.5. Old
code from 3.1 and earlier versions did not cause warnings usually. I can say
nothing about (x)windows compilation. I did it only with pure dos/unix
compile.

> > 1. "aggregate has a partly bracketed initializer"
>
> No idea what it is complaining about.  The code is perfectly legal.

It is array of structures with one element - array. It have to be "double
bracketed" (is this english correct ?). So instead of:
  { ".jpg",  ".JPG",  ".jpeg", ".JPEG" },
it should be:
  { { ".jpg",  ".JPG",  ".jpeg", ".JPEG" } },

> > 2. "multi-character character constant"
>
> These are nonsensical compiler warnings for perfectly legal and portable
> code as long as the platform being used has 32 bit or bigger ints.

It helped to add definition:

#define FOURCHARS_TO_INT(c1,c2,c3,c4) \
                    (((unsigned long) c1 << 24) | \
                     ((unsigned long) c2 << 16) | \
                     ((unsigned long) c3 << 8 ) | \
                     ((unsigned long) c4      ))

I have additional question. Is this more correct or still valid if I replace
line 1756:
  fprintf(file, "%.8x%.8x\n", h, l);
with line:
  fprintf(file, "%.8lx%.8lx\n", h, l);
?

ABX

Post a reply to this message

In article <5jsfpuofbifqlq9avonj4mejd3f7siihe0@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> It helped to add definition:
>
> #define FOURCHARS_TO_INT(c1,c2,c3,c4) \
>                     (((unsigned long) c1 << 24) | \
>                      ((unsigned long) c2 << 16) | \
>                      ((unsigned long) c3 << 8 ) | \
>                      ((unsigned long) c4      ))

No, this is incorrect!  All it does is trick the compiler in shutting up
with its nonsense messages while changing absolutely nothing for the broken
compiler, but potentially *breaking* the code on compilers which handle
multibyte character constants correctly!!!

The correct solution is to simply turn off the particular warning.

    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

On Mon, 30 Sep 2002 11:44:39 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> but potentially *breaking* the code on compilers which handle
> multibyte character constants correctly!!!

how ?

ABX

Post a reply to this message

On Mon, 30 Sep 2002 08:58:48 +0200, ABX <abx### [at] abxartpl> wrote:
> I have additional question. Is this more correct or still valid if I replace
> line 1756:
>   fprintf(file, "%.8x%.8x\n", h, l);
> with line:
>   fprintf(file, "%.8lx%.8lx\n", h, l);
> ?

I mean in povms.cpp :-)

ABX

Post a reply to this message

In article <rs7gpukm3087jh97t57rg628i23c4mk01h@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

>> line 1756:
>>   fprintf(file, "%.8x%.8x\n", h, l);
>> with line:
>>   fprintf(file, "%.8lx%.8lx\n", h, l);
>> ?
>
> I mean in povms.cpp :-)

Line numbers don't help me much (they change...).  I need the function name
:-)


    Thorstem


____________________________________________________
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

On Mon, 30 Sep 2002 13:11:20 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> Line numbers don't help me much (they change...).  I need the function name
> :-)

There is only one occurance of it in that file - it is case kPOVMSType_Long in
POVMSObject_DumpAttr function.

ABX

Post a reply to this message

In article <on7gpug752bj3v9f0v3po33uha7a3s487r@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

>> but potentially *breaking* the code on compilers which handle
>> multibyte character constants correctly!!!
>
> how ?

If you mix a programmer defined implementation with an implementation
defined implementation.  The following, while perfectly legal code may
break:

    unsigned long prog = FOURCHARS_TO_INT('A','B','C','D');

    if(prog == 'ABCD')
        puts("equal");
    else
        puts("not equal");

This is perfectly legal and will not break:

     unsigned long prog = 'ABCD';

    if(prog == 'ABCD')
        puts("equal");
    else
        puts("not equal");

Essentially the problem is that what you do actually creates a problem if
the implementation defined implementation differs from the programmer
defined implementation of multicharacter constants.  This may very well
happen depending i.e. on byteorder, but also on many other things.

Multicharacter constants are great if used consistently, but not if one
messes around with them like your macro does.  Some compilers think they
have to always warn you because you _might_ use it incorrectly.

POV-Ray uses it correctly and will work as it should because it never makes
any assumption like the actual representation of the multicharacter
constants, which your macro does.  It only compares multicharacter constants
with other multicharacter constants, which works without any limitations
whatsoever and is perfectly legal and clean code.  Except some compilers
with broken default warning settings warn about it, of course :-(


    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

On Mon, 30 Sep 2002 13:23:17 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> If you mix a programmer defined implementation with an implementation
> defined implementation.

I think I see the difference better now. I still wonder it is correct to use
implementation dependand features. Would you like to unroll some statement
about it ? I understnad it is necessary to make some assumptions about
compiler but gcc is very portable nowadays and povray I think is supposed to
be "gcc-compatible". For example I considered recently to buy some
palm/handheld with port of gcc to play with povray sources on the village
where I have no computer and waste time at evenings. But there is a risk I
could not use it becouse some modern assumptions were done to the sources. I
decided to buy old used Pentium 75 MHz for such portable compilation machine.
But I still affraid that future development would get me off becouse of
requiements. Right now Pentium 75 is enough for DJGPP with GCC 3.1 and some
MP3 in background. That's just fears, not criticism.

ABX

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> No, this is incorrect!  All it does is trick the compiler in shutting up
> with its nonsense messages while changing absolutely nothing for the broken
> compiler

  You are starting to be quite irritating.
  If you say that "broken compiler" thing once or twice, then it's an opinion,
but when you start to repeat over and over, it starts to be an obsession.
An irritating obsession.

  Just imagine that someone would start to post messages about povray warning
about the camera being inside a non-hollow object in perfectly legal scenes
over and over, and calling povray "broken" and similar derogatory names. That
would certainly irritate many people.

  One thing is to whine about a warning you think is irrelevant, and another
totally different thing is to say that the program is broken because of this
irrelevant warning. It's a kind of insult.

  So would you stop, please?

-- 
#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 <vgcgpu8b7p6a4fcaqabl82gf6hfai8lu0s@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

>> Line numbers don't help me much (they change...).  I need the function name
>> :-)
>
> There is only one occurance of it in that file - it is case kPOVMSType_Long in
> POVMSObject_DumpAttr function.

Nope, but change the type of h and l to int and unsigned int respectively.

    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

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

>   Just imagine that someone would start to post messages about povray warning
> about the camera being inside a non-hollow object in perfectly legal scenes
> over and over, and calling povray "broken" and similar derogatory names. That
> would certainly irritate many people.

IIRC, this is a known bug:  <http://www.povray.org/download/3.5-bugs.php>

So in this regard POV-Ray is "broken".  Not seriously "broken", of course.

    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

In article <dbdgpu4mk28f04fs4g645r9mpgf49seddc@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> I still wonder it is correct to use
> implementation dependand features.

Well, unless you don't want to use any POD types you will have to.  As you
know, the precision of ints, floats, doubles, or even if chars are signed or
unsigned by default is implementation defined as well.  Just like many other
things.  Otherwise C/C++ would not be such powerful languages and we would
still be writing device drivers in assembler - not that that would always be
a bad thing, but still ;-)

    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 in message:
> If you mix a programmer defined implementation with an implementation
> defined implementation.

Could you please tell us why do you have to mix? It seems to be somewhat
unfair to compare your code to the code with *artificial* flaws... Why
cannot you just write

    unsigned long prog = FOURCHARS_TO_INT('A','B','C','D');

    if(prog == FOURCHARS_TO_INT('A','B','C','D'))
        puts("equal");
    else
        puts("not equal");

and get rid of unnecessary wornings? That would certainly be a better
quality code.

Post a reply to this message

In article <3d997467$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> Could you please tell us why do you have to mix? It seems to be somewhat
> unfair to compare your code to the code with *artificial* flaws... Why
> cannot you just write

Because there is no need.  With the original code there is nothing wrong,
and in real code, not the trivial example i give, nobody could tell why it
would not work.  Adding traps for programmers in legal and well working code
just to silence a compiler warning in some broken compilers is not exactly a
good solution...

    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

In article <3d997467$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

>     unsigned long prog = FOURCHARS_TO_INT('A','B','C','D');
>
>     if(prog == FOURCHARS_TO_INT('A','B','C','D'))
>         puts("equal");
>     else
>         puts("not equal");
>
> and get rid of unnecessary wornings? That would certainly be a better
> quality code.

By the time when cluttering code with unnecessary macros is considered
better code, I am going to jump out of the window!

    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:
> 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

Warp <war### [at] tagpovrayorg> wrote in news:3d9a4b7e@news.povray.org:

> ABX <abx### [at] abxartpl> wrote:
>   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.

I agree. A simple case is the line:
  if (a = b)
It is perfectly legal in C, but at some warning level, the compiler howls...

And I agree with it. I may wanted to check if b is non-null, but most of the 
case, I just failed to type two equal signs.

If I want to do:
  if (f = Foo())
to check if Foo is not returning an error status, I should instead write:
  if ((f = Foo()) != 0)
which is uglier, but less prone to errors or ambiguity.

I know that some coders prefer to write:
  if (Foo() == f)
because if they forget an equal, an error will be thrown. But I don't like 
much this form, habits, you know?

BTW, I write now:
  f = Foo();
  if (f != 0)
which is more elegant, easier to read, and probably as efficient.
Some may object it wastes space (see the hot discussion about soft braces 
placement...) but I now prefer a nice layout to a compact one.
There was a time were I admired C's compactness (coming from Basic and 
Pascal worlds), but experience changed that :-)

BTW, removing warnings is not a futile task.
Lua programmers take careful steps to maintain strict ANSI C compliance, so 
their code is very portable. Sometime, when compiling with VC++, I get some 
warnings. Most of the time, they correct the code (mostly to add some 
explicit casts).
It allows:
- to insure no ambiguity (because of default rules) remains;
- to avoid inundating the poor programmer with a lot of harmless warnings, 
letting him miss the important ones...

Last note: you can't please everyone, including compilers.
Lua has the following function:
  static int io_exit (lua_State *L) {
    exit(luaL_opt_int(L, 1, EXIT_SUCCESS));
    return 0;  /* to avoid warnings */
  }
Well, VC++ issues a warning on the return line:
D:\Programmes\Langages\Lua\src\lib\liolib.c(565) : warning C4702: 
unreachable code
Both are right, of course. :-)
Note: the function must return an int because it is the signature of all Lua 
functions (called by the interpreter).

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

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

>   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.

Well, if you don't read carefully you will of course continue to miss that I
am complaining about the default warnings.  Not about being able to enable
other warnings.  In fact, I made this clear early in this thread.

It is hard to argue if you either intentionally misunderstand what I say or
simply intentionally forget 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

In article <Xns### [at] 204213191226> , Philippe Lhoste 
<Phi### [at] GMXnet>  wrote:

> Warp <war### [at] tagpovrayorg> wrote in news:3d9a4b7e@news.povray.org:
>
>>   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.
>
> I agree.

Well, Warp intentionally misrepresented what I said in order to argue about
something else just for the sake of argument.  I never disagreed on the
point he makes, in fact I made very clear:

In article <3d8ed609$1@news.povray.org> , "Thorsten Froehlich"
<tho### [at] trfde> wrote:
> Of course, setting the maximum warning level changes this rule (it should
> then warn about everything it can detect), but such a thing does not belong
> into the default warning set, but the all warning set (gcc and VC warn by
> default about this incorrectly).


    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

In article <Xns### [at] 204213191226>,
 Philippe Lhoste <Phi### [at] GMXnet> wrote:

> I agree. A simple case is the line:
>   if (a = b)
> It is perfectly legal in C, but at some warning level, the compiler howls...
> 
> And I agree with it. I may wanted to check if b is non-null, but most of the 
> case, I just failed to type two equal signs.

And I usually avoid this kind of code. Sapphire doesn't allow it, and I 
probably won't add it.


> If I want to do:
>   if (f = Foo())
> to check if Foo is not returning an error status, I should instead write:
>   if ((f = Foo()) != 0)
> which is uglier, but less prone to errors or ambiguity.

I'm just too lazy to keep typing " != 0" or " != NULL"...it hasn't 
caused me trouble yet, but for reading I'd prefer it because of its 
unambiguity.


> I know that some coders prefer to write:
>   if (Foo() == f)
> because if they forget an equal, an error will be thrown. But I don't like 
> much this form, habits, you know?

Besides, it doesn't always work in C++...a function can return a 
reference.

myCam.Location() = blah;

is perfectly valid code. Not a good design in most cases, but valid.


> BTW, I write now:
>   f = Foo();
>   if (f != 0)
> which is more elegant, easier to read, and probably as efficient.
> Some may object it wastes space (see the hot discussion about soft braces 
> placement...) but I now prefer a nice layout to a compact one.

If f is used later, then yes. Otherwise the larger amount of code 
outweighs the clearer wording, in my opinion. "if(Foo() != 0)" or 
"if(Foo())" are clearer.


> There was a time were I admired C's compactness (coming from Basic and 
> Pascal worlds), but experience changed that :-)

Well...being excessively verbose is bad too. For example, I much prefer 
"{}" braces to a "begin...end" style, it is easier to recognize the 
symbols when mixed in with lots of other words and nicely short to type, 
but languages like Python which use white space to define blocks of code 
drive me nuts.
And I doubt anyone would prefer "add", "multiply", etc for 
operators...think of how huge simple expressions would get. However, I 
do prefer "and" and "or" to "&&" and "||". And I've never used the "?:" 
operator.

-- 
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

Christopher James Huff <chr### [at] maccom> wrote:
> myCam.Location() = blah;

> is perfectly valid code. Not a good design in most cases, but valid.

  Yes.
  The problem with that is that returning a non-const reference to a
member variable (which is of course private; if you see a member variable
anywhere else than in the private part, then dump that code, it's crap)
is against good OO coding practices, as it pretty much nullifies the whole
purpose of keeping it in the private part of the class.

  Reading and writing to that variable should be done eg. like this:

var = myCam.Location();

myCam.Location(newLocation);

  (The reason for this is left as homework... :) )

> And I've never used the "?:" operator.

  Why not? It's handy. :)

-- 
#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

"Philippe Lhoste" <Phi### [at] GMXnet> wrote:
> If I want to do:
>   if (f = Foo())
> to check if Foo is not returning an error status, I should instead write:
>   if ((f = Foo()) != 0)
> which is uglier, but less prone to errors or ambiguity.
>
> I know that some coders prefer to write:
>   if (Foo() == f)
> because if they forget an equal, an error will be thrown. But I don't like
> much this form, habits, you know?
>
> BTW, I write now:
>   f = Foo();
>   if (f != 0)
> which is more elegant, easier to read, and probably as efficient.

Yes, it is generally as efficient. And clear. I tend to use this form most
of the time as well...

BTW, there's one more way to express that same thing and not to cause any
warning messages:

if((f=Foo()))

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
>>   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.

> Well, if you don't read carefully you will of course continue to miss that I
> am complaining about the default warnings.  Not about being able to enable
> other warnings.  In fact, I made this clear early in this thread.

  Ok, I can admit this misunderstanding. However, it would be easier if
it was the *only* thing that you claimed. What I don't like is that you
call the compiler "broken" just because it has a default warning set which
you think should not be default, but behind a higher warning level option.

-- 
#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

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

>   The problem with that is that returning a non-const reference to a
> member variable (which is of course private; if you see a member variable
> anywhere else than in the private part, then dump that code, it's crap)

Well, it is useful, but rarely. The only time I've ever used public 
variables is for the components in a 3D vector type, and a color type. 
My reasons: they are the only members, and are never going to change, 
and it makes code using these vectors a lot shorter and clearer. Speed 
isn't a factor, I expect any decent compiler to optimize the function 
calls away.
I do use "struct" instead of "class" to differentiate these...there is 
no real difference to the compiler other than default access level, but 
you will never see a class from me with a public variable. (unless it is 
something left over from debugging or some coding mistake)

Off the topic of this discussion, but another thing I've occasionally 
wished for was a way to specify specific methods as being exposed to 
objects of a class...friend classes are close, but are all-or-nothing. 
Sometimes there are two closely related classes that need to talk to 
each other, but the API between them doesn't need to be public and they 
don't need private access to each other. Maybe a way to group 
methods/data members into categories that can be exposed to specific 
classes. (category is a bad term, it is already used for something else 
in many OO languages and doesn't apply to C++, but I can't think of 
anything better)


> is against good OO coding practices, as it pretty much nullifies the whole
> purpose of keeping it in the private part of the class.
>   Reading and writing to that variable should be done eg. like this:

Exactly.


> > And I've never used the "?:" operator.
>   Why not? It's handy. :)

Never needed it. Expressions using it are much less readable IMO, and 
I've never had a situation where using if...else was significantly 
longer or more awkward.

-- 
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

Christopher James Huff <chr### [at] maccom> wrote in news:chrishuff-
A44### [at] netplexaussieorg:

> In article <3d9c22b8@news.povray.org>, Warp <war### [at] tagpovrayorg> 
> wrote:
> 
>> > And I've never used the "?:" operator.
>>   Why not? It's handy. :)
> 
> Never needed it. Expressions using it are much less readable IMO, and 
> I've never had a situation where using if...else was significantly 
> longer or more awkward.

printf("There is %d object%s\n", objNb, objNb > 1 ? "s" : "");

Alternatives: use two printf (may be better if you need to localize it, some 
languages may not use the same plural rules) or an intermediate variable.
I don't like much the "object(s)" syntax when I can avoid it. Even less the 
"1 objects" form...

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

"Philippe Lhoste" <Phi### [at] GMXnet> wrote:
>
> printf("There is %d object%s\n", objNb, objNb > 1 ? "s" : "");
>
> Alternatives: use two printf (may be better if you need to localize it,
some
> languages may not use the same plural rules) or an intermediate variable.
> I don't like much the "object(s)" syntax when I can avoid it. Even less
the
> "1 objects" form...

"Have no fear of perfection: you'll never reach it!" :-)

IMHO in this particular case two printf()s would be better than the
altogether correct

printf("There %s %d object%s\n", objNb > 1 ? "are" : "is", objNb, objNb > 1
? "s" : "");

BTW, can't there be no objects at all? ;-)

Follow-ups to povray.off-topic.

Post a reply to this message