In article <cjameshuff-CF95A3.17100922022004@news.povray.org> , Christopher
James Huff <cja### [at] earthlinknet>  wrote:

> I've written a raytracer using vectors that use operator overloading. It
> was much easier to see what the code did than it is in POV, which uses
> macros for the vector operations.

In the source code you have access to it doesn't!

    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

"Tek" <tek### [at] evilsuperbraincom> wrote in message
news:40393ba8$1@news.povray.org...
> "Dan P" <dan### [at] yahoocom> wrote in message
> news:4039335d$1@news.povray.org...
> > Thank you, Warp.
>
> Uh, I said that, not him.
>
> > This has been a puzzle for me for some time now: why do so
> > many programmers write such awful code?
>
> It seems impossible for me to make a statement without people taking it
too far!

Oh, I'm sorry; I didn't think that sounded like you, Tek :-)

Post a reply to this message

In article <40392dba$1@news.povray.org>, "Tek" <tek### [at] evilsuperbraincom> 
wrote:

> Well yes, I'm not debating that. I'm saying for what you're doing 
> it's better to deal with things on a cleaner more mathematical basis, 
> but for what I do at work it's better to deal with things on a more 
> technical implementation-based level.

No...I don't give a damn about the mathematics. It's just cleaner 
looking and easier to read with overloaded operators. Easier and faster 
to write and debug, giving me much more time to spend on optimization or 
extension of the program.


> > Yes you did...in a reply to one of my earlier messages:
> No, I said it was an argument against the *use* of operator overloading, not
> it's existence. I'm not saying it should never be used, I'm just explaining 
> why we don't use it.

Then why did you even reply to my message?


> Which still is not a reason to hide what the code is actually doing.

The only information hidden is that which isn't of any use to the 
situation anyway. You don't need to know exactly how vectors and 
matrices are multiplied, it is enough to know that doing so is 
time-consuming.


> Besides, a good optimiser does neither of those, you begin by 
> profiling the system extensively to ascertain what is slow. It 
> doesn't matter how cumbersome the big concepts are, or how badly 
> implemented the low level things are, all that matters is how long 
> things take.

I did mention "specific bottlenecks". How do you think those bottlenecks 
would be found, if not by profiling the program?


> > And I don't buy your argument about vector-matrix
> > multiplication...if you're doing high-performance code, you should
> > always be aware of the types you're working with.
> 
> But how do I gain this awareness if it's not my code?

You read the code.


> Last project I 
> was on had 20 programmers, and I was one of the main people assigned 
> to optimise things. It was more important to me to see how the code 
> worked at a lower level than to see nice clean algorithms.

You regularly have separate programmers coding and optimizing? That does 
not sound like a good idea...the person optimizing starts out knowing 
nothing about the code.
And again, it's not about "nice clean algorithms", it's "nice clean 
*code*" that lets you see what's being done!


> However I know there are other games companies that go all out for OO code,
> because they wish to code at a higher level. They do not produce such 
> efficient code as we do :)

Then they're doing it wrong. And what company do you work for? I never 
want to work there.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-CD5ABF.18305722022004@news.povray.org...
> In article <4039335d$1@news.povray.org>,
>  "Dan P" <dan### [at] yahoocom> wrote:
>
> > > > > We like the clunkier syntax *because* it is harder to use and
requires
> > more
> > > > > thought from the programmer. In our situation this is a good
thing.
> >
> > Thank you, Warp. This has been a puzzle for me for some time now: why do
so
> > many programmers write such awful code? At first, I thought it was
because
> > they didn't want other programmers to understand it because they could
be
> > replaced. Then, I figured it was just because they were engineers with
no
> > sense of cognitive psychology. Finally, I read your message, and now I
> > understand it: these engineers are doing the world a /favor/ by making
code
> > hard to read because it makes other programmers think more. I get it
now!
> > It's alturism.
> >
> > Don't send me a resume.
>
> Warp didn't write that. And even if he had, your attack would have been
> completely unwarranted. Speaking as a member of the TAG, please stop
> these personal attacks, insults, and other anti-social behavior. Now.

That wasn't an attack, that was sarcasm. I apologize, Warp; I didn't realize
that wasn't you that said that. Chris, if you want to single me out, okay,
but this group is anything but friendly and I'm just as happy to remove it
from my newsgroups list as you are to remove me from it. Because I feel
personally attacked every time I write a message on this board, particularly
when I post code of any sort. Messages like, "You should read an OO book"
are pretty damned insulting and pretty damned personal so I ask you,
politely, to remove the double-standard when wielding your "big stick".

Post a reply to this message

In article <40393bc7$1@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> > I've written a raytracer using vectors that use operator overloading. It
> > was much easier to see what the code did than it is in POV, which uses
> > macros for the vector operations.
> 
> In the source code you have access to it doesn't!

In the currently final version, the version that everyone has access to, 
it does. ;-)

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> Because I feel
> personally attacked every time I write a message on this board, particularly
> when I post code of any sort. Messages like, "You should read an OO book"
> are pretty damned insulting and pretty damned personal so I ask you,
> politely, to remove the double-standard when wielding your "big stick".

  No, there's no conspiracy against you here.

  I don't tend to remember people names for negative things, but tend to
easily forget them. If I have a flamewar with someone and then it stops,
after a week or two I have probably already totally forgotten the name
of my "adversary". In fact, I wasn't completely sure if it was you whose
C code I commented when I responded with the OO things (and I didn't make
much effort remembering, for that matter).

  Although you might feel like it, this is not a place where regulars
select some newcomer at random and start attacking him as a team effort.
That would be completely silly.
  If you are receiving tons of negative responses, then think about why
that may happen. It's certainly not a conspiracy against you personally.

-- 
#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:403946d7@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
>
>   Although you might feel like it, this is not a place where regulars
> select some newcomer at random and start attacking him as a team effort.
> That would be completely silly.
>   If you are receiving tons of negative responses, then think about why
> that may happen. It's certainly not a conspiracy against you personally.

