POV-Ray : Newsgroups : povray.programming : Improved intersection routine for CSG-Intersection objects : Re: Improved intersection routine for CSG-Intersection objects Server Time
6 Oct 2024 15:21:45 EDT (-0400)
  Re: Improved intersection routine for CSG-Intersection objects  
From: Wolfgang Wieser
Date: 14 Dec 2003 17:39:02
Message: <3fdce685@news.povray.org>
Warp wrote:

> Wolfgang Wieser <wwi### [at] gmxde> wrote:
>> Pointers are the most useful thing in C and you cannot get around
>> them in C++ if you want to keep fast performance.
> 
>   In C++ there's less need to use pointers everywhere. For instance, often
> a reference is better than a pointer (a reference is more secure and
> easier to use syntax-wise).
>   And if you are going to use dynamically allocated memory, abstracting
> the pointer is a good idea anyways. For instance most (if not all)
> STL data containers are classes which contain just one member
> variable: A pointer. Which means that these data containers are
> basically a pointer. However, they are 100 times more secure than
> using a pointer directly, 100 times easier to use and in no way less
> efficient.
>
They _are_ less efficient. (Because even temporaries trigger allocatation 
on the heap instead of the fast stack and because the con/destructors 
are called all the time increasing and decreasing reference counters, 
etc.) 

So, my personal opinion is that for complex types the speed penalty
is small compared to the gain in safety (especially when one can 
frequently use references which eliminate the need to call con/destructors). 
But _not_ for real simple types. For "I quickly need a vector", using 
double v[3] is still faster than anything using operator new or 
applying a fancy con/destructor. (One could use a fixed-size template 
in that case, though: MyVect<double,3> v; )

>   Using 'new' outside an abstract type is usually a bad idea. Honestly.
> 
It depends. But in the most cases this is true. 

Wolfgang


Post a reply to this message

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