Warp wrote:

> 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.
> 
Please have a look at the example code in the other posting nearby. 

Wolfgang

Post a reply to this message

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

>>> For inline functions this is true. Not so for extern linkage.
>>
>> You cannot have external linkage for template functions.
>>
> You can. You just have to make sure that a specialisation for the
> used type is linked in extenally.

Well, you still need the whole template source code for the compiler to
work.  So, the code would still be generated locally and the linker may then
indeed decide to throw the local instance of the template functions away and
use the one from the outside, but this will hardly gain you anything but
problems with most compilers.

>> Only if you use containers of many different types!  Modern linkers will
>> eliminate multiple identical template function instances, thus you only
>> see the code bloat in the object files, but not in the final linked
>> program.
>>
> Correct. But all as you normally need to have all template stuff
> inline, this results in a lot of inline code duplication.

No, only the very common bad programming habit of placing template
implementation code inside classes instead outside causes template code to
be inlined (also a compiler is *not* required to inline anything!).

>> But only if there is data.  If properly designed, if there is no data, no
>> memory should be allocated.  Unless you use fixed-size data in C, you will
>> have exactly the same amount of work.  And there is nothing that keeps you
>> from using fixed-size data in C++, except that it is bad style, in both
>> languages.
>>
> I have the feeling that we're not getting the point of what we want
> to tell each other...

Could well be the case.

> Because the C construction does no reference counting. You allocate
> a pointer once and then use it. And the designer knows where it was
> allocated, "who" is responsible for the pointer and its lifetime.
>
> Yes, that's insecure like hell but faster and smaller.

Of course, nothing keeps you from doing this in C++ as well...


> That will (1) allocate some bytes on the stack (fast) and then
> (2) allocate internal object using operator new (slow).
>
> That is what I had in mind.

I almost assumed you did.  However, node that having just a pointer to an
"internal" object is just terrible design, and if you use this to hide
something "private" behind another interface, C++ is not the language you
want to be using!

Second, if you really have a valid need to frequently create temporary
copies of a specific class of objects, you will gain a really lot if you use
a memory pool (i.e. boost::pool for C++).  And of course, you will still
have the same problems when doing something similar in C.

> I still am the opinion that it is pretty hard if not (nearly?) impossible
> to design really fast C++ code (i.e. as fast as insecure C code) when one
> forces itself to stick to all the "good style" guidelines. (Depends on
> what one defines as "good style").

Yet, but you are making two major mistakes in your logic here: Just because
C++ allows you to use more secure programming methods does not imply in any
way that C++ is slow or slower than C.  It simply implies that a
well-programmed piece of code will have a tiny bit of overhead over a fast
hack.  And the languages features for good programming style only exist in
C++ but not C.  Thus you can only use them in C++, while you are stuck with
unstable code in C.

However, this is the case for any higher language level.  You can claim
exactly the same for C and your native assembler.  Of course, if you know
what you are doing you can still outperform even a very good compiler (the
SSE2 noise code in POV-Ray is a good example for this) by using lower level
programming languages, but that doesn't say anything about the higher level
languages!

    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 <3fe1f82f@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

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

Which does an extremely miserable job!  In fact, Qt is just one of the worst
GUI abstraction layers that exist (I am sure that is why it is so popular!).
It does not abstract most of the GUI elements at all, it just draws them on
its own.  Apart from that, Qt is hardly a good example for use of C++.  Its
signal implementation is a perfect example.  As is is non-existent
thread-safety - even if a native API used is fully thread-safe, Qt in
general is not thread-safe.  And its OpenGL widget for Windows is full of
very obvious bugs (also this is only available with the expensive commercial
code license); even M$ sample code shows how to properly create a correct
Z-buffered contexts.

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

> In article <3fe1f82f@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>>> In article <3fddcfb2@news.povray.org> , Warp <war### [at] tagpovrayorg> 
>>> wrote: 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.
>>
>> Have a look at Qt.
> 
> Which does an extremely miserable job!  In fact, Qt is just one of the
> worst GUI abstraction layers that exist (I am sure that is why it is so
> popular!). 
>
Your opinion. There are a lot of people who see that the opposite 
way. 