Actually, I think I am wired a little different. Here's an example: when you
said to someone, "If you don't know what operator+() does with the type you
are using, then you should seek another job, IMHO," I thought that was far
worse than anything I have ever said to anybody on here by at least a factor
of 10. I've never said you weren't qualified to do your job or even hinted
at it. In my response, I indirectly said that I wouldn't want you working
for /me/. But, I think you aren't using an active reference in your
sentence. What I mean by that is I read your message as, "You, poster, don't
know what the operator +() does and, therefore, you should seek another
job." What I think you must be saying, if it isn't insulting, is, "If some
person doesn't know whwat operator +() does with the type you are using,
then that person should seek another job." Even that could be taken the
wrong way, but it is not direct and, therefore, not an "attack".

I think we have different parsers and I'm going to have to adjust mine to
get along here. Plus, I felt way more negatively about what I thought you
were saying because I have to deal with that on a daily basis and it just
makes my job hard... I was emotional and /wrong/ for being so.

Can I get another chance at fixing my parser?

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> > And in real languages, you don't even have to tell the compiler to do
> > that. ;-)

> You don't need to do in C++ either.  "inline" is only a hint to the compiler
> just like the "register" keyword.  Most modern compilers will inline
> whatever they see fit, and some will even completely ignore the "inline"
> keyword and find a better selection of functions to inline.

  What I meant when I said that the operator function should be made
"inline" was that it should be implemented where it's declared (or
at least at the same visibility level).
  If the function is declared in a header file but implemented in a
separate object file then the compiler naturally can't inline it.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> Argh...forget about virtual functions. They are an artifact of C++, 
> which does everything statically by default. I specifically said no 
> static binding. No virtual functions, because everything is dynamically 
> bound.

  What do you mean "no virtual functions"? If every function is dynamically
bound, then *every* member function is virtual.

  At least you should be able to specify a default implementation for
a member function or live it as purely virtual.
  If you leave all the member functions as purely virtual, then what
you have is an interface.

> >   A class is abstract if it has pure virtual functions (that is,
> > the class does not implement the virtual function(s) and thus cannot
> > be instantiated because of this; it can only be used through
> > inheritance so that the derived class implements the virtual
> > function(s) in question).

> Again, I'm talking about single inheritance. Multiple inheritance is not 
> necessary, and is needlessly complex.

  Who is talking about multiple inheritance here? I'm not.

  And multiple inheritance may be complex from the point of view of
the interpreter/compiler, not from the point of view of the user.
Why should that be a limit?

> Abstract classes are not as useful 
> in single inheritance models, interfaces cover their functionality. 

  I don't understand what you are saying.
  Why have *two* types of classes when you can have just one?
And why abstract classes are not useful in single inheritance model?

> Interfaces render multiple inheritance + multiple abstract root classes 
> obsolete, not the other way around.

  Interfaces are a poor way of making multiple inheritance. They have
all the logical problems of multiple inheritance and they force you
to make code repetition.
  I have never understood what's so good about interfaces.

> >   That's right. *You*. But that's ok only for as long as you don't
> > distribute that library of yours containing public member variables...
> > Someone will inevitably use it in the wrong way and his code can then
> > break with an updated version of the library.

> That's their fault

  You can't design libraries with that principle.

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

> Then why did you even reply to my message?

You said you'd never seen a good argument against it, I merely wanted to tell
you the argument against it that I've heard, since it was good enough to
convince the programmers I know. I never meant the argument was against operator
overloading being used by anyone, just against it being used in the environments
I've worked in. It was really only inteded as trivia, I never meant to spark
such a long discussion! :)

Though I confess at the time I heard the argument I knew far too little about OO
code, so I've failed miserably to convey the true convincingness of the original
discussion...

Well that's my excuse.

> The only information hidden is that which isn't of any use to the
> situation anyway. You don't need to know exactly how vectors and
> matrices are multiplied,

Yes, *I* do. That's what I'm saying. That's why we don't use operator
overloading, because we prefer to see the information that it hides.

> You regularly have separate programmers coding and optimizing?

Not exactly, but some of us can optimise a lot better than others. Besides we
believe everyone should write code in a way that anyone else can read, and for
our purposes that means at a lower level than true OO.

> Then they're doing it wrong. And what company do you work for? I never
> want to work there.

Naughty Dog, (Jak & Daxter, Crash Bandicoot, and the engine for Ratchett &
Clank), and until recently I worked for Codemasters (on the Toca series of
games). Just a few little multimillion selling titles, I'm sure we don't have a
clue what we're doing.

There are higher level languages and there are lower level languages, you have
to choose what you use according to the nature of what you do. The games
industry has progressed from Assembler to C to using some features of C++, but
(in our case) not all of them, because the nature of the games we develop is
gradually becoming more high level.

In the future we shall doubtless move to a more pure C++ style of code, but it
is naive to presume that assembler is simply inferior to C++. Higher level is
not necessarily better, it depends on the nature of the program you are
developing. We have chosen our level based on many decades of combined
experience of games development, and whilst I may not personaly be able to
explain all the reasons for this (since my OO experience is limitted) I think it
is foolish to assume these intelligent professionals would simply get it wrong.

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   Interfaces are obsolete of you can make abstract classes.

> Technically, they're obsolete if you have decent multiple inheritance. 
> The benefit of a Java interface is that you can be a Stream *and* a 
> Thread *and* an Iterator.

  Supposing you are happy with the fact that you must implement every
single method of Stream, Thread and Iterator in every single inherited
class... You can't group common functionality in the interfaces.

  This is one thing which I have never understood (and probably never
will) about interfaces: They *force* you to perform one of the basic
sins in programming: Code repetition.
  I thought Java was designed to force the programmer to make good
code, not bad code. *sigh*

  Besides, multiple inheritance was not included in Java because you
