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

> If exceptions are slower than normal return, that won't hurt much
> because they are meant to be used as "exceptions". So, for exceptions
> my critisism was the size overhead.
>
> And for RTTI: I cannot imagine that a dynamic_cast has real little
> overhead but I honestly hope that it is the case until I run a test
> in the next days.

Effectively you only need it when using multiple inheritance.  Of course, if
you depend on dynamic_cast heavily, you probably have some serious problem
understanding C++.

> Okay, my observations quoted above were based on my experiences on the
> gcc-2.7.3.2 -> gcc-2.8 transition and may very well be outdated.

One of the slowest known compilers around ... and outdated by half a decade.

> So, RTTI and exceptions still introduce considerable overhead even if
> not used.

Shitty compiler => shitty code!  You should really use professional
compilers to base your comparisons on.  Gcc's main feature is portability,
not performance.

    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

Wolfgang Wieser <wwi### [at] gmxde> wrote:
> 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.) 

  How do using pointers directly alleviate the problem of temporaries
triggering allocation on the heap? I don't understand.

  And constructors and destructors are called when instances are copied.
The most common place to copy an instance is when a function takes such
data container by value.
  Usually you don't make functions which take big data containers by value,
but by reference, so no constructors/destructors are called.

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

  But that's a *static* data type, not a dynamic one. Why would you
want to use a dynamic data container for a table of static size? That's
like shooting flies with a cannon.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Wolfgang Wieser <wwi### [at] gmxde> wrote:
> So, if you need a local variable of just such a type we're talking about, 
> i.e. a class which simply contains a pointer to an internal class, 
> then the class will be allocated on the stack (okay, fast) and the 
> internal class will be allocated using operator new on the heap. 

  I still not understand that if you want a container of static size
why would be use a dynamic container for that.
  Make a container with static size which does not allocate memory and
there you are.

> All that happens when you call the constructor and initialize your 
> class. For the normal use, this is just what you want because when 
> you pass the class to a function, it is quite fast (just increase 
> reference counter). But if the object is simply a local var you want 
> on the stack, then the overhead is considerably. 

  If the default constructor does nothing, then make it inline with an
empty implementation. The compiler will optimize the constructor call
away. Same goes for the destructor.

> Correct. But if your class behaves that way because you're doing reference 
> counting (see above), then there is little you can do against that. 

  Even if you used a dynamic data container, why would reference counting
kick in (unless you are making functions which take big data containers
by value, which is seldom a good idea)?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> You clearly haven't done a lot of GUI programming. 

  That's true.

> If you acquire resources
> from the operating system, it is usually a good idea to keep them in a
> specialised container able to release the resource should i.e. an exception
> occur.  Likewise when it comes to passing data to the operating system.
> Frequently this does require a more low-level work on manually allocated
> memory with new, and then auto_ptr can be really helpful! *

  I would try to abstract whatever resources you are allocating from the OS
behind a class. Everything that is related to that resource would be handled
by that class and the public interface would be very abstract. You simply
tell the object "allocate the resources this way" and the object will
handle the system call, storing the pointer or whatever to the allocated
resource and freeing it when appropriate.
  This is more than a "smart pointer". It's a kind of "smart resource
allocator".

  Using a smart pointer sounds more like making system-dependant calls
in wrong places. Like taking system-dependant code higher than necessary
in the abstraction level. The pointer doesn't know what's behind the
pointer, that's left to higher levels to decide. Personally I don't
like that.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> if
> you depend on dynamic_cast heavily, you probably have some serious problem
> understanding C++.

  Actually it's a symptom of bad OO design (unless you are using
dynamic_cast for something else than downcasting...).

  The only cast which is "legit" is static_cast.
  dynamic_cast is, how would I call it, "half-legit". It's safe and OO-like,
but if you need to use it, there's usually something wrong with your whole
design (not always, though, but usually).

  The other two casts are very "illegit". They are very unsafe and only
