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

In article <3fdf63e3@news.povray.org> , Nicolas Calimet <pov### [at] freefr>
wrote:

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

The C++ streams tend to be slow due to practically all libraries
implementing them in the simplest, not fastest manner.  Practically they
just put a layer on top of C streams, wrap it yet again, then they pull in
more locale and half of the rest of STL and easily you get a huge program if
you just use something as trivial as even a simple cout <sigh>

Guides have been written how to make C++ streams fast, but I don't think any
big STL or compiler vendor has implemented all of them yet.

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

The STL string, if implemented well, is extremely fast, especially if you
deal with dynamic string length and need to copy strings around.  In fact,
the strings are usually one of the best optimised things in current STL
library implementations...

>>   (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  ;-)

It really depends.  Taker a look at povdocgen (in Perforce).  You will
notice that is reads and writes data very quickly, and it uses only STL
strings.  It really is only so "slow" processing everything because of the
massive applying of regular expressions.  The most important thing is that
STL strings make use of strings almost trivial just like it is in most
higher level languages (i.e. modern Basic variants).

    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

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

	Ooops, sorry, here I was refering to STRINGS, not streams...

> The STL string, if implemented well, is extremely fast, especially if you
> deal with dynamic string length and need to copy strings around.  In fact,
> the strings are usually one of the best optimised things in current STL
> library implementations...

	Indeed those dynamic strings are what I'm interested in.  So I should
have a look at the STL then...  Still don't see how they could be faster than
some equivalent functionality in a good implementation of the C library on the
same architecture.  Maybe thanks to faster, dedicated memory management ?

	- NC

Post a reply to this message