can use it "in the wrong way" (same song as with every non-included
feature in Java).
  How can you use multiple-inheritance in the wrong way? Well, one
classical example is that you have a Boat class and a Plane class
and you multiple-inherit a Hydroplane class from them. This is
bad OO design (mainly because a Hydroplane is not a boat).
  Well, make a Boat interface and a Plane interface and make
a Hydroplane class which implements them. What's the difference?

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

> Actually, I think I am wired a little different. Here's an example: when you
> said to someone, "If you don't know what operator+() does with the type you
> are using, then you should seek another job, IMHO," I thought that was far
> worse than anything I have ever said to anybody on here by at least a factor
> of 10.

Yeah, speaking as the recipient of that comment, I did find it a little uncalled
for. I'm not sure whether Warp was trying to suggest I'm an idiot or simply
assuming that myself and every professional games programmer I know fails to
understand how to write code, but in either case I think he was out of line.

Though my policy is that I don't tend to take offence unless it's a direct
insult. i.e. if you actually think I'm an idiot but you don't say so then we
should get along just fine.

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> > Int foo = container.size(); // <- gets a *reference*

> No, that initializes an Int named foo to the object returned by 
> container.size. Not a problem.

  And what if you *do* want a reference to the member variable?
You can't?

  (One common situation where you want to do this eg. in C++ is when
you have a big container inside another container and you return
a const reference to the internal container; this way the big internal
container is not needlessly copied, which would be inefficient, but you
can read it directly.)

> You could also introduce const references...not sure if its worth the 
> trouble.

  I think they are useful, as I mentioned above.
  Don't know what would be a practical syntax, though.

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

Tek <tek### [at] evilsuperbraincom> wrote:
> Yeah, speaking as the recipient of that comment, I did find it a little uncalled
> for. I'm not sure whether Warp was trying to suggest I'm an idiot or simply
> assuming that myself and every professional games programmer I know fails to
> understand how to write code, but in either case I think he was out of line.

  Nope, it was not directed at you personally.

  From what I understood, you said something in the lines of "I don't want
to hide a complex operation behind an overloaded operator because then
someone else could use that operator in the wrong way, not knowing what
it really does".
  To that I responded basically "if this someone" (ie not you) "uses your
library for some time-critical application and does not know what the
operator does, then he is in the wrong business".
  What I meant is that it's not your fault if someone uses your library
in the wrong way without taking care of knowing which functions are heavy
and which aren't.
  You can, of course, design the public interface of your library in
such way that even less aware coders are warned about a possible
inefficiency, and I fully understand this ideology. I just opposed
the idea of avoiding operator overloading in all cases.

  So no, I was not directing any insult or anything else against you
personally.

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

"Tek" <tek### [at] evilsuperbraincom> wrote in message
news:40394cc2$1@news.povray.org...
> > Actually, I think I am wired a little different. Here's an example: when
you
> > said to someone, "If you don't know what operator+() does with the type
you
> > are using, then you should seek another job, IMHO," I thought that was
far
> > worse than anything I have ever said to anybody on here by at least a
factor
> > of 10.
>
> Yeah, speaking as the recipient of that comment, I did find it a little
uncalled
> for. I'm not sure whether Warp was trying to suggest I'm an idiot or
simply
> assuming that myself and every professional games programmer I know fails
to
> understand how to write code, but in either case I think he was out of
line.
>
> Though my policy is that I don't tend to take offence unless it's a direct
> insult. i.e. if you actually think I'm an idiot but you don't say so then
we
> should get along just fine.

As I think more and more about this (I went for a drive to cool off), I
realize what is happening and what I'm doing wrong. I came on these groups
initially because I just made a move to an apartment where I'm isolated and
I needed some social interaction. I felt that, by coming on to a board where
I felt I could contribute, I would fill that need. Colored by the fact that
I am easily at the lowest point in my life of nothing but low points, I
didn't come in with a very thick skin to begin with.

It wasn't your commentary on my code, Warp, that made me angry initially -- 
it was when you supported Thorsten's personal attack on me that made me
angry with you. I've learned a lot from your critique and I feel honored
that you took the time to teach me how to do it right. Proof's in the thread
on my claim there.

Truth is, almost every one of the messages on this board makes me sad in
some way. Disrespect makes me feel sad -- not even angry, just sad, which
turns to anger when I start to rebel against it. I can't afford to be sad
and it is coloring how I read things and not in a good way. There are povray
boards that are making me happy, however, so I've decided to desubscribe to
this group and stick to the boards that make me happy. I'm not lurking -- 
not expecting a response -- Chris, you don't have to kill-file me -- I'm not
going to post here again.

For what it's worth, please accept my sincerest apologies for walking in and
stirring things up.

Post a reply to this message

>   To that I responded basically "if this someone" (ie not you) "uses your
> library for some time-critical application and does not know what the
> operator does, then he is in the wrong business".

Ah, I see. Yes, that is not an insulting statement to make, I simply
misinterpretted your meaning.

However, I find in my line of work that if you have to rely on people being able
to write good code, you will get an inferior result. We find these practices
make our style of coding easier, hence we use them. For more high-level
applications this approach would bog things down too much.

>   So no, I was not directing any insult or anything else against you
> personally.

In that case I shall stick to my policy of generally not interpretting anything
as an insult :)

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

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

>   What do you mean "no virtual functions"? If every function is dynamically
> bound, then *every* member function is virtual.

No. Virtual function tables are an implementation detail, the 
implementation specifically used by C++. There are other ways of 
implementing dynamic dispatch.


> > Again, I'm talking about single inheritance. Multiple inheritance is not 
> > necessary, and is needlessly complex.
> 
>   Who is talking about multiple inheritance here? I'm not.

You're implying it. You say abstract classes can replace interfaces. A 
class can have multiple interfaces, but in single interface models can 
only inherit from one class. Therefore, I figured you must be talking 
about multiple inheritance, because nothing else made sense.


