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

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

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

It really depends on which STL you are talking about.  Certainly the M$ STL
implementation is rather ugly.  There are much better ones.

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

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

Nothing, really, except debugging (hand hardly for that).  One problem in
the C++ standard is that the string is completely implementation defined.  A
compiler could even return an empty string and conform to the standard.  Or
return the same string for every class.  Only the type_ info comparison
functions are of any real use.  Another big problem is that the C++ standard
does not guarantee that there only will be one type_info object for one
class.

That said, most compilers supply the class name in the name string.

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

No, you just search through a list.  That list is (in general, but
necessarily for every case - it may be shorter) as long as the total number
number of classes a class inherited from.  This has to do with the common
vtable structure.  How exactly it is implemented of course all depends on
your compiler runtime library implementation.  You may want to check if
source code is provided for it (many vendors do provide source code).

    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