And if you ever did GUI with Java, you will find Qt like heaven...

> It does not abstract most of the GUI elements at all, it just
> draws them on its own. 
>
Correct. So what?

> Apart from that, Qt is hardly a good example for use of C++. 
>
That's 50% true (max). 

> Its signal implementation is a perfect example. 
>
The signal implementation is indeed a strange thingy. 

> As is is non-existent
> thread-safety - even if a native API used is fully thread-safe, Qt in
> general is not thread-safe. 
>
I cannot comment on that. But I recall that early versions of Ot were 
single threaded. And adding thread support to a single threaded design 
often runs into trouble when system near components are involved. 

> And its OpenGL widget for Windows is full of
> very obvious bugs (also this is only available with the expensive
> commercial code license); even M$ sample code shows how to properly create
> a correct Z-buffered contexts.
> 
Hell, don't use Qt for OpenGL. 
Either you want performance or you want Qt. But a factor of 3..5 in 
GUI performance loss is acceptable in the most cases. (And still much 
better than swing...)

Wolfgang

Post a reply to this message

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

>>> 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.
>>
> Heeee. gcc is by all means no "shitty compiler". But we may try using
> e.g. the intel compiler (it has -fno-rtti but no -fno-exceptions).
>
> Do you know how RTTI internally works? (I.e. in an "non-shitty"
> compiler.)

It is very simple (of course there are other ways to do it).  In essence,
all you need is a single static type_info object for every class.  So, you
create one static instance of such an object (ideally you have the linker
fold multiple instances). Every virtual function table gets a pointer to the
type information. For PODs and structs you know the type at compile-time
anyway. So, all you need it one pointer per class to determine its type,
plus 50 or so bytes (depending on what the name string of type_info returns)
per class (not per object!). And of course, the compiler will only need to
generate this data if type information is required for a particular class.

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

>> Correct. But all as you normally need to have all template stuff
>> inline, this results in a lot of inline code duplication.
> 
> No, only the very common bad programming habit of placing template
> implementation code inside classes instead outside causes template code to
> be inlined (also a compiler is *not* required to inline anything!).
> 
(Yes but good compilers do when told so...)

>> Because the C construction does no reference counting. You allocate
>> a pointer once and then use it. And the designer knows where it was
>> allocated, "who" is responsible for the pointer and its lifetime.
>>
>> Yes, that's insecure like hell but faster and smaller.
> 
> Of course, nothing keeps you from doing this in C++ as well...
> 
We were talking about what is faster... and what safer...

>> That will (1) allocate some bytes on the stack (fast) and then
>> (2) allocate internal object using operator new (slow).
>>
>> That is what I had in mind.
> 
> I almost assumed you did.  However, node that having just a pointer to an
> "internal" object is just terrible design, and if you use this to hide
> something "private" behind another interface, C++ is not the language you
> want to be using!
> 
Ah really?! Have fun reading the STL code :p

> Second, if you really have a valid need to frequently create temporary
> copies of a specific class of objects, you will gain a really lot if you
> use
> a memory pool (i.e. boost::pool for C++). 
>
I tried things like that. Stack allocation is still fastest for 
small amounts of memory. 

> And of course, you will still
> have the same problems when doing something similar in C.
>
One would not use a desing like that in plain C. 
 
>> I still am the opinion that it is pretty hard if not (nearly?) impossible
>> to design really fast C++ code (i.e. as fast as insecure C code) when one
>> forces itself to stick to all the "good style" guidelines. (Depends on
>> what one defines as "good style").
> 
> Yet, but you are making two major mistakes in your logic here: Just
> because C++ allows you to use more secure programming methods does not
> imply in any
> way that C++ is slow or slower than C.  It simply implies that a
> well-programmed piece of code will have a tiny bit of overhead over a fast
> hack. 
>
I was making no mistake in my reasoning. I just wanted to express 
what you stated above in your own words...
No discrepancy there. 

> And the languages features for good programming style only exist in
> C++ but not C.  Thus you can only use them in C++, while you are stuck
> with unstable code in C.
> 
You could implement similar (not-so-safe) things in C. Don't understand 
me wrong: 
I do _not_ propose that, it's just what I extracted from your frequent 
replies stating "you would have the same overhead in C when implementing 
that in C". 

