"Thorsten Froehlich" <tho### [at] trfde> wrote:
>
> Which compiler do you use?

On one of my machines, there is Visual Studio 6.0; on the other machine --
Visual Studio .NET. So that's Visual C++. I'm using /W2 for retail, and /W3
for debug builds, and consider that rather practical (to me, the default /W1
is way too forgiving to be used in the compilation of really large sources).
This is the compiler with which I'm doing now all that work I mentioned.

As an aside:

Long ago, I was using Intel's Proton, after it was given to me at one of
their seminars, as a part of Intel's "early access program". This one was
used in the making of POVPro.

All my attempts to compile 3.0 with Symantec C/C++ 7.2 have failed (it used
to go mad on lighting.c), and I never tried it since then.

GCC did not deliver particularly good results, although I did manage to
build 3.1 (I believe...) with it. Never used it heavily with POV-Ray.

Post a reply to this message

"Ken" <tyl### [at] pacbellnet> wrote:

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

Not quite so... Although, yes, my setup is not completely standard: I'm
using Visual C++ with /W2 for retail, and /W3 for debug compiles. To me,
what the compiler complains about in these modes does make sense; in fact,
it is VERY easy to write code that does not generate warnings under
/W2/W3...

Post a reply to this message

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

> "Ken" <tyl### [at] pacbellnet> wrote:
> 
> Not quite so... Although, yes, my setup is not completely standard: I'm
> using Visual C++ with /W2 for retail, and /W3 for debug compiles. To me,
> what the compiler complains about in these modes does make sense; in fact,
> it is VERY easy to write code that does not generate warnings under
> /W2/W3...

I took the habit of using /W4 for most projects, both debug and release 
compilations, except for external libraries which trigger too much 
warnings...
One you get used to it, it isn't so bad. :-)

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

Post a reply to this message

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

> Not quite so... Although, yes, my setup is not completely standard: I'm
> using Visual C++ with /W2 for retail, and /W3 for debug compiles. To me,
> what the compiler complains about in these modes does make sense; in fact,
> it is VERY easy to write code that does not generate warnings under
> /W2/W3...

Ah, because all compilers are as defective as Visual C?  Ah, no, sorry, I
forgot, Visual C is the only true compiler around, and if it is broken, all
other compilers must be broken as well.  Sure!

In VC 6 as well as VC 7 you can turn off individual warning messages, just
by either putting them on the command line (as /wNNNN iirc, with NNNN being
the warning number) or by adding a #pragma warning directive (for POV-Ray in
config.h).

In fact, it seems the default set of warnings in Visual C is so useful that
even Microsoft's OS division needs to turn the most annoying and wrong ones
off (see below).  Kind of supports my point if M$ needs to disable the
useless warnings one of their own defective products generates, don't you
think? ;-)


    Thorsten


Beginning of "windows.h":

#ifndef RC_INVOKED
#if     ( _MSC_VER >= 800 )
#pragma warning(disable:4514)
#ifndef __WINDOWS_DONT_DISABLE_PRAGMA_PACK_WARNING__
#pragma warning(disable:4103)
#endif
#if _MSC_VER >= 1200
#pragma warning(push)
#endif
#pragma warning(disable:4001)
#pragma warning(disable:4201)
#pragma warning(disable:4214)
#endif
#include <excpt.h>
#include <stdarg.h>
#endif /* RC_INVOKED */

End of "windows.h":

#pragma warning(default:4001)
#pragma warning(default:4201)
#pragma warning(default:4214)
/* Leave 4514 disabled.  It's an unneeded warning anyway. */

____________________________________________________
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:
> In fact it can be found in
> all versions of the gcc online documentation.

It is not that I couldn't find it. That's obvious where I can find such
suggestions. I'm developing my patches at home where I'm offline. But I
have basic info with DJGPP so I quickly turned off this warning with
appropriate option. Couldn't find more at home - my only connection with
world is 1,44 MB on piece of something. But before posting I offcourse
checked online resources and found probably all mentioned sites. But I
asked if it is possible to remove this just for convenience, to increase my
own knowledge and to increase portability (if possible and reachable).
Asking not hurts. Asking is better than sending wishlists IMO.

> So it is really not difficult to turn it off and no longer have any
> problems.

Nobody said it is difficult.

> And indeed, if it is that easy to turn off, I do not understand
> their problem with it.

You don't have to. I have no problem :-)

ABX

Post a reply to this message

Thorsten Froehlich wrote:
> Well, why should I fix something that is not broken when there is a list of
> things that are broken.

Having more opened development model somebody could work on broken things
and somebody less experienced could just fix warnings...

ABX

Post a reply to this message

On Thu, 03 Oct 2002 13:33:47 -0400, Włodzimierz ABX Skiba quoth:

> Thorsten Froehlich wrote:
>> Well, why should I fix something that is not broken when there is a
>> list of things that are broken.
> 
> Having more opened development model somebody could work on broken
> things and somebody less experienced could just fix warnings...

...and we get more disasters like the original version of the spline{}
code.

-- 
Mark

Post a reply to this message

Thorsten Froehlich wrote:
> So can we end this endless and useless complaining now and get back to
> fixing real problems...?

http://www.ifrance.com/antre-des-vampires/thor.JPG

--
Rick

Kitty5 NewMedia http://Kitty5.co.uk
POV-Ray News & Resources http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA



---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.393 / Virus Database: 223 - Release Date: 30/09/2002

Post a reply to this message

In article <3d9d8353$1@news.povray.org> , "Rick [Kitty5]" <ric### [at] kitty5com>
wrote:

> http://www.ifrance.com/antre-des-vampires/thor.JPG

Of course, guess why my parents gave me this name ;-)

    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 Wed, 2 Oct 2002 19:19:05 +0400, Vadim Sytnikov wrote:
> All my attempts to compile 3.0 with Symantec C/C++ 7.2 have failed (it used
> to go mad on lighting.c), and I never tried it since then.

VC++ 5 had a problem with lighting.c as well, fixed in a service pack.  It
was related to a specific optimization.  I wouldn't be surprised if you found
the same problem with Symantec C.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message