 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
HI all,
well, that's the time where I hate my fucking new system :(sorry:)
But it is as it is. I can't just unzip configur and compile the sources
because of some basic C++ standard issues. such as max and std::max. gcc
has been very loosely to the ANSI/ISO C++ standard in gcc 2.x. Most of
these issues has been fixed now and, what's now? lots of sources (such as
povray) can't be compiled.
That's now good :(
Will the developer fix that? or do we need to walk through the code and add
the namespace prefix (std::) to each standard function? This wouldn't be
nice since I'm pretty sure that I'm not the only one who should do exactly
the same as the others in that case.
Thanks,
Christian Parpart.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 02 Aug 2002 01:59:28 +0200, Christian Parpart wrote:
> HI all,
>
> well, that's the time where I hate my fucking new system :(sorry:)
No need to be sorry just don't swear it's that simple.
> Will the developer fix that? or do we need to walk through the code and add
> the namespace prefix (std::) to each standard function? This wouldn't be
> nice since I'm pretty sure that I'm not the only one who should do exactly
> the same as the others in that case.
Have a look around in some other groups that you think may contain the
answer to your question, it so happens that your question was answered
some hours ago in povray.unix.
--
%HAV-A-NICEDAY email mailto:ste### [at] zeropps uklinuxnet
Steve web http://www.zeropps.uklinux.net/
or http://start.at/zero-pps
1:35am up 35 days, 11:57, 1 user, load average: 1.29, 1.24, 1.21
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Quick fix: Add 'using namespace std;' to config.h
(Ugly perhaps, but who cares? At least it compiles.)
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Quick fix: Add 'using namespace std;' to config.h
> (Ugly perhaps, but who cares? At least it compiles.)
I have no problem with it, but I do remember you going on about how it isn't
something you should grow accustomed to doing. I'm surprised you're the one
suggesting it. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp inspired the electrons to say:
> Quick fix: Add 'using namespace std;' to config.h
> (Ugly perhaps, but who cares? At least it compiles.)
Exactly. That's what I did. Quick'n'dirty.
And, as we was talking in povray.unix group about too (unfortunately).
Greets,
christian.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Parpart wrote:
> HI all,
>
> well, that's the time where I hate my fucking new system :(sorry:)
> But it is as it is. I can't just unzip configur and compile the sources
> because of some basic C++ standard issues. such as max and std::max. gcc
> has been very loosely to the ANSI/ISO C++ standard in gcc 2.x. Most of
> these issues has been fixed now and, what's now? lots of sources (such as
> povray) can't be compiled.
>
> That's now good :(
>
> Will the developer fix that? or do we need to walk through the code and add
> the namespace prefix (std::) to each standard function? This wouldn't be
> nice since I'm pretty sure that I'm not the only one who should do exactly
> the same as the others in that case.
>
> Thanks,
> Christian Parpart.
Christian,
This simple thing works until that issue is fixed.
Put these lines in config.h:
#ifndef max
#define max(a,b) ( a > b ? a : b )
#endif
#ifndef min
#define min(a,b) ( a < b ? a : b )
#endif
This is easier than searching & prefacing all max
and min calls with std:: , eh? ;-)
Bob Jamison
LinCom Corp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob Jamison <rja### [at] lincom-asgcom> wrote:
> #ifndef max
> #define max(a,b) ( a > b ? a : b )
> #endif
> #ifndef min
> #define min(a,b) ( a < b ? a : b )
> #endif
> This is easier than searching & prefacing all max
> and min calls with std:: , eh? ;-)
How is it easier than writing 'using namespace std;' instead?
Besides, your solution is very bad. Do you know why?
--
#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 2 Aug 2002 20:34:28 -0400, Warp wrote:
> Bob Jamison <rja### [at] lincom-asgcom> wrote:
>> #ifndef max
>> #define max(a,b) ( a > b ? a : b )
>> #endif
>> #ifndef min
>> #define min(a,b) ( a < b ? a : b )
>> #endif
>
>> This is easier than searching & prefacing all max
>> and min calls with std:: , eh? ;-)
>
> How is it easier than writing 'using namespace std;' instead?
>
> Besides, your solution is very bad. Do you know why?
Oooh! Oooh! I know! I know!
--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
> Oooh! Oooh! I know! I know!
But you are a professional. You can't participate. ;)
--
#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:3d4b2513@news.povray.org
>> #ifndef max
>> #define max(a,b) ( a > b ? a : b )
>> #endif
>> #ifndef min
>> #define min(a,b) ( a < b ? a : b )
>> #endif
>> This is easier than searching & prefacing all max
>> and min calls with std:: , eh? ;-)
> How is it easier than writing 'using namespace std;' instead?
> Besides, your solution is very bad. Do you know why?
<rot13>
fbzr rkcerfvbaf jvyy abg or pnyphyngrq ng pbzcvyr-gvzr ?
--
#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:
> fbzr rkcerfvbaf jvyy abg or pnyphyngrq ng pbzcvyr-gvzr ?
Eh... I don't think *any* min/max implementation will allow it to
perform them at compile-time, no matter how advanced... :)
No, that's not the 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2 Aug 2002 23:11:04 -0400, Warp wrote:
> Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
>> fbzr rkcerfvbaf jvyy abg or pnyphyngrq ng pbzcvyr-gvzr ?
>
> Eh... I don't think *any* min/max implementation will allow it to
> perform them at compile-time, no matter how advanced... :)
> No, that's not the problem.
Actually, there are two problems with that implementation. Which one
are you looking for, or will you give partial credit for either one?
--
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2 Aug 2002 22:11:13 -0400, Warp <war### [at] tagpovrayorg> wrote:
> But you are a professional. You can't participate. ;)
I know! I know! And I ain't no pro, buddy.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Bob Jamison <rja### [at] lincom-asgcom> wrote:
> > #ifndef max
> > #define max(a,b) ( a > b ? a : b )
> > #endif
> > #ifndef min
> > #define min(a,b) ( a < b ? a : b )
> > #endif
>
> > This is easier than searching & prefacing all max
> > and min calls with std:: , eh? ;-)
>
> How is it easier than writing 'using namespace std;' instead?
>
> Besides, your solution is very bad. Do you know why?
>
Well, i'm no expert in c, but i guess
max(++x, y)
would cause problems.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 15 Jul. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> Well, i'm no expert in c, but i guess
> max(++x, y)
> would cause problems.
Yes, that's the big problem.
Another minor problem is caused by the exact same reason: If you have
complicated statements as parameters to that "function", they will be
evaluated twice, thus producing inefficient code.
If you want to make the min() and max() functions in C++, the correct
way is to use templates. The result will be the same, but without the
mentioned problems (yes, compilers do a very good job when inlining this
type of functions and all temporary local variables will simply be gone).
template<typename T>
inline T max(const T& a, const T& b)
{
return a > b ? a : b;
}
(This is most probably how it's implemented in the STL, although there
*might* be some optimization as well...)
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote in
news:3D4B8CF7.90B5D011@gmx.de
> Well, i'm no expert in c, but i guess
> max(++x, y)
ofcourse :) but I wrong understand question, I thounght question was, why
sometimes #define is better then std::
with define something like
const int size_a = 100;
const int size_b = 500;
...
void fun() { int max_size = max(size_a,size_b); // <-- this will be changed
// to int max_size=500 at compile-time
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 03 Aug 2002 09:57:43 +0200, Christoph Hormann wrote:
>
>
> Warp wrote:
>>
>> Bob Jamison <rja### [at] lincom-asgcom> wrote:
>> > #ifndef max
>> > #define max(a,b) ( a > b ? a : b )
>> > #endif
>> > #ifndef min
>> > #define min(a,b) ( a < b ? a : b )
>> > #endif
>>
>> > This is easier than searching & prefacing all max
>> > and min calls with std:: , eh? ;-)
>>
>> How is it easier than writing 'using namespace std;' instead?
>>
>> Besides, your solution is very bad. Do you know why?
>>
>
> Well, i'm no expert in c, but i guess
>
> max(++x, y)
>
> would cause problems.
The other problem is precedence. If a or b are expressions, they'll be
substituted directly into the other expression above. Some expressions
might not take the substitution so well. For example, what if you did
max( c==d?c:d, b )
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
>
> The other problem is precedence. If a or b are expressions, they'll be
> substituted directly into the other expression above. Some expressions
> might not take the substitution so well. For example, what if you did
> max( c==d?c:d, b )
>
Which you can fix with brackets (which also fixes all other problems,
other than the efficiency issue (which'll more often than not get handled by
an optimising compiler anyway)).
--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Pandora <pan### [at] pandora-softwarecom> wrote:
> Which you can fix with brackets (which also fixes all other problems,
Wrong. It doesn't fix the max(i++, j++) problem.
> the efficiency issue (which'll more often than not get handled by
> an optimising compiler anyway)).
Wrong. For example if you call a function to get the value of the
parameter, eg. max(function1(), function2()), the compiler can't optimize
that double call away unless it can inline the function in question. If
it can't inline the function, it can't know if the function will return
a different value at the second call. If it takes a considerable amount of
time to execute these functions, time will be wasted in calling them twice.
(And if the function *does* return a different value when called again, the
whole max() macro will simply give the wrong result for the exact same reason
as the max(i++, j++) gives a wrong result.)
Using the template solution fixes all problems.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3d508498@news.povray.org...
> Pandora <pan### [at] pandora-softwarecom> wrote:
> > Which you can fix with brackets (which also fixes all other
problems,
>
> Wrong. It doesn't fix the max(i++, j++) problem.
>
Ah, yes, true. That slipped my mind, but can be solved in the same way
as the efficiency issue, see below :
> > the efficiency issue (which'll more often than not get handled by
> > an optimising compiler anyway)).
>
> Wrong. For example if you call a function to get the value of the
> parameter, eg. max(function1(), function2()), the compiler can't optimize
> that double call away unless it can inline the function in question.
Easily solved by doing :
a=function1();
b=function2();
c=max(a,b);
> (And if the function *does* return a different value when called again,
the
> whole max() macro will simply give the wrong result for the exact same
reason
> as the max(i++, j++) gives a wrong result.)
also fixed by doing it in three stages, as above.
> Using the template solution fixes all problems.
>
Only if you have a compiler that allows you to use templates.
--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d517fdb@news.povray.org>,
"Pandora" <pan### [at] pandora-softwarecom> wrote:
> > Wrong. For example if you call a function to get the value of the
> > parameter, eg. max(function1(), function2()), the compiler can't optimize
> > that double call away unless it can inline the function in question.
>
> Easily solved by doing :
>
> a=function1();
> b=function2();
> c=max(a,b);
So something that looks like a function can't be used like one. That is
not a solution, it is a workaround. Plus, it requires two temporary
variables and three lines of code instead of one simple line.
> > Using the template solution fixes all problems.
>
> Only if you have a compiler that allows you to use templates.
If you don't have one, get one.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3d517fdb@news.povray.org>,
> "Pandora" <pan### [at] pandora-softwarecom> wrote:
> >
> > a=function1();
> > b=function2();
> > c=max(a,b);
>
> So something that looks like a function can't be used like one.
It may look like a function, that don't mean it is a function.
> That is
> not a solution, it is a workaround.
Writing your own templated min/max functions could be seen as a
'workaround'...
> Plus, it requires two temporary
> variables and three lines of code instead of one simple line.
>
So ?
> If you don't have [a compiler that allows you to use templates], get one.
>
I knew someone would say that... (and, yes, I do have one, sort of
(VC6))...
--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Pandora <pan### [at] pandora-softwarecom> wrote:
> Writing your own templated min/max functions could be seen as a
> 'workaround'...
A workaround for what? If it works perfectly, with absolutely no
compromises, how is it a workaround?
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3d51a85c@news.povray.org...
> Pandora <pan### [at] pandora-softwarecom> wrote:
> > Writing your own templated min/max functions could be seen as a
> > 'workaround'...
>
> A workaround for what? If it works perfectly, with absolutely no
> compromises, how is it a workaround?
>
It's a workaround because the POV source code is not C++ code, it's C
code. Any true solution to the problem should work on any given _C_
compiler. Unfortunately there are no true solutions to this problem, only
workarounds - either use carefully declared and used macros or a C++
compiler and templated functions - both workarounds in the context of the
POV source code.
--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 8 Aug 2002 06:36:08 +0100, "Pandora"
<pan### [at] pandora-softwarecom> wrote:
> It's a workaround because the POV source code is not C++ code, it's C
>code.
Is not - POV now requires a C++ compiler. Some parts are C++, that's
why.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Pandora <pan### [at] pandora-softwarecom> wrote:
> It's a workaround because the POV source code is not C++ code, it's C
> code.
Wrong. POV-Ray 3.5 requires a C++ compiler in order to be compiled, and
it uses the standard std::min() and std::max() functions of the C++ standard
library <algorithm>.
The problem is that it lacks the std:: prefix (either in the function calls
themselves or implicitly through a 'using' command). This is simply a human
mistake; the original intention was to use the C++ standard functions.
--
#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 <3d5202ff$1@news.povray.org>,
"Pandora" <pan### [at] pandora-softwarecom> wrote:
> It's a workaround because the POV source code is not C++ code, it's C
> code. Any true solution to the problem should work on any given _C_
> compiler. Unfortunately there are no true solutions to this problem, only
> workarounds - either use carefully declared and used macros or a C++
> compiler and templated functions - both workarounds in the context of the
> POV source code.
Your information is out of date, POV 3.5 requires C++. Templates aren't
a workaround, they are the correct solution.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d52579e@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> The problem is that it lacks the std:: prefix (either in the function calls
> themselves or implicitly through a 'using' command). This is simply a human
> mistake; the original intention was to use the C++ standard functions.
Unfortunately not. The "using namespace std;" in config.h is the only
appropriate way as it makes sure everything works fine even with outdated
C++ library versions and compilers not supporting namespaces. So hardcoding
namespace usage into the source code just for this would cause more trouble
than problems it would solve. And using macros (as previously in frame.h)
is no longer an option as it tends to cause trouble for ISO compliant C++
compiler and library combinations!
The real problem is that nobody seems to have read the Unix source code
notes which probably tell which compiler was used. How to properly adjust
the source code for a different compiler and library combination is the job
of the person compiling, not that of the POV-Team. And that is precisely
what config.h is for*.
Thorsten
* And that is why in the Mac specific config.h you will findexactly that
line: using namespace std;
____________________________________________________
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3d5202ff$1@news.povray.org>,
> "Pandora" <pan### [at] pandora-softwarecom> wrote:
>
> > It's a workaround because the POV source code is not C++ code
>
> Your information is out of date, POV 3.5 requires C++.
It seems it is. I haven't taken a look at the 3.5 source yet - have had
the 3.1 source for ages, compiled it once, never touched it since.
> Templates aren't a workaround, they are the correct solution.
Indeed so.
I still stand by the statement that "templated min/max functions _could_
be seen as a workaround" in some contexts though.
--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
