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

> The real (yes, real) problem is the number of warnings 3.5 generates.

It simply depends on the compiler and settings you use.

    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 wrote:
> 
> [...]
> 
> I do not care for the tons of hypothetical or impractical or already known
> to be wrong examples given in the whole thread of discussion.

I have no way enough knowledge about the matters discussed here to form a
justified opinion, but in the end it really does not matter much who is
right and who not about these specific questions.

What i have been missing in your posts of this thread is a statement of
understanding to those who compile POV-Ray with gcc every day and
therefore have problems with all those warnings without any conncetion to
the reason of the warning in the first place.  To me it seems that both
ABX and Vadim respect your opinion on the matter of the warnings and their
reasons but your arguments would probably be much better received if you
better show your understanding of someone's motives for working and making
thoughts on that matter.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3D99CB0F.5DE476A8@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> What i have been missing in your posts of this thread is a statement of
> understanding to those who compile POV-Ray with gcc every day and
> therefore have problems with all those warnings without any conncetion to
> the reason of the warning in the first place.  To me it seems that both
> ABX and Vadim respect your opinion on the matter of the warnings and their
> reasons but your arguments would probably be much better received if you
> better show your understanding of someone's motives for working and making
> thoughts on that matter.

Well, reading the documentation of gcc suggests to use "-Wno-multichar" as a
command line option to turn those warnings off.  In fact it can be found in
all versions of the gcc online documentation at

<http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC8>
<http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html#SEC11>
<http://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/Warning-Options.html#Warning%20
Options>
<http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Warning-Options.html#Warning%20Op
tions>

Really trivial, if you ask me.  I could find it within seconds at the place
I would expect it (warning command line options) yet I really do not use gcc
frequently at all.

It is also trivial to find in google, which returns currect help for this
problem at least behind every link of the first three result pages!

<http://www.google.com/search?q=multicharacter+constant+gcc+warning>

So it is really not difficult to turn it off and no longer have any
problems.  And indeed, if it is that easy to turn off, I do not understand
their problem 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

"Vadim Sytnikov" <syt### [at] rucom> wrote in news:3d99b4fb@news.povray.org

> The real (yes, real) problem is the number of warnings 3.5 generates. 

-w 

:) ?

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

Vadim Sytnikov <syt### [at] rucom> wrote:
> The real (yes, real) problem is the number of warnings 3.5 generates.

  I have to go to Thorsten's side in this: I don't really see how
this is a "real problem".
  As far as I know, none of the warnings is about code which is buggy
and does not work as expected. Of course this doesn't mean that most
of the warnings could not be handled (eg. by making double -> int
conversions explicit), and IMHO it would be good if this was done
(to make the code cleaner) but those are just minor details, not major
problems, as you are implying.

  The only problem I personally have with them is that the warnings
flood my terminal when I'm compiling POV-Ray. Not a major problem.

-- 
#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:
>   I have to go to Thorsten's side in this: I don't really see how
> this is a "real problem".

This is how: I have a lot of my own modifications, and am constantly working
on new ones. For you to understand the degree of those modifications, I
would list some of them here:
- it is a Win32 console executable (running with detached console, i.e. w/o
standard Win32 character console),
- output to hi-color (16-bit) DirectDraw full-screen window,
- own custom console *within* that window,
- own means of synchronization with other Win32 applications (set of Events,
plus a memory-mapped file),
- numerous own patches (representing major modifications to POV-Ray; like,
say, building density maps),
- etc.

Once again, I'm constantly working on that, making my own (sic!) errors in
the process. Common sense (as well as many years of experience) suggests
that I do not turn off warnings, since absolute majority of them are indeed
very helpful in spotting bugs. Just as I said on a number of accations,
compiler writers are not idiots.

And now I have to use Tcl/Tk scripts for my build procedure to sort out
warnings. Tell me, is that OK?

Post a reply to this message

Vadim Sytnikov wrote:
> 
> "Warp" <war### [at] tagpovrayorg> wrote:
> >   I have to go to Thorsten's side in this: I don't really see how
> > this is a "real problem".
> 
> This is how: I have a lot of my own modifications, and am constantly working
> on new ones. For you to understand the degree of those modifications, I
> would list some of them here:
> - it is a Win32 console executable (running with detached console, i.e. w/o
> standard Win32 character console),
> - output to hi-color (16-bit) DirectDraw full-screen window,
> - own custom console *within* that window,
> - own means of synchronization with other Win32 applications (set of Events,
> plus a memory-mapped file),
> - numerous own patches (representing major modifications to POV-Ray; like,
> say, building density maps),
> - etc.
> 
> Once again, I'm constantly working on that, making my own (sic!) errors in
> the process. Common sense (as well as many years of experience) suggests
> that I do not turn off warnings, since absolute majority of them are indeed
> very helpful in spotting bugs. Just as I said on a number of accations,
> compiler writers are not idiots.
> 
> And now I have to use Tcl/Tk scripts for my build procedure to sort out
> warnings. Tell me, is that OK?

One could argue that if you are doing such serious work with the POV-Ray source
code then it might benefit you to use the same development tools that the
POV-Ray developers use, thereby avoiding any potential warning messages from the
original code base. The POV-Ray developers cannot in anycase be expected to
aniticipate how the source code will behave on compilers that they themselves
do not use and expecting them to is unrealistic.

-- 
Ken Tyler

Post a reply to this message

In article <3D9ADF96.2E332020@pacbell.net> , Ken <tyl### [at] pacbellnet>  
wrote:

>> And now I have to use Tcl/Tk scripts for my build procedure to sort out
>> warnings. Tell me, is that OK?
>
> One could argue that if you are doing such serious work with the POV-Ray
> source code then it might benefit you to use the same development tools that
> the POV-Ray developers use, thereby avoiding any potential warning messages
> from the original code base. The POV-Ray developers cannot in anycase be
> expected to aniticipate how the source code will behave on compilers that they
> themselves do not use and expecting them to is unrealistic.

Very true.  On all compilers used and supported by the POV-Team the warnings
can be controlled on a warning type by warning type basis.  Plus all four
compilers supported by the POV-Team are the most popular compilers on their
particular platform.

    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 <3d9acd67@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> And now I have to use Tcl/Tk scripts for my build procedure to sort out
> warnings. Tell me, is that OK?

Which compiler do you use?


    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

Vadim Sytnikov <syt### [at] rucom> wrote:
> And now I have to use Tcl/Tk scripts for my build procedure to sort out
> warnings. Tell me, is that OK?

  Why don't you just turn off *certain* warnings instead of turning them all
off?

  But yes, I agree that at least the implicit conversions from double to
int should be changed to explicit. This is a good coding habit (it kind of
"comments" the code in such a way that a person reading it will see that
"yes, this conversion is deliberate, not a mistake/overlook").
  Letting the conversions be implicit is bad not only because of the
warnings, but because it makes it more unclear whether a certain implicit
conversion is the desired thing or a mistake.
  Sometimes an implicit conversion from a bigger type to a smaller one
(where information is lost) is indeed a mistake from the part of the coder
and may cause a bug.

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