POV-Ray : Newsgroups : povray.general : pov source gcc3 problem Server Time
6 Aug 2024 00:14:10 EDT (-0400)
  pov source gcc3 problem (Message 11 to 20 of 29)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 9 Messages >>>
From: Warp
Subject: Re: pov source gcc3 problem
Date: 2 Aug 2002 23:11:04
Message: <3d4b49c7@news.povray.org>
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

From: Ron Parker
Subject: Re: pov source gcc3 problem
Date: 2 Aug 2002 23:52:03
Message: <slrnakmkr7.p6d.ron.parker@fwi.com>
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

From: Peter Popov
Subject: Re: pov source gcc3 problem
Date: 3 Aug 2002 00:00:23
Message: <69lmku4dg5b309dkocfslhb83g50mbkqnb@4ax.com>
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

From: Christoph Hormann
Subject: Re: pov source gcc3 problem
Date: 3 Aug 2002 03:57:45
Message: <3D4B8CF7.90B5D011@gmx.de>
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

From: Warp
Subject: Re: pov source gcc3 problem
Date: 3 Aug 2002 06:25:57
Message: <3d4bafb5@news.povray.org>
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

From: Rafal 'Raf256' Maj
Subject: Re: pov source gcc3 problem
Date: 3 Aug 2002 09:25:12
Message: <Xns925F9C3FAB755raf256com@204.213.191.226>
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

From: Ron Parker
Subject: Re: pov source gcc3 problem
Date: 3 Aug 2002 12:42:30
Message: <slrnako1vs.rnc.ron.parker@fwi.com>
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

From: Pandora
Subject: Re: pov source gcc3 problem
Date: 6 Aug 2002 21:29:29
Message: <3d5077f9$1@news.povray.org>
"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

From: Warp
Subject: Re: pov source gcc3 problem
Date: 6 Aug 2002 22:23:21
Message: <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.

> 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

From: Pandora
Subject: Re: pov source gcc3 problem
Date: 7 Aug 2002 16:15:23
Message: <3d517fdb@news.povray.org>
"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

<<< Previous 10 Messages Goto Latest 10 Messages Next 9 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.