In article <397d8cb8@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   What is shorter, to write the 6 lines of code above for every pair of
> structs you use, or just write the swap function directly?
>
>   Perhaps in this case it could be better to have a 'swap' method inside
> the classes/structs, so you could write:
>
>   a.swap(b);

For the swap function this is to long, yes, but what about classes similar
to ones link vector<>, list<> or map<> templates in C++?  While in many
cases good old void pointers will do, it is possible to use macros instead.

Anyway, my point was not that templates are easy and good to do in C, just
that it is possible with a little bit of work to get a lot of features of
C++ in C - and the three lines would be exactly what it would takes to
implement a vector<> template of any class in C.


     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

Chris Huff wrote:
> 
> In article <3975DC6C.3C023FF2@itam.cas.cz>, Disnel <dis### [at] itamcascz>
> wrote:
> 
> > 2) No one talked about virtual methods, although its big advantage, I
> > think.
> 
> I don't think they would apply to POV-Script...their main use is when
> referring to objects by pointers, and POV-Script doesn't have pointers.
> I think that *all* methods would behave "virtual", separate bindings
> would be useless in POV-Script.

But what are POV #declares? They can be taken as references, I think.
You are right with virtual methods, all would behave "virtual"

> 
> > This is true when you don't allow changing objects after they have been
> > parsed, but I think, that can be one great advantage, mainly in
> > persistent animations.
> 
> I don't see what you mean...why would changing the object be a problem?

For example I have two spheres and my new object, which connects
these two spheres with cylinder. When one sphere was changed during
animation, my connecting object need to be notified about it.
Where it contains only copies of sphere, it knows nothing about
change.

> If you mean adding members to an existing variable, then don't do that!
> It would be like trying to add variables and methods to a C++ class.
> Just make a new object from that one, which has the additional members
> you need.

I don't mean anything else.

> If you mean modifying an object which has been placed in the scene, and
> isn't a variable, then (again) don't do that! Modify the object, and
> *then* put it in the scene. This will work with persistent variables
> just fine...

Here we don't understand: you are thinking about object oriented
preprocesor and I'am thinking about object oriented scene during
rendering and animation, I'am right?

> 
> --
> 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 <397F0286.85776D5C@itam.cas.cz>, Disnel <dis### [at] itamcascz> 
wrote:

> But what are POV #declares? They can be taken as references, I think.

I suppose they could be considered references...
You could create basic "types" by making certain base objects to 
inherit/copy from, just like you do in some of the include 
files(shapes.inc, for example). Members would be copied as well. In 
other words, objects inherit from objects, not from object types.
My idea doesn't separate types of objects and actual objects, like C++, 
but it should work, and might be much easier for people to learn. 
Besides, I don't see any simpler way of adding OOP to POV-Script.


> You are right with virtual methods, all would behave "virtual"

I don't see how they couldn't, since POV is interpreted all in one pass, 
and doesn't have separate compile-link-run stages. That, and the way 
it's "types" are done...


> For example I have two spheres and my new object, which connects
> these two spheres with cylinder. When one sphere was changed during
> animation, my connecting object need to be notified about it.
> Where it contains only copies of sphere, it knows nothing about
> change.

I still don't see the problem...have one sphere be changed with a member 
macro, which calls member macros of the other sphere and the linking 
cylinder. When one changes, the other two will be updated automatically. 
The main sphere is updated every frame of the animation, and all three 
are stored in persistent variables, say Sphere1, Cylinder, and Sphere2. 
After processing is done, copies of them are placed in the scene, like 
this:
Sphere1.Update(clock);

object {Sphere1}
object {Cylinder}
object {Sphere2}



> > If you mean adding members to an existing variable, then don't do that!
> > It would be like trying to add variables and methods to a C++ class.
> > Just make a new object from that one, which has the additional members
> > you need.
> 
> I don't mean anything else.

Just make a new variable/class with the new members, and using the same 
name as the parent object...like this:
#declare Foo = object {...}
#declare Foo = object {Foo ...new members...}
Where is the problem? You don't need to be able to add variables or 
functionality to an existing object, just create a new one derived from 
the original. What do you think inheritance is for?


> Here we don't understand: you are thinking about object oriented
> preprocesor and I'am thinking about object oriented scene during
> rendering and animation, I'am right?

No processing of the scene file is done during rendering...the scene 
*has* to remain static during that stage, and it wouldn't make sense 
otherwise. It makes sense to only modify objects which you have in 
dynamic form, as a variable. As for animation, the scene is reprocessed 
before every frame. You can keep variables from one frame to the next, 
what is wrong with modifying those and rebuilding the scene each frame?

-- 
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

