In article <3fdbba25$1@news.povray.org> , Severi Salminen 
<sev### [at] NOT_THISsibafi>  wrote:

>> I outlined the answers to your questions in the second half of the last
>> paragraph of my message.
>
> Indeed, I hadn't read that. You wrote: "a fast, lean and extraordinary
> stable piece of software". But doesn't Pov-Ray allready meet these
> goals? Or is this simply about it being _easier_ to achieve those goals
> with C++ than with C? (My knowledge of C++ is _very_ limited). Just curious.

The code could be much shorter in many places if everything wouldn't be done
the "manual" way in good old C style.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3fdbce98@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Some books really help. For instance "Effective C++" and "More Effective
> C++"... :P
>   (Of course these books are aimed to those who already have experience
> about C++ and want to learn more.)

Well, these book are extremely dated.  After all it appeared back in 1995.
I have not seen the second edition of the first book yet.  Anyway, just
consider Item 5 in the first book.  The final language specification
actually says it is undefined behavior to call the wrong delete (but few
compilers manage to warn when this happens, also in most cases they could).
Or item 3 in the second book - you don't have problems if you use STL rather
than self-cooked arrays.  Or consider item 13 in the second book.  This is
again more an advice for language beginners, everybody even a tiny bit
experienced should really know.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Sun, 14 Dec 2003 12:51:38 +0100, Pascal <net### [at] freesurffr> wrote:

Um, geez ever heard of smart pointers like auto_ptr ?

> Unfortunately, after a while, even the best designed C++ program, if
> sufficiently large and complex,  will turn into an ugly,
> crash prone, unmaintainable corruption factory maze of lines of code,
> because it is SO easy to go this route
> (with operator overloading, multiple inheritance and pointers as the main
> tools)
>
> --
> Pascal.
>
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Post a reply to this message

Thorsten Froehlich wrote:

> In article <3fd9c437@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:
> 
> It also turns out that no matter what you do, a Java program will always
> be a fat, slow thing that tends to misbehave and corrupt your data rather
> than
> just crash and leave your data alone.  C++, on the other hand, if, and
> only if, used properly, will result in a fast, lean and extraordinary
> stable piece of software.
> 
I just have to emphasize the statement "if and only if used properly". 
Usind RTTI and exceptions, it is easy to get a really fat (as of binary 
size) and slow program much faster than you think. 

For something like a raytracer, I personally think one should stay away 
from exceptions and RTTI unless it is _really_ needed. 

Just my 2 cents
...after many years of C(++) coding

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:

> Anybody who still uses raw pointers in C++ deserves to be shot!
> 
If you mean "raw pointer" = "void pointer", then I completely agree. 

Otherwise, I strongly object. 
(Because you then probably would have to shoot me -- with several 
automatic guns in parallel :p)

Pointers are the most useful thing in C and you cannot get around 
them in C++ if you want to keep fast performance. 
All that guided stuff I've heared yet is both slow & fat. 

Or do you see an alternative?

Wolfgang

Post a reply to this message

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.
  Using 'new' outside an abstract type is usually a bad idea. Honestly.

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

George Pantazopoulos <george@gamma*killspam*burst.net> wrote:
> Um, geez ever heard of smart pointers like auto_ptr ?

  I have never needed smart pointers, yet in the last 5 years I don't
remember how many memory leaks I have had in my programs, but it's quite
close to 0.
  I don't really understand what smart pointers are useful for. In my
opinion if you need to use a smart pointer, there's a flaw in your
design.
  Abstract the pointer directly to the data container type you want
to use it for. It's cleaner that way.

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

In article <3fdcbcc2@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> I just have to emphasize the statement "if and only if used properly".
> Usind RTTI and exceptions, it is easy to get a really fat (as of binary
> size) and slow program much faster than you think.

No, not at all!  RTTI is something you get for no runtime cost at all and
the data size it adds is in the range of a few dozen bytes per class.  If
you can get exceptions for free depends a tiny bit on the architecture used,
but in general the answer is yes as well.  In particular, if you don't throw
any exceptions inside a function, exceptions will not cost anything.

The frequently found warning that RTTI and exceptions make programs slow is
due to very early C++ compilers (we are talking about ten years old or more)
did not implement these features efficently.  This is not the case for *any*
recent compiler released in the past few years.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3fdcbe02@news.povray.org> , 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.
> All that guided stuff I've heared yet is both slow & fat.

I don't know which implementation you are refering to, but neither the two
leading compilers for Windows nor the two leading compilers for Mac OS have
such a problem.  In fact, it is really hard to make auto_ptr use slow
anywhere if the compiler supports at least the most trivial of
optimisations...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

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