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