needed for hacking things. (They still can be sometimes useful, though,
even though it's usually "dirty" code :P )

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

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

>   Using a smart pointer sounds more like making system-dependant calls
> in wrong places.

Well, if you only target one operating system for one reason or another, you
are usually not concerned about portability at all.  Or, like a task I am
currently dealing with, you don't get pointers back but ids that you even
want to reference in multiple places (OpenGL display lists).  Yet they
belong only to one particular object of a class (the OpenGL context that was
active when they were created).  So, when giving an object encapsulating a
display list to the user (of the OpenGL context object), you have to make
sure when you get them back that they belong to your object at all.

On the other hand, in many cases (like when using OpenGL) you need a rather
low-level interface at a fairly high application level.  The alternative
would be a total abstraction in many cases (i.e. if you want to support
another API like Direct3D), which ends up being a lot of very careful coding
to even only deal with a tiny subset of functionality.

>   I would try to abstract whatever resources you are allocating from the OS
> behind a class.

When dealing with an operating system C interface, sometimes there has to be
a compromise between good abstraction and feasibility.  For example,
supplying Get and Set methods for every possible OpenGL flag and state
variable would quickly result in several thousand member function template
based Get/Set methods - the OpenGL 1.5 API contains over 450 functions
offering access to about 1500 different flags and states!  Not even to
mention the optional feature extensions in OpenGL.  So, unless somebody
wants to implement this and update it for every new OpenGL version, you end
up using less abstraction.  While not in this particular case (you need ids
as outlined above), in many other cases a smart pointer is a really good
alternative to going all the way to a full abstraction layer.  In particular
if you only need certain system functions once.

    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

Thorsten Froehlich <tho### [at] trfde> wrote:
> if you only target one operating system for one reason or another

  In my opinion it's not good to think "I will be making this huge program
for (the current version of) Windows and that's it; I will never want to
port it to any other system and I will trust that newer Windows versions
will support this system call as it is now".
  The day you, for some reason or another, want to port it to another system
(or when a new windows version breaks that system call), you will curse
your decision, specially if you have ten thousands calls scattered all
over the place... ;)

  (Ok, that is a bit extreme, but I still like to encapsulate system-dependent
things as far as it is feasible and makes the code cleaner.)

-- 
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 <3fddcfb2@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   In my opinion it's not good to think "I will be making this huge program
> for (the current version of) Windows and that's it; I will never want to
> port it to any other system

Especially on Windos, but almost equally so on all others systems, there are
so many specific things, trying to abstract them is a true waste of time
unless a *very* small subset of all available functionality is used.  In
short, it is much better to do one thing well than three or four things
badly.

    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

"Mael" <mae### [at] hotmailcom> wrote:

>> I'll try again later on a more recent system
>
>This time I tried on windows (VC++ 6) and same (wrong) results for
>chess2.pov (you can render it without focal blur for faster test)
>I hope this is something easy to track down .. good luck :-/

I'll fix this and include the bbox tree.
This may take some days as i must change from my Notebook to a new PC.

Andreas

Post a reply to this message

>   The sad thing is that sometimes the "C-way" will be slower and less
> efficient than the "C++-way". For instance, compare C and C++ strings.
> (Most operations are much faster in C++, not to talk about C++ strings
> being a lot more secure with regard to memory leaking. C++ strings are
> also a lot easier to use.)

	But in what language the C++ streams are implemented internally ?
Isn't it mostly in C and asm ?  The C libraries usually are too.

	I'm interested in this particular point since my own projects
rely _a lot_ on labelled data (using my own C string "library").  Could you
give an example where C++ strings clearly outperform the equivalent C code
(if anything similar can be done) ?

>   (It's really sad that C++ streams are still slower than C streams in
> most compilers. When will they make an implementation which is at least
> as fast?)

	Ah ! Since I usually write GB of data, it seems that I still have
a good reason to "kiss" C a bit longer  ;-)

	- NC

Post a reply to this message