 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <403a9f16$1@news.povray.org> , Darren New <dne### [at] san rrcom>
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
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