>   And multiple inheritance may be complex from the point of view of
> the interpreter/compiler, not from the point of view of the user.
> Why should that be a limit?

Look at virtual inheritance and why it's necessary.


>   I don't understand what you are saying.
>   Why have *two* types of classes when you can have just one?

I never said anything about two class types...I have no idea how you're 
reading what I'm trying to say. 


> And why abstract classes are not useful in single inheritance model?

Because you can only inherit from one.


> > Interfaces render multiple inheritance + multiple abstract root classes 
> > obsolete, not the other way around.
> 
>   Interfaces are a poor way of making multiple inheritance. They have
> all the logical problems of multiple inheritance and they force you
> to make code repetition.

They do not have all the problems of multiple inheritance. And a 
language could have default implementations for interfaces. Java is not 
an example of a perfect, or even very good OO language.


>   I have never understood what's so good about interfaces.

They avoid many of the problems of multiple inheritance.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

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

>   If the function is declared in a header file but implemented in a
> separate object file then the compiler naturally can't inline it.

You would be surprised what some modern compilers can do if you care neither
about memory usage nor compilation time...

    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

In article <403947c4@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> OK, honestly, I misspoke. Folks were talking about C++ style 
> programming, and said something about lacking virtual functions. I 
> equated that to lacking dynamic dispatch, because that was kind of the 
> environment it was discussed in. The only dynamic dispatch in C++ is 
> virtual functions (or pointers to functions).

Ok, I was just talking about OO in general, not narrowing it down to a 
specific implementation.


> Sure, messages and methods are more than virtual functions. Objective-C 
> basically took the messaging model from Smalltalk and pasted it on top of C.

That's basically it. Works pretty well, actually, though it does look 
funny...and no blocks, unfortunately. There is the concept of "higher 
order messaging" that might take their place...


> > Virtual functions are just a specific implementation detail, not a core 
> > requirement for object oriented languages.
> 
> Correct. But I'd contend that dynamic dispatch (i.e., the same name used 
> at the same point in the program meaning different invocations at 
> different times in the execution of the program) is a core requirement.

I agree.


> > BTW, have you ever looked at Dylan?
> 
> No, but I've used Smalltalk. What's unique about Dylan that I should 
> look at it? :-)

Well, the name is an abbreviation of "Dynamic language". It's object 
oriented and very, well, dynamic. You mentioned Eiffel and said some 
things that made me think you were familiar with Smalltalk, so I thought 
you might know about Dylan...I don't know a lot about it myself, but it 
looks interesting. Hmm...
http://directory.google.com/Top/Computers/Programming/Languages/Dylan/
http://www.cetus-links.org/oo_dylan.html

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:403963c6@news.povray.org...
> In article <40394870@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:
>
> >   If the function is declared in a header file but implemented in a
> > separate object file then the compiler naturally can't inline it.
>
> You would be surprised what some modern compilers can do if you care neither
> about memory usage nor compilation time...

We enabled link time code generation on the last project I worked on, it made
the game a huge amount faster, and made the link time REALLY slow. Like over 5
minutes just for incremental builds. Nasty. Still a good thing to do on the
final build.

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

Tek <tek### [at] evilsuperbraincom> wrote:
> Ah, I see. Yes, that is not an insulting statement to make, I simply
> misinterpretted your meaning.

  I sometimes write things a bit hastily without re-reading them and
thinking if they could be understood in a different way than what I'm
thinking.

> However, I find in my line of work that if you have to rely on people being able
> to write good code, you will get an inferior result. We find these practices
> make our style of coding easier, hence we use them. For more high-level
> applications this approach would bog things down too much.

  I just took the "operator overloading is not good" part of your text
and answered to that... :)

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

Christopher James Huff <cja### [at] earthlinknet> wrote:
> >   I don't understand what you are saying.
> >   Why have *two* types of classes when you can have just one?

> I never said anything about two class types...I have no idea how you're 
> reading what I'm trying to say. 

  I can't see interfaces as anything else than very limited classes.

  For example, in Java I see two types of classes: The regular ones
and the extremely limited ones which they call "interfaces".
  What I wonder is why have two types of classes like this when just
one type suffices? IMO interfaces cause more problems than they avoid.

> > And why abstract classes are not useful in single inheritance model?

> Because you can only inherit from one.

  So basically what you want is to support multiple inheritance, but
without the possibility of grouping common functionality to the
"base classes" (ie. "interfaces" in this case) but forcing the inherited
classes to implement everything again and again?

> >   I have never understood what's so good about interfaces.

> They avoid many of the problems of multiple inheritance.

  From the compiler's point of view or the programmer's point of view?

  Can you present a good example?

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Right. But if you can't do multiple inheritance, you can't do that with 
> abstract classes either. Interfaces don't replace abstract classes, they 
> replace multiple inheritance. Abstract classes without multiple 
> inheritance is not a replacement for interfaces, either.

  But why forbid multiple inheritance?
  Everyone talks about multiple inheritance like it was a scary monster.
I have never understood why. All the examples of bad usages of multiple
inheritance are of the same type as how regular inheritance can be
used wrongly or how operator overloading can be used wrongly. Or what
the heck, how variable names can be used wrongly.

  As with all those other features, multiple inheritance is a very
powerful and useful feature when you know how to use it right.
  This is one reason why I hate Java: By trying to "protect" inexperienced
programmers they have taken away useful features from experienced ones who
know how to use the features right. My attitude with Java is "yes, I know
how things can be used wrongly, but I'm not going to, so give me the damn
features, ok?"

> >   This is one thing which I have never understood (and probably never
> > will) about interfaces: They *force* you to perform one of the basic
> > sins in programming: Code repetition.

> Well, more like they make it easier for the compiler-writer.

  So the maker of the compiler is simply lazy? ;)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   So basically what you want is to support multiple inheritance, but
