 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
|
|
