POV-Ray : Newsgroups : povray.advanced-users : Object Oriented POV code : Re: Object Oriented POV code Server Time
29 Jul 2024 16:32:35 EDT (-0400)
  Re: Object Oriented POV code  
From: Warp
Date: 22 Feb 2004 06:07:31
Message: <40388d73@news.povray.org>
Tek <tek### [at] evilsuperbraincom> wrote:
> i.e. when you compile a+b, you expect it to compile to a simple add instruction,
> and these days most processors can do vector maths so I'd certainly support it
> being used for them. The problem is if you've defined your own type of data that
> has a "+" function, you incur the cost of a function call invisibly in your
> code. This is a very bad thing for time-critical applications like computer
> games. Things like this make optimising an absolute nightmare.

  This may have been true 10 years ago.

  Current compilers can usually optimize the overhead (eg. the function
call) away completely (supposing the operator function is inline).
If you make a class which uses operator overloading for simple tasks
(such as adding two internal values together) you should definitely
make them inline, after which the compiler will be able to optimize
all the overhead away.

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

class MyInt
{
    int value;

 public:
    MyInt(int init=0): value(init) {}

    int operator+(const MyInt& rhs) const { return value+rhs.value; }
};

  Now if you do something like this:

MyInt a=1, b=2, c;
c = a+b;

I would be very surprised if the code generated by a modern compiler
would be any different from the code which it would generate if you
replace the MyInt class with:

typedef int MyInt;


  PS. In fact, I just tested this with gcc. I added the following
method to the MyInt class for easier usage:

    operator int() { return value; }

and then made a code like this:

int foo()
{   
    MyInt a=1, b=2, c;
    c = a+b;
    return c;
}

  Using the MyInt class or typedeffing MyInt to int resulted in identical
assembler code (when using optimizations):

.LLFB3:
        !#PROLOGUE# 0
        !#PROLOGUE# 1
        retl
        mov     3, %o0

  This is sparc asm, and if we "translate" it back to C++ it means
the same thing as:

int foo()
{
    return 3;
}

  So using a class with operator overloading did not ask any overhead
*at all* to the code.

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

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