> > without the possibility of grouping common functionality to the
> > "base classes" (ie. "interfaces" in this case) but forcing the inherited
> > classes to implement everything again and again?

> Right. It avoids a fairly wide range of problems, both semantic and 
> efficiency.

  So because the makers of the compiler are lazy they force the
user of the language to make bad code?

  C++ does multiple inheritance quite efficiently, and even if it didn't,
why should it matter? You just need to know how heavy multiple inheritance
is and then decide whether to use it or not in your application. However,
if you have a place where it would be extremely useful then it's good that
you have the possibility.
  One could argue that virtual functions are inefficient because they
produce internally an indirect function call (subroutine call to an
address got from behind a pointer got from behind a pointer), which
potentially make them slightly slower than regular function calls.
Does this mean virtual functions should be left out? Of course not.
You just need to be aware of what they do.

> Also, diamond-shaped inheritance is problematic, semantically speaking.

> For one: If D inherits from B and C, and both B and C inherit from A, 
> and A declares instance variables, how many copies of that instance 
> variable show up in D?

  Diamond-inheritance is truely rare, so if you want to forbid that
special situation IMHO you can. However, don't forbid *all* multiple
inheritances because of one specific case.
  In C++ if you want the base class to appear only once in the
bottommost inherited class in diamond-inheritance, you can make
the member variables of the base class virtual.

> A is a vehicle
> B is a plane
> C is a boat
> D is a hydroplane

  That was a classical example of bad OO design, so I don't think you
should be using it to demonstrate your point. ;)

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

Darren New <dne### [at] sanrrcom> wrote:
> >   But why forbid multiple inheritance?

> Because it's difficult to get right. See my other post.

  We have used multiple inheritance in our project without the
slightest problems. I don't see what's so wrong with it.

  (In fact, we use it in places where the base classes from which you
are multiple-inheriting from act more or less like interfaces. The good
thing is, however, that these "interfaces" can and do have default
implementations for certain things and internally they form their own
inheritance hierarchy, which makes maintaining them easier.)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

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

> Christopher James Huff <cja### [at] earthlinknet> wrote:
> > > Int foo = container.size(); // <- gets a *reference*
> 
> > No, that initializes an Int named foo to the object returned by 
> > container.size. Not a problem.
> 
>   And what if you *do* want a reference to the member variable?
> You can't?

No...then you declare a reference to it. For example, Sapphire has two 
forms of the syntax for declaring variables:

def foo: bar; //declares foo as a reference to bar

def foo = bar; //declares foo as a reference to a copy of bar


> > You could also introduce const references...not sure if its worth the 
> > trouble.
> 
>   I think they are useful, as I mentioned above.
>   Don't know what would be a practical syntax, though.

And it does complicate the language. Remember that this is a scene 
description language...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> >   And what if you *do* want a reference to the member variable?
> > You can't?

> No...then you declare a reference to it. For example, Sapphire has two 
> forms of the syntax for declaring variables:

  What if you want to make your class secure so that the user can't
break it?
  This may happen by accident (ie. the user doesn't realize what he
is doing), not necessarily by a malign coder.

> And it does complicate the language. Remember that this is a scene 
> description language...

  That doesn't mean it shouldn't be made secure.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

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

> > No...then you declare a reference to it. For example, Sapphire has two 
> > forms of the syntax for declaring variables:
> 
>   What if you want to make your class secure so that the user can't
> break it?
>   This may happen by accident (ie. the user doesn't realize what he
> is doing), not necessarily by a malign coder.

Then don't return a direct reference. You could return a proxy that 
doesn't implement modification operations, but otherwise behaves like 
the object referred to. You get the benefits of returning a member 
without a long copy operation, and that member is still protected from 
modification. Of course, this is basically doing what language-level 
constant references would do, and isn't much simpler...


> > And it does complicate the language. Remember that this is a scene 
> > description language...
> 
>   That doesn't mean it shouldn't be made secure.

It does mean it should be made as simple as feasible. Lack of constants 
hasn't done much harm in POV-Ray.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

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

> > I never said anything about two class types...I have no idea how you're 
> > reading what I'm trying to say. 
> 
>   I can't see interfaces as anything else than very limited classes.

Because you're stuck in thinking about things in terms of C++...I think 
it'd help you to learn a few more object-oriented languages.


>   For example, in Java I see two types of classes: The regular ones
> and the extremely limited ones which they call "interfaces".
>   What I wonder is why have two types of classes like this when just
> one type suffices? IMO interfaces cause more problems than they avoid.

Like? And don't say anything about the lack of default implementations, 
that's Java-specific. I'm talking about the concept of interfaces in 
general. I see it as being much like structured programming...rather 
than one construct that can do anything with complex enough code, you 
have restricted constructs that do specific jobs. It makes the intent of 
the code clearer, and makes the language easier to learn and understand, 
IMO at least. I also think languages should make more use of delegation 
and composition...


>   Can you present a good example?

At the moment, no. Nothing other than diamond inheritance, anyway. I'll 
try to get a good example...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <403a9f16$1@news.povray.org> , Darren New <dne### [at] sanrrcom>  
wrote:

> If you're asking "Why do X?" when you really mean to say "I
> don't think X should be necessary", you should phrase it differently.

You should learn when to interpret as question as a rhetorical question.
usually a good hint to interpret a question this way is when the person
continues to give an answer to it.

    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

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   So because the makers of the compiler are lazy they force the
> > user of the language to make bad code?

> Correctamundo! Welcome to commercial programming!

  If I'm not completely mistaken this thread was about what would be
useful features and what would be unnecessary features for a theoretical
future OO scripting language for POV-Ray.
  Last time I checked POV-Ray was not commercial and the developers didn't
have really tight deadlines.

> >   C++ does multiple inheritance quite efficiently, and even if it didn't,
> > why should it matter? You just need to know how heavy multiple inheritance
> > is and then decide whether to use it or not in your application.