Chris Huff wrote:
> 
> In article <397F0286.85776D5C@itam.cas.cz>, Disnel <dis### [at] itamcascz>
> wrote:
> 
> > But what are POV #declares? They can be taken as references, I think.
> 
> I suppose they could be considered references...
> You could create basic "types" by making certain base objects to
> inherit/copy from, just like you do in some of the include
> files(shapes.inc, for example). Members would be copied as well. In
> other words, objects inherit from objects, not from object types.
> My idea doesn't separate types of objects and actual objects, like C++,
> but it should work, and might be much easier for people to learn.
> Besides, I don't see any simpler way of adding OOP to POV-Script.

I also think, that C++ style with class declaration and using
new after is inappropriate for POV language. Better will be
true OO style: each object can contain each object, messages
sent to object are also objects and result of message sent to object is
also object.

> 
> > You are right with virtual methods, all would behave "virtual"
> 
> I don't see how they couldn't, since POV is interpreted all in one pass,
> and doesn't have separate compile-link-run stages. That, and the way
> it's "types" are done...

Sure, they can.

> 
> > For example I have two spheres and my new object, which connects
> > these two spheres with cylinder. When one sphere was changed during
> > animation, my connecting object need to be notified about it.
> > Where it contains only copies of sphere, it knows nothing about
> > change.
> 
> I still don't see the problem...have one sphere be changed with a member
> macro, which calls member macros of the other sphere and the linking
> cylinder. When one changes, the other two will be updated automatically.
> The main sphere is updated every frame of the animation, and all three
> are stored in persistent variables, say Sphere1, Cylinder, and Sphere2.
> After processing is done, copies of them are placed in the scene, like
> this:
> Sphere1.Update(clock);
> 
> object {Sphere1}
> object {Cylinder}
> object {Sphere2}

Yes, it will work, but it will waste memory and CPU time,
its no problem with sphere but if you want make descendant from 50MB
tree, it will be very unfortunate.
Second, it will be unnecessary compilcated to use.

> 
> > > If you mean adding members to an existing variable, then don't do that!
> > > It would be like trying to add variables and methods to a C++ class.
> > > Just make a new object from that one, which has the additional members
> > > you need.
> >
> > I don't mean anything else.
> 
> Just make a new variable/class with the new members, and using the same
> name as the parent object...like this:
> #declare Foo = object {...}
> #declare Foo = object {Foo ...new members...}
> Where is the problem? You don't need to be able to add variables or
> functionality to an existing object, just create a new one derived from
> the original. What do you think inheritance is for?

Maybe.

> 
> > Here we don't understand: you are thinking about object oriented
> > preprocesor and I'am thinking about object oriented scene during
> > rendering and animation, I'am right?
> 
> No processing of the scene file is done during rendering...the scene
> *has* to remain static during that stage, and it wouldn't make sense
> otherwise. It makes sense to only modify objects which you have in
> dynamic form, as a variable. As for animation, the scene is reprocessed
> before every frame. You can keep variables from one frame to the next,
> what is wrong with modifying those and rebuilding the scene each frame?

Sure, scene should remain static during rendering, you are right ;-).
But rebuilding whole scene for each frame is once more wasting
of CPU time, is some cases, chance to use objects from previsous
scene with only slight modifications can improve rendering time.
For example smoothing height field, tree generation .... It can be
done once for whole animation.

> 
> --
> 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

Disnel <dis### [at] itamcascz> wrote:
: I also think, that C++ style with class declaration and using
: new after is inappropriate for POV language.

  Firstly, you have to define somehow what the object looks like. A class
is as good as any other method of doing it. I don't see the problem.
  Secondly, you don't need to use 'new'. I seldom use it although I code
a lot in C++.

: Better will be
: true OO style: each object can contain each object, messages
: sent to object are also objects and result of message sent to object is
: also object.

  It seems to be that a variable or table or structure allocated in the
memory (and some 'handle' to get it) becomes an 'object' after you just
say "this is an object". As long as you don't say it, it's not an object,
but something else.
  Of course everything can be considered an object. What else could it be?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39815686.AA9BAAB5@itam.cas.cz>, Disnel <dis### [at] itamcascz> 
wrote:

> Better will be true OO style: each object can contain each object, 
> messages sent to object are also objects and result of message sent 
> to object is also object.

This could be done...just pass the message object as a parameter to a 
member macro.


> Sure, they can.

That is what I meant: they can't not be like this. It wouldn't make 
sense for them to be any other way.


