 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
The 3.5 version for Windows couldn't be compiled by VC.NET. Is there a plan
on supporting it? The changes are not so many. I tried it with the
following changes.
1. "iosteam.h" is end of lifed in VC .NET. So need to change it to "iosteam"
in file "ztimer.h"
2. all other changes are related to compile-time errors from math functions.
VC.NET is more restrict on syntax, so it issues errors for pow(2,2). It
should be pow((double)2,2). pow() is one of the math functions, there're
also sqrt(),fabs...
Thanks very much,
Jennifer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.3ffc64d3e05b701c9fd50ea0@news.povray.org> , "JenniferJ"
<nomail@nomail> wrote:
> The 3.5 version for Windows couldn't be compiled by VC.NET. Is there a plan
> on supporting it?
No, POV-Ray will forever use an outdated compiler on Windows. Also, you
should have mentioned that you are talking about Visual C 7.1, because that
is the compiler/library combination with problems, not VC 7.0.
> 2. all other changes are related to compile-time errors from math functions.
> VC.NET is more restrict on syntax, so it issues errors for pow(2,2). It
> should be pow((double)2,2). pow() is one of the math functions, there're
> also sqrt(),fabs...
This is not as trivial as this. And putting a cast in front of a constant
is just the plain wrong way of solving this. In fact, if used without care,
casts will create unnecessary performance bottlenecks. Blindly doing
whatever is necessary to please a broken compiler/library combination is no
good idea!
The problem is that in VC 7.1 many bugs and most of VCs non-standard
behavior was corrected compared to early versions of VC. However, the C
libraries that come with VC 7.1 are still pretty much the same junk that
already came with VC 6.0. So, now you have a conforming compiler and non
standard conforming libraries, which results in compilation problems in
standard conforming code...
Good compilers like Intel's, if provided with a conforming C library will
not exhibit any problem. Nor will any other serious compiler around.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 08 Jan 2004 10:49:38 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> Nor will any other serious compiler around.
I was always curious Thorsten. Can you enumerate serious compilers you know?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 7 Jan 2004 14:58:11 EST, "JenniferJ" <nomail@nomail> wrote:
> 1. "iosteam.h" is end of lifed in VC .NET. So need to change it to "iosteam"
> in file "ztimer.h"
AFAIK this is already fixed for next release.
> pow((double)2,2)
I do not see such requirement at
http://msdn.microsoft.com/library/en-us/vcstdlib/html/vclrf_valarray_pow.asp
And IIRC for next releases majority of float numbers where replaced with
equivalent with comma for this purposes where required.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
JenniferJ <nomail@nomail> wrote:
> pow((double)2,2)
Whether or not you should "need" to do that, that's the cumbersome way
of doing it.
If you want a double-type constant, then write a double-type constant.
It makes no sense to write an int-type constant and cast it to double.
That is: pow(2.0, 2)
--
#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 <j5fqvvk0mds1rguo2f5njsmb9eb83s21ev@4ax.com> , ABX
<abx### [at] abxartpl> wrote:
>> Nor will any other serious compiler around.
>
> I was always curious Thorsten. Can you enumerate serious compilers you know?
Almost any C++ compiler based on a recent version of the EDG frontend on any
platform, as well as vendor specific compilers for specific architectures.
Thus, compilers from Intel, IBM, Motorola and so on can be considered
"serious" because they are made by people who have access to information
they really need, and they do have that information early on and usually
even have significant influence when it comes to planning a new processor
implementation.
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
|
|
| |
| |
|
|
|
|
| |
|
|