> Spoken like someone who writes all his own code without using someone 
> else's libraries. Very good. :-)

  I do use someone else's libraries a lot. For instance, I use the STL
libraries in almost every single C++ program I make. I do know most of
the advantages and disadvantages (including bottlenecks) in them.

> >   One could argue that virtual functions are inefficient because they
> > produce internally an indirect function call (subroutine call to an
> > address got from behind a pointer got from behind a pointer), which
> > potentially make them slightly slower than regular function calls.

> Of course, that assumes the compiler's too stupid to turn this into a 
> direct call in the case that there's no actual dynamic dispatch in the 
> program. Same kind of thing. Lazy compiler writers. ;-)

  If a member function has been declared virtual in C++, there's no way
the compiler can know at compile time there will be no more than one
derived class implementing that function. It can't even theoretically
check this at linking time because some code in a dynamic library (which
may change in the future) may implement that virtual function.

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

Christopher James Huff <cja### [at] earthlinknet> wrote:
> >   I can't see interfaces as anything else than very limited classes.

> Because you're stuck in thinking about things in terms of C++...I think 
> it'd help you to learn a few more object-oriented languages.

  Actually I was thinking in terms of Java. My comment was in no way
related to C++.

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

Darren New <dne### [at] sanrrcom> wrote:
> You asked why one would forbid multiple inheritance. The ones doing the 
> forbidding are the compiler writers. Hence, the answer is from a 
> compiler-writer's point of view. Compiler-writers don't *use* multiple 
> inheritance. They *implement* it.

  That's exactly my point.
  The fact that implementing multiple inheritance in a compiler is
laborious shouldn't be a good-enough reason for depriving the user of
the compiler from the possibility of using multiple-inheritance for
something useful.
  It's a bit like "sorry, I don't know how to implement function calls
in my compiler, so you'll just have to make your code without function
calls". Not acceptable. :)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> Of course, this is basically doing what language-level 
> constant references would do, and isn't much simpler...

  Exactly my point. :)

> >   That doesn't mean it shouldn't be made secure.

> It does mean it should be made as simple as feasible. Lack of constants 
> hasn't done much harm in POV-Ray.

  This is because you can pass things by value and because there isn't
really any modules with a state (which you could break by accident).
But as soon as you introduce modules (which work like libraries) you
need some security features to avoid the user breaking their functionality
by accident.

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

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   If I'm not completely mistaken this thread was about what would be
> > useful features and what would be unnecessary features for a theoretical
> > future OO scripting language for POV-Ray.

> Yet, just 2 posts up, you said
> >   For example, in Java I see two types of classes: The regular ones
> > and the extremely limited ones which they call "interfaces".
> >   What I wonder is why have two types of classes like this when just
> > one type suffices? IMO interfaces cause more problems than they avoid.

> You need to learn to stay on topic. ;-)

  I don't understand where I went off-topic.

  I said that I don't like Java interfaces and I don't understand why
there needs to be any. So IMO this new scripting language doesn't need
any interfaces á la Java.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

In article <4032b303$1@news.povray.org>,
 Tom Melly <pov### [at] tomandlucouk> wrote:

> IMHO this comes down to 'pov ain't oo' - I don't think anyone denies 
> that oo capabilities in pov wouldn't be at the very least interesting, 
> but that's not the issue....

Now, what was that you were saying anyway? I never figured out if you 
thought OO capabilities were interesting or not...though this thread 
makes it clear that at least some people consider them to be of great 
interest. It's almost at the 200 message mark...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

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

>   Actually I was thinking in terms of Java. My comment was in no way
> related to C++.

I meant that you're looking at Java in terms of C++, by considering 
interfaces to be multiply-inherited, limited classes.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

On Sun, 22 Feb 2004 01:11:47 -0800, Tek wrote:

(Just a hint: start a new thread "Cast operators are evil" and I'll
agree at once)

>My point is that a+b takes a different length of time according to the types of
>a and b, where as MyMatrixAddFunction(a,b) takes the same length of time always,

I don't know what you want to state above. I think everybody will
agree that adding two matrices will take more time than adding two
integers. An operator adding two matrices takes the same time as your
MyMatrixAddFunction() function.
 
>plus you can search for it to see where it's executed in the code,

Ok, this might by an advantage.

>plus you can
>stick a nice big comment on the prototype of it saying "//avoid calling this
>unless really necessary, it's very slow" so that anyone who doesn't know how to
>add these two things has to look up the function prototype and read the comment
>and reconsider the code they're writing.

If someone is new to the project (as he doesn't know how to add 'these
two things') you have to train him anyway.
Using appropriate operators is IMHO more intuitive (and as fast as
your My...Function() above).

>I'm not trying to suggest the source looks nicer with more function calls, it
>certainly doesn't. I'd even say I like operator overloading a lot, it's
>extremely useful in high-level programming applications. I'm merely saying that,
>in practice, it makes it easier to write code that is much more complex to
>execute than it is to read or write. This is both it's strongest and weakest
>point.

I don't get the point. All that I know if I see 'My...Function(a, b)'
in the code is "Either a or b, or both of them are not simple types",
it doesn't give me any hint/warning about it's complexity.

>> The macros required to do trivial colour/vector arithmetic are
>> 'information hiding' in the worst sense. They blow up source code and
>> add visual noise which makes it sometimes almost impossible to see
>> what's going on.

>As I said, I support using + for vectors since that's what it will compile to.
>Although I don't really see your point about visual noise, function calls

Think of the core steps of an algorithm as signal, the code you
write/read as noise.

>certainly make it harder to write clearly readable code but since it's harder
>all it takes is more effort.

Yes. Harder to write it once, *and*
- harder to read always,
- harder to find bugs,
- easier to hide bugs,...

>Programming isn't about making things easier for
>the programmer, it's about making the end result better. In application software
>or high level programming these two ideas are very compatible, but in time
>critical stuff like game engines people like me have to give ourselves headaches
>trying to optimize out one cycle in a render loop in order to improve the
>performance of the game. Operator overloading hinders us in this quest.

>Damn that made me sound so cool...

:-)