> Yes, it will work, but it will waste memory and CPU time,
> its no problem with sphere but if you want make descendant from 50MB
> tree, it will be very unfortunate.
> Second, it will be unnecessary compilcated to use.
...snip...
> But rebuilding whole scene for each frame is once more wasting
> of CPU time, is some cases, chance to use objects from previsous
> scene with only slight modifications can improve rendering time.
> For example smoothing height field, tree generation .... It can be
> done once for whole animation.

First, I don't think it would be any slower and not much more memory 
intensive. Some data could be shared, and only duplicated when 
absolutely necessary.
And it wouldn't be more complicated...you have to add those objects to 
the scene in the first place, being able to modify objects which are 
already in the scene could easily get more complex than modifying 
variables, and it might not be as efficient in memory usage.

-- 
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

Declaration of object structure you need when objects has types,
I'am thinking about untyped language.

Warp wrote:
> 
> Disnel <dis### [at] itamcascz> wrote:
> : I also think, that C++ style with class declaration and using
> : new after is inappropriate for POV language.
> 
>   Firstly, you have to define somehow what the object looks like. A class
> is as good as any other method of doing it. I don't see the problem.
>   Secondly, you don't need to use 'new'. I seldom use it although I code
> a lot in C++.
> 
> : Better will be
> : true OO style: each object can contain each object, messages
> : sent to object are also objects and result of message sent to object is
> : also object.
> 
>   It seems to be that a variable or table or structure allocated in the
> memory (and some 'handle' to get it) becomes an 'object' after you just
> say "this is an object". As long as you don't say it, it's not an object,
> but something else.
>   Of course everything can be considered an object. What else could it be?
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

> This could be done...just pass the message object as a parameter to a
> member macro.

Sure, its one implementation. But not neccessary the one possible.

> 
> > Sure, they can.
> 
> That is what I meant: they can't not be like this. It wouldn't make
> sense for them to be any other way.
> 

OK. You are right.

> First, I don't think it would be any slower and not much more memory
> intensive. Some data could be shared, and only duplicated when
> absolutely necessary.

But its not a "copy" of object, then.

> And it wouldn't be more complicated...you have to add those objects to
> the scene in the first place, being able to modify objects which are
> already in the scene could easily get more complex than modifying
> variables, and it might not be as efficient in memory usage.

How you mean "add in the first place"?

If some object will support it (heightfield is able to change its small
part, for example) it will be very usable. All objects should support
basic things, such as transformation matrix change, texture change....


Disnel

Post a reply to this message

In article <398ACFB9.BBCFCC2B@itam.cas.cz>, Disnel <dis### [at] itamcascz> 
wrote:

> Sure, its one implementation. But not neccessary the one possible.

It seems to be the easiest and simplest way to do it, with minimal 
disturbance to the existing language.


> But its not a "copy" of object, then.

Sure it is. Just because shared data isn't duplicated doesn't mean it is 
a different object. For example, you can have many "copies" of a mesh 
which share the same mesh data, possibly saving megabytes of memory. 
Textures also can share data, and I think the same goes for height 
fields.


> How you mean "add in the first place"?

The object was placed in the scene before, there is no other way for it 
to get there. :-)
Since you obviously have code to put it in the scene, just don't add 
extra code to not put in the scene for later frames.
If persistant objects are used, you have to check to see if the object 
already exists, and if it does, than don't add it to the scene again, or 
you will just waste memory and render time. If only persistent variables 
are used, you don't have to do this. You don't have to have special 
handling for placing an object in the scene, or any special code for 
modifying it.

-- 
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

> It seems to be the easiest and simplest way to do it, with minimal
> disturbance to the existing language.

OK.

> 
> > But its not a "copy" of object, then.
> 
> Sure it is. Just because shared data isn't duplicated doesn't mean it is
> a different object. For example, you can have many "copies" of a mesh
> which share the same mesh data, possibly saving megabytes of memory.
> Textures also can share data, and I think the same goes for height
> fields.

OK. I meaned "copy" as physical copy, not only shared data.
If you will use shared data, all is OK.

> 
> > How you mean "add in the first place"?
> 
> The object was placed in the scene before, there is no other way for it
> to get there. :-)
> Since you obviously have code to put it in the scene, just don't add
> extra code to not put in the scene for later frames.
> If persistant objects are used, you have to check to see if the object
> already exists, and if it does, than don't add it to the scene again, or
> you will just waste memory and render time. If only persistent variables
> are used, you don't have to do this. You don't have to have special
> handling for placing an object in the scene, or any special code for
> modifying it.

But when I need to scale height field in y direction during
animation, for example, I need to modify it for each frame.
But rebuilding whole HF for each frame is not neccessary
(OK, I don't know if POV does some precomputation for HF
which should need rebuild of HF structure when changing
its scale, but its only for example).

Best regards

Disnel

Post a reply to this message