 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d517fdb@news.povray.org>,
"Pandora" <pan### [at] pandora-software com> 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
|
|
| |
| |
|
|
|
|
| |
