POV-Ray : Newsgroups : povray.advanced-users : Object Oriented POV code : Re: Object Oriented POV code Server Time
29 Jul 2024 16:28:41 EDT (-0400)
  Re: Object Oriented POV code  
From: Warp
Date: 22 Feb 2004 07:15:07
Message: <40389d4b@news.povray.org>
Tek <tek### [at] evilsuperbraincom> wrote:
> Well, it can lose the function call overhead, but not the overhead of it being a
> function (i.e. several instructions) rather than a simple instruction (which is
> really my point).

  The only alternative to operator overloading is to use a member function.
So how is that any different?

> >   For example, suppose you have this (in C++):

> Aha! but you'd never define an object for a type inherently supported by the
> compiler, only for types which require something more complex. So you end up
> with "+" becoming different amounts of compiled code depending on the context in
> which it's used. This makes it harder to optimise code, since it is harder to
> keep track of where the more complex + functions are being invoked.

  You missed my point completely.

  I just gave a simple example and wanted to point out that using operator
overloading does not add any overhead whatsoever to regular function calls.
  If you want to make, for example, a rational number type (which contains
two integers), then it doesn't matter if you use it with operators or with
regular member function calls: Using operators is not any slower.

> Plus when someone is writing the code if they have to call
> PerformReallySlowAndComplicatedAddition( a, b ) rather than a+b it tends to make
> people more aware of what they're doing.

  So you are saying that even if the addition would be extremely fast you
still should not use operator overloading? Why?

  Using operators makes the code cleaner and easier to read with complex
expressions.
  (This is IMHO a true problem in Java. You can't make in Java things like
"a = b + c*(d*c-e);" with your own defined type.)

> Operator overloading is great if you want to code at a higher level without
> being bogged down by thinking about what's happening at the lowest level, but
> when optimising code you want to do the opposite! Heck, if were even remotely
> feasible we'd write everything in assembler...

  If you don't know what operator+() does with the type you are using,
then you should seek another job, IMHO.
  If you are making speed-critical code then you should know your tools.

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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.