POV-Ray : Newsgroups : povray.off-topic : Games programmers : Re: Games programmers Server Time
10 Oct 2024 11:18:42 EDT (-0400)
  Re: Games programmers  
From: Warp
Date: 11 Sep 2008 16:03:07
Message: <48c9797b@news.povray.org>
Orchid XP v8 <voi### [at] devnull> wrote:
> Anyway, according to this book, by default all class methods have static 
> binding. If you want real OO-style dynamic binding, that's an extra 
> feature that you have to remember to turn on. (Presumably because it 
> incurs a small performance hit, and C++ is targetted at speed, not 
> flexibility.)

  The basic design principle in C++ is that you don't have to pay for
what you don't use.

  If C++ classes were always dynamically bound (like eg. Java classes are),
then each instance of each class would have a size overhead of one pointer,
and every function call would have a double indirection (making it very hard
for the compiler to perform inlining and other optimizations).

  This means that if you had, for example, a pixel class which has nothing
else than 4 bytes inside it (for rgba), its size would actually be 8 bytes
(or 12 in 64-bit systems, which would be even worse), even if you didn't
use dynamic binding for anything, and everything you cared about with your
pixel class is optimal memory usage and speed. Also all the functions of
that pixel class would be double indirections.

  C++ supports dynamic binding if you need it, but it's not shoved down
your throat by force.

> This also suggests that if somebody else wrote some code and you only 
> have a binary copy, and they decided to not make some method 
> overridable... too bad. (But then, frankly, trying to extend classes 
> that somebody else wrote is usually pretty hard in any OO language.)

  Nowadays object-oriented features such as dynamic binding are falling
out of fashion, and they are less and less popular. In this way C++ actually
got to the winning side by turning it off by default.

> >> Templates?
> > 
> >   One of the coolest, most powerful and most useful things around.

> And also one of the hardest parts to learn, no doubt.

  What's so hard to learn about them? Usually the only difference is
that theres one or more type which are abstracted away, and that's it.
For example, rather than writing:

int foo(int parameter) { ... }

where the type of the parameter and the return value is fixed to int,
you abstract them away like this:

template<typename Data_t>
Data_t foo(Data_t parameter) { ... }

  Now you can call that function with ints, longs, doubles, chars...

  Sure, when you start developing really complicated template code, you
can get quite obfuscated templates, but that's usually more the exception
than the rule.
  The most complicated template sentence I have written in actual code
has been this:

typename Allocator::template rebind<size_t>::other(*this).deallocate(refCount, 1);

  It would probably take half a book to explain everything that is involved
there. :P
  However, you don't usually have to write code like that when you are
making regular programs.

> >> Untrapped numeric overflows?
> > 
> >   You want the compiler to automatically insert a conditional after each
> > single arithmetic operation you perform? Maybe you should use some other
> > language.

> The "maybe you should use some other language" part pretty much hits the 
> mark, IMHO.

  Sometimes you have to use what the industry demands, not what you would
like to use. Besides, it's not that bad.

> The long and short of it is that C++ is designed to be used by experts, 
> and if you're not one, the langauge will make no attempt to prevent you 
> hurting yourself. Now I don't know about you, but when *I* code things, 
> I make mistakes. And I appreciate having systems in place to help me 
> find and fix those mistakes.

  I don't like that when it's shoved down your throat whether you want
it or not, at the expense of, among other things, memory usage efficiency
and speed.

  Yes, debug checks are nice. They are nicer if you can turn them off
for a final release.

-- 
                                                          - Warp


Post a reply to this message

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