 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think in the next version of POV (eg 4), there should be real
functions, not macros.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 23 Jul 2000 21:53:51 -0700, David wrote:
> I think in the next version of POV (eg 4), there should be real
>functions, not macros.
>
It's an interpreted language. What do you see are the differences?
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povray org> wrote:
: It's an interpreted language. What do you see are the differences?
I have an idea. Add a new keyword #function, which is just a synonym for
#macro. This way everyone can use whichever they like and will be happy :)
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <B5A119EF.1928%dav### [at] maccom>, David
<dav### [at] maccom> wrote:
> I think in the next version of POV (eg 4), there should be real
> functions, not macros.
Why? Functions would be much more restricting than macros, and not any
more useful.
Don't forget that the current macros don't behave exactly like C
macros...for example, the parameters are actual variables, not bits of
text that are cut and pasted into the body. The body *is* copy-pasted,
which allows a macro to do and generate anything, without needing a
single return type.
Anyway, isosurface functions already use the "function" keyword. :-)
I think it might be worth it to have these functions be available to
ordinary calls, like this:
#declare myFunc = function (A=0, B=1){sin(A)*cos(B)}
#declare Val = myFunc(2, 1.6);
#declare Val2 = myFunc(3);
#declare Val3 = myFunc();
This would be most useful if functions could have different numbers of
parameters, not just 3. The above declaration would have 2 parameters, x
and y, defaulting to 0 and 1. The default parameter list would be (x, y,
z), so this would be backward compatible with all existing functions.
And while they would be restricted to scalar values, they would probably
parse faster than macros.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, for one, a fuction can return a var. Perhaps you can return with a
marco, but I don't know how...
Functions can have templates. Hmmm...what else...fuctions can be used for
overloading. The list goes on.
> From: Chris Huff <chr### [at] maccom>
> Newsgroups: povray.programming
> Date: Mon, 24 Jul 2000 13:27:11 -0500
> Subject: Re: Fuctions
>
> In article <B5A119EF.1928%dav### [at] maccom>, David
> <dav### [at] maccom> wrote:
>
>> I think in the next version of POV (eg 4), there should be real
>> functions, not macros.
>
> Why? Functions would be much more restricting than macros, and not any
> more useful.
> Don't forget that the current macros don't behave exactly like C
> macros...for example, the parameters are actual variables, not bits of
> text that are cut and pasted into the body. The body *is* copy-pasted,
> which allows a macro to do and generate anything, without needing a
> single return type.
>
> Anyway, isosurface functions already use the "function" keyword. :-)
> I think it might be worth it to have these functions be available to
> ordinary calls, like this:
> #declare myFunc = function (A=0, B=1){sin(A)*cos(B)}
>
> #declare Val = myFunc(2, 1.6);
> #declare Val2 = myFunc(3);
> #declare Val3 = myFunc();
>
> This would be most useful if functions could have different numbers of
> parameters, not just 3. The above declaration would have 2 parameters, x
> and y, defaulting to 0 and 1. The default parameter list would be (x, y,
> z), so this would be backward compatible with all existing functions.
> And while they would be restricted to scalar values, they would probably
> parse faster than macros.
>
> --
> Christopher James Huff - Personal e-mail: chr### [at] maccom
> TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
> Personal Web page: http://homepage.mac.com/chrishuff/
> TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <B5A20496.1935%dav### [at] maccom>, David
<dav### [at] maccom> wrote:
> Well, for one, a fuction can return a var. Perhaps you can return
> with a marco, but I don't know how...
Macros can return variables and expressions:
#macro Foo(Bar)
#local Blah = Bar*2;
Blah
#end
#macro Foo2(Bar)
(Bar*2)
#end
They can also recurse, can have local variables, and can contain any
statement you can put in a POV file, other than macro definitions.
> Functions can have templates. Hmmm...what else...fuctions can be used for
> overloading.
No. Those are specific features of C++ functions, and perhaps of
functions in some other languages. They are not required in order for
something to be a "function", but are features of a specific language,
which happens to be quite a bit different from POV-Script. C, for
example, has functions, but does not have overloading or templates.
Some of those could be added to POV macros, and some aren't necessary or
couldn't be done even if functions were used, because of the structure
of POV-Script.
> The list goes on.
Please continue, then.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 23 Jul 2000 21:53:51 -0700 David <dav### [at] maccom> wrote:
>Subject: (bleep)
Whew! Glad the topic was *functions* <s>.
--
Alan - ako### [at] povrayorg - a k o n g <at> p o v r a y <dot> o r g
http://www.povray.org - Home of the Persistence of Vision Ray Tracer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> No. Those are specific features of C++ functions, and perhaps of
> functions in some other languages. They are not required in order for
> something to be a "function", but are features of a specific language,
> which happens to be quite a bit different from POV-Script. C, for
> example, has functions, but does not have overloading or templates.
> Some of those could be added to POV macros, and some aren't necessary or
> couldn't be done even if functions were used, because of the structure
> of POV-Script.
Why don't we simply try to build a POV-C++ library? You would write the code in
full OOP in C style, compile it and that would give you a scene renderer or
anything else as useful... i don't know... I just like the idea of programming
POV-Ray in C++ just as I do with OpenGL... That would be cool then to merge
these two... OpenGL for the preview and POV-Ray for the final...
But that's up to you, I'm already programming in parallel with OpenGL and
POV-Ray to test my camera movements and such...
Thanks,
Simon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <397CC152.575CC3BB@yahoo.com>, lem### [at] yahoocom wrote:
> Why don't we simply try to build a POV-C++ library? You would write
> the code in full OOP in C style, compile it and that would give you a
> scene renderer or anything else as useful... i don't know... I just
> like the idea of programming POV-Ray in C++ just as I do with
> OpenGL... That would be cool then to merge these two... OpenGL for
> the preview and POV-Ray for the final...
>
> But that's up to you, I'm already programming in parallel with OpenGL and
> POV-Ray to test my camera movements and such...
Making libraries or frameworks in C++ or Java has been discussed, but
doesn't fill the same purpose...it would require a compiler, for one
thing. Also, these languages are much more complex, more difficult to
learn, and aren't designed for scene description.
Still, it would be useful to have a framework to emit POV-Script and
possibly call POV to render the script...I have a C++ vector class that
I could contribute to the project, though Java might be a better choice
for cross-platform compatibility. I doubt the POV-Team has the time to
devote to such a thing, so it would be a 3rd party or community project.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Making libraries or frameworks in C++ or Java has been discussed, but
> doesn't fill the same purpose...it would require a compiler, for one
> thing. Also, these languages are much more complex, more difficult to
> learn, and aren't designed for scene description.
>
> Still, it would be useful to have a framework to emit POV-Script and
> possibly call POV to render the script...I have a C++ vector class that
> I could contribute to the project, though Java might be a better choice
> for cross-platform compatibility. I doubt the POV-Team has the time to
> devote to such a thing, so it would be a 3rd party or community project.
A Community Project! Why not? Like MesaGL over OpenGL we could create a
POV-Lib... don't you think?
I've already started my own... it's small but growing! and it rocks...
Thanks,
Simon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