> However, this is the case for any higher language level.  You can claim
> exactly the same for C and your native assembler.  Of course, if you know
> what you are doing you can still outperform even a very good compiler (the
> SSE2 noise code in POV-Ray is a good example for this) by using lower
> level programming languages, but that doesn't say anything about the
> higher level languages!
> 
Correct. Assuming that one could implement the core parts of an 
application in assembler gaining speed increases of factor 2 or above 
it may seem irrelevant to talk about <=5% loss at a C -> C++ transition. 
Especially if there are benifits (better maintainability, etc)

Wolfgang

Post a reply to this message

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

> Well, there is no normally need to zero the pointer in the
> caller function and do all that fancy stuff. A raw pointer or reference
> will do in most cases.

BTW, given you assigned "0" to a pointer, take a look at
<http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1488.pdf>
It has some important news about "0" and "NULL"...

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

>> Do you know how RTTI internally works? (I.e. in an "non-shitty"
>> compiler.)
> 
> It is very simple (of course there are other ways to do it).  In essence,
> all you need is a single static type_info object for every class.  So, you
> create one static instance of such an object (ideally you have the linker
> fold multiple instances). Every virtual function table gets a pointer to
> the type information. For PODs and structs you know the type at
> compile-time anyway. So, all you need it one pointer per class to
> determine its type, plus 50 or so bytes (depending on what the name string
> of type_info returns) per class (not per object!). And of course, the
> compiler will only need to generate this data if type information is
> required for a particular class.
> 
Okay, that explains all the strings one sees in the binary when turning 
on RTTI. It is probably responsible for most of the size overhead when 
using RTTI. 

But what do we need the type name string for? (..in a binary!) 
[Apart from an error message.]

What you did not mention is some sort of tree structure. I'm not 
sure about the details, but isn't there the need for a tree traversal 
to decide if the dynamic_cast is valid? (Think of multiple inheritance...)

Wolfgang

Post a reply to this message

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

>> Which does an extremely miserable job!  In fact, Qt is just one of the
>> worst GUI abstraction layers that exist (I am sure that is why it is so
>> popular!).
>>
> Your opinion. There are a lot of people who see that the opposite
> way.

Many people also like Windows, apparently ;-)

> And if you ever did GUI with Java, you will find Qt like heaven...

I wrote a tiny program in Java once, and it didn't even have a GUI.  Since
that day, programming in Java is something I will do voluntarily experience
again!

>> It does not abstract most of the GUI elements at all, it just
>> draws them on its own.
>>
> Correct. So what?

If the GUI look changes, Qt does not.  So you end up with a really ugly
application full of (for the user) odd redraw errors.  And it many cases the
Qt widgets don't behave exactly as their native counterparts, resulting in a
plain usability nightmare <sigh>

>> As is is non-existent
>> thread-safety - even if a native API used is fully thread-safe, Qt in
>> general is not thread-safe.
>>
> I cannot comment on that. But I recall that early versions of Ot were
> single threaded. And adding thread support to a single threaded design
> often runs into trouble when system near components are involved.

The problem is still there in the 3.x line of Qt.  And one major problem is
the signal implementation.  Another big problem is the self-made drawing
code for GUI elements.

>> And its OpenGL widget for Windows is full of
>> very obvious bugs (also this is only available with the expensive
>> commercial code license); even M$ sample code shows how to properly create
>> a correct Z-buffered contexts.
>>
> Hell, don't use Qt for OpenGL.

Hmm, I think you don't know how the Qt OpenGL widget works: It only allows
you to create OpenGL contexts (and a few other system specific things like
fonts).  The OpenGL drawing and such is all native, you simply make the
native OpenGL calls from inside a Qt OpenGL widget.

    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 <3fe2128a@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

>> No, only the very common bad programming habit of placing template
>> implementation code inside classes instead outside causes template code to
>> be inlined (also a compiler is *not* required to inline anything!).
>>
> (Yes but good compilers do when told so...)

No, good compilers will have mechanisms t detect where inlining will be
beneficial that are more intelligent than any user can be 99% of the time.
They will also be able to inline functions not marked explicitly or
implicitly as inline.

    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