 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trf de> 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
|
|
| |
| |
|
|
|
|
| |
|
|