-- 
Andreas

Post a reply to this message

On Sun, 22 Feb 2004 12:33:36 -0500, Christopher James Huff wrote:

>In article <n8ag309hemfhpmj8jnt5j5s3k8gr66rm62@4ax.com>,
> Andreas Kaiser <aka### [at] nurfuerspamde> wrote:
>
>> This might be a 'learning' problem if you aren't aware of the
>> operators 'hidden' complexity. 
>
>Only if the code is poorly designed. You shouldn't have to care about 
>the hidden complexity. It doesn't matter one bit how the = operator 
>copies a string, only that it does so.

This was meant from a newbie's point of view where 'a *= b' might
appear to be faster than a call to 'MyMatrixMultiplyMatrixEq(a, b)'.

>> >So do functions.
>> 
>> Yes, same problem here. There's no correlation between length of
>> function name and complexity. 

Oh, I see, I forgot the smiley.
Please read it as "... 'problem' ...".

>It's not a problem. It's a feature. Code written without functions is 
>called spaghetti code, it ain't pretty and it is very inefficient and 
>unmaintainable. Or should functions that do more have longer names?

This is what I wanted to point out.

> How long should POV-Ray's main() function be?

As short as possible.

-- 
Andreas

Post a reply to this message

Christopher James Huff wrote:

> though this thread
> makes it clear that at least some people consider them to be of great
> interest. It's almost at the 200 message mark...

I am still unconvinced that the greater majority will be served by the
addition of OO capabilities. I see a handful of dedicated programmers
in this discussion discussing what makes a program OO compliant but the
average joe-blow POV-Ray user is conspicuously absent in this discussion.

How much program bloat will it add and how many people will be served by
it? If it's just to provide a new toy, for a few dedicated programming
enthusiasts, rather than to act as a significant improvement for the
mainstream user, I don't think it is worth the effort.

-- 
Ken Tyler

Post a reply to this message

In article <403C146F.38604E10@tag.povray.org>,
 Ken <ken### [at] tagpovrayorg> wrote:

> How much program bloat will it add and how many people will be served by
> it? If it's just to provide a new toy, for a few dedicated programming
> enthusiasts, rather than to act as a significant improvement for the
> mainstream user, I don't think it is worth the effort.

Honestly, it won't add much bloat. And everyone who uses POV will be 
served by it, even if they don't use the features directly. It would 
make it easier for the programmer types to create extensions for POV 
(lens flares, for example), and make those extensions easier to use.

About the bloat issue: actually, it would be a good idea to replace the 
parser completely rather than trying to wedge OO features into this one, 
in which case the result could be much faster and more efficient than 
the present parser. And remember that non-programmers do use the work 
that programming enthusiasts create. The main point of object 
orientation is to make it possible to have a simple way to use complex 
things, without caring about the guts.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Okay, you obviously don't understand my point, so I'll try to come at it from a
different angle:

I'm sure you would agree there are some applications for which assembler is
better suited than smalltalk, right?

One is basically the lowest level of coding, the other is more or less the
highest.

But, most people don't use either! That's because both extremes have problems
caused by being too low level, or too high level.

All that I'm saying is that in my experience the games industry likes to be at a
slightly lower level than C++. Overloaded operators are one of the things we
prefer to do in the low-level way rather than the high-level way.

Obviously it compiles to the same code but so do all high level languages, it
all ends up as assembler in the end. It's just a question of what level you wish
to think & code at.

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

I heard Ken saying "average joe-blow" wasn't participating in this long
discussion, so I'm here.

"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-01630D.22313524022004@news.povray.org...
> make it easier for the programmer types to create extensions for POV
> (lens flares, for example), and make those extensions easier to use.

I guess it could be, if I followed any of this talk at all.

> in which case the result could be much faster and more efficient than
> the present parser. And remember that non-programmers do use the work
> that programming enthusiasts create. The main point of object
> orientation is to make it possible to have a simple way to use complex
> things, without caring about the guts.

Simple can be good, but... What I'm imagining happening is that a simple
sphere might look like:

ThisSphere.sphere {<1,2,3>,1}

And continued usage (adding a color for example):

ThisSphere.color {<0.1,0.2,0.3,1,0>}

Where MySphere remains defined but gets additional info attached to it. Or
all at once:

ThisSphere.sphere.color {<1,2,3>,1,<0.1,0.2,0.3,1,0>}

Then raytraced when only the name stands alone:

ThisSphere

And so it's difficult to think of doing this for evermore complicated
things. Am I on the wrong track to believe this way? Such as, perhaps, Ken
has too? Apologies if I've gone astray but I had to reread much of this
thread again and i still am unsure of the potential OO-like SDL has, good or
bad.

Bob H.

Post a reply to this message

Tek <tek### [at] evilsuperbraincom> wrote:
> My point is that a+b takes a different length of time according to the types of
> a and b, where as MyMatrixAddFunction(a,b) takes the same length of time always,

  I would like to see a MyMatrixAddFunction() which adds two matrices
together and which takes the same length of time independently of how
big the matrices given as parameters are.
  That's a big like claiming that std::sort() always takes the same length
of time (even if you use it only with one type of parameters).

  Besides, it's not 100% sure that a function called "MyMatrixAddFunction()"
will always take the same amount of time because you can overload that
function name to do something else with some other types (in the exact
same way you can overload operators to do that).

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

Ken <ken### [at] tagpovrayorg> wrote:
> I am still unconvinced that the greater majority will be served by the
> addition of OO capabilities.

  They will.

  Learning to program OO programs is not the only way of benefiting from it.
