POV-Ray : Newsgroups : povray.advanced-users : Object Oriented POV code : Re: Object Oriented POV code Server Time
29 Jul 2024 18:24:45 EDT (-0400)
  Re: Object Oriented POV code  
From: Tek
Date: 22 Feb 2004 08:29:10
Message: <4038aea6$1@news.povray.org>
> > Anyway, my point isn't just the function call overhead, it's the fact that
> > it's not an operator internally supported by the compiler with a bunch of
> > rules, it's a series of instructions of unspecified length elsewhere.
>
> There is no such difference.

Okay, remove the word "elsewhere" and you might see what I mean.

> > 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).
>
> No, there won't be additional instructions if a function is inlined.  For
> any (not ten year old) compiler the overhead of inlining a function will be
> exactly zero compared to direct insertion of the code.

ffs, I know that! I know what inline does! I'm talking with the premise that you
won't write a function to do something you can already do in one line of code.

i.e. if anyone, anywhere, ever writes a function:
add(a,b)
{
    return a+b;
}

that person should be dragged out into the street and shot*. So, ON THAT
PREMISE, if you have decided to write an inline function there will be an
"overhead of it being a function (i.e. several instructions) rather than a
simple instruction", by which I mean you have decided to write a function that
is more than one instruction.

I just explained that *really* badly yet again...

What I'm saying is, quite simply, we like to make a distinction between "+" and
any more elaborate function. Because doing so prevents people writing lines like
a = b + 3*(c-d), which looks perfectly innocent, but could be a major
bottleneck.


I'm not saying overload operators are a bad thing, I'm just presenting the
reasons why we don't generally use them in game coding. I think for simple types
which are well suited to the compiler you could define some more (like vectors),
but I'd still make a distinction between that and a significantly greater amount
of processing.

We like the clunkier syntax *because* it is harder to use and requires more
thought from the programmer. In our situation this is a good thing.

-- 
Tek
www.evilsuperbrain.com

*I bet someone's now going to come up with a perfectly good reason why they
might do this, but it's 5:20am and I can't think of one!


Post a reply to this message

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