It's obvious that if POV-Ray had a full-featured object-oriented scripting
language, only a few percentage of POV-Ray users would learn to use it at
its full strength.
  However, that doesn't mean only this small percentage will benefit from it.

  Having a good, full-featured OO language means that those hc programmers
can make better libraries which are more powerful and very easy to use.
If designed correctly, everyone can use these libraries without much
effort or learning, thus indirectly benefiting from the power of the
language.

  Think of it like this: You don't need to know how your fully graphical
operating system works internally: The hc programmers which made that OS
have already figured out the difficult parts for you and made a simple
user interface for you to benefit from these properties. Even though
you may not know how to program hardware and other types of low-level
things, you still are indirectly benefiting from it because someone else
made an easy-to-use interface to use it.
  However, these few hc programmers need the tools to make their programs.
If they don't have the tools, then everyone is on their own.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

In article <403c3ec3$1@news.povray.org>,
 "Hughes, B." <omn### [at] charternet> wrote:

> > make it easier for the programmer types to create extensions for POV
> > (lens flares, for example), and make those extensions easier to use.
> 
> I guess it could be, if I followed any of this talk at all.

For example, being able to make a lens flare object that you can 
translate around, put in a CSG, etc.


> Simple can be good, but... What I'm imagining happening is that a simple
> sphere might look like:
> 
> ThisSphere.sphere {<1,2,3>,1}

That wouldn't be any syntax I recognize. It could easily end up looking 
like:
def ThisSphere = sphere {<1,2,3>,1}


> And continued usage (adding a color for example):
> 
> ThisSphere.color {<0.1,0.2,0.3,1,0>}

ThisSphere.pigment.color = <0.1,0.2,0.3,1,0>;


> Where MySphere remains defined but gets additional info attached to it. Or
> all at once:
> 
> ThisSphere.sphere.color {<1,2,3>,1,<0.1,0.2,0.3,1,0>}

def ThisSphere = sphere {<1,2,3>, 1 pigment {<0.1,0.2,0.3,1,0>}}

The dot syntax is just about always used for accessing parts of an 
object, not for creating one. Like vector .x, .y, .z, or color .red, 
.green, etc.


> Then raytraced when only the name stands alone:
> 
> ThisSphere

There's several ways adding the object to the scene could be handled, 
this is one way.


> And so it's difficult to think of doing this for evermore complicated
> things. Am I on the wrong track to believe this way?

Yes. You're assuming you would have to do everything in a much more 
complex fashion, this is not the case. The final result could be very 
similar to the current POV language in general use.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <06nn30d5mm6n9obft2tquhgr82le6s4jok@4ax.com>,
 Andreas Kaiser <aka### [at] nurfuerspamde> wrote:

> This was meant from a newbie's point of view where 'a *= b' might
> appear to be faster than a call to 'MyMatrixMultiplyMatrixEq(a, b)'.

And I've seen people ask if functions and variables with longer names 
were slower to access (in C++), I've even seen code with shortened names 
to maximize speed...but this kind of newbie misconception shouldn't last 
long, and is no argument against operator overloading.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

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

> > Of course, that assumes the compiler's too stupid to turn this into a 
> > direct call in the case that there's no actual dynamic dispatch in the 
> > program. Same kind of thing. Lazy compiler writers. ;-)
> 
>   If a member function has been declared virtual in C++, there's no way
> the compiler can know at compile time there will be no more than one
> derived class implementing that function.

However, there are cases where the compiler can figure out which 
inherited implementation is desired and turn a member function call into 
a static call, or even inline it. Pretty much whenever the exact type of 
the object being referred to is known.


> It can't even theoretically
> check this at linking time because some code in a dynamic library (which
> may change in the future) may implement that virtual function.

C++ doesn't play particularly well with dynamic linking. C++ RTTI and 
virtual functions can cause many problems with it.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

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

>   I don't understand where I went off-topic.
> 
>   I said that I don't like Java interfaces and I don't understand why
> there needs to be any. So IMO this new scripting language doesn't need
> any interfaces á la Java.

And that's where you keep going off topic. We're not talking about Java 
interfaces, we're talking about interfaces.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-625719.08263725022004@news.povray.org...
> In article <403c3ec3$1@news.povray.org>,
>  "Hughes, B." <omn### [at] charternet> wrote:
>
> > Where MySphere remains defined but gets additional info attached to it.
Or
> > all at once:
> >
> > ThisSphere.sphere.color {<1,2,3>,1,<0.1,0.2,0.3,1,0>}
>
> def ThisSphere = sphere {<1,2,3>, 1 pigment {<0.1,0.2,0.3,1,0>}}
>
> The dot syntax is just about always used for accessing parts of an
> object, not for creating one. Like vector .x, .y, .z, or color .red,
> .green, etc.

Ahh yes, thanks for that clarification. I suspected as much but it was
looking to me like everything was to be built in the same way as accessing
it later.

> > Then raytraced when only the name stands alone:
> >
> > ThisSphere
>
> There's several ways adding the object to the scene could be handled,
> this is one way.

I like not having to use object {ThisSphere}, so this is a good thing I
think. Minimized scripting in the same vein as not needing parent wrappers,
which I believe you actually mentioned back in the thread someplace, could
be nice. Maybe not clear until learning what's what, but easier to write.

> > And so it's difficult to think of doing this for evermore complicated
> > things. Am I on the wrong track to believe this way?
>
> Yes. You're assuming you would have to do everything in a much more
> complex fashion, this is not the case. The final result could be very
> similar to the current POV language in general use.

Okay. But, admittedly, it would still become more code-like for the writers
of it. Yet, presumably, easier to use the result. Regardless, I think all
this will come down to a widened dividing line between casual artists and
data-crunchers. Since no one knows the future for certain it could go either
way, good or bad thing. Maybe no worse than other changes had been. Hmmm...
That's a statement not to be taken too lightly. The halo, semicolons,
patterns... sounds ultra mild compared to most of the talk in this thread.
;-)

Bob H.

Post a reply to this message