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

In fact, the 'inline' keyword is obsolete with regard to inlining.
In most current compilers this keyword has no effect whatshoever on
the behaviour of the compiler: If the compiler can inline a function
and its inlining algorithm tells it that it will be beneficial, it will
inline it, else it won't. And this is completely regardless of whether the
'inline' keyword appears or not.

  The 'inline' keyword has a quite different task, however, which means
that it isn't completely obsolete in C++. It's actually a command for
the linker (and has nothing to do with inlining).

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

On Thu, 18 Dec 2003 21:32:49 +0100, Wolfgang Wieser <wwi### [at] gmxde> wrote:
> > It does not abstract most of the GUI elements at all, it just
> > draws them on its own. 
>
> Correct. So what?

So it is not user-friendly for native GUI users (which of course is not
related to C++ internal design discuted here nor to improved intersection
routine). See screenshots of native minimal sample under wxWindows:

OS2:    http://www.wxwindows.org/images/screens/wxos2.jpg
Win9x:  http://www.wxwindows.org/images/screens/minimal_win95sm.gif
Motif:  http://www.wxwindows.org/images/screens/minimal_motifbig.gif
MacOSX: http://www.wxwindows.org/images/screens/minimal_macosx.gif
GTK+:   http://www.wxwindows.org/images/screens/minimal_gtk.gif
WinCE:  http://www.wxwindows.org/images/screens/wxwince_minimal.jpg
http://cvs.wxwindows.org/viewcvs.cgi/wxWindows/samples/minimal/minimal.cpp

and screenshots of more advanced application of wxWindows under MacOSx,
Windows, Linux: http://mahogany.sourceforge.net/screenshots.html

ABX

Post a reply to this message

Thorsten Froehlich wrote:
>> 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).
> 
Okay, and do you think that explains how the following code 
works: 

-----------------------------
#include <iostream>

struct A
{
        int a;
        A():a(1){}
        virtual ~A(){}
};

struct B
{
        int b;
        B():b(2){}
        virtual ~B(){}
};

struct C : A,B
{ };

int main()
{
        C c;
        A *a=&c;
        std::cerr << (dynamic_cast<B*>(a))->b << std::endl;
}
-----------------------------

Obviously, you can cast A to B without either one being derived 
from the other one just because they share a common parent. 

I must admit that I did not spend a lot of time on thinking but 
as for now, I cannot imagine any algoritm which can perform the 
above dymanic_cast without doing tree traversal. 

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:
>>> 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>
> 
Okay. As I am only using Qt under Linux, I do not see that problem. 
But regarding MS Windows, you may well be right. 

And well... probably ABX is right: We're off-topic here. 

But as we're talking about GUI, I'd favour complete separation 
of the raytracing core and the GUI for future POVRay versions. 
It should be possible to build a non-GUI POVRay for render farms. 

Wolfgang

Post a reply to this message

In article <3fe21f39@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

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

The language isn't that bad, actually...though it is missing a few 
things that I'd really like to have. The standard frameworks, however...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

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

> But as we're talking about GUI, I'd favour complete separation
> of the raytracing core and the GUI for future POVRay versions.

You will be surprised ... this is already possible with POVMS. Not that it
is easy to use in the 3.5.0 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

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

> Obviously, you can cast A to B without either one being derived
> from the other one just because they share a common parent.
>
> I must admit that I did not spend a lot of time on thinking but
> as for now, I cannot imagine any algoritm which can perform the
> above dymanic_cast without doing tree traversal.

You may recall one can keep binary trees in an array.  Essentially, if you
take away the need to add and remove elements (as C++ class inheritance is
fixed this requirement is fulfilled), you actually have to fold the whole
"tree" to a list.  The exact rules, while well defined, are a bit
complicated, but what exactly has to happen is specified in the ISO C++
specification...

    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've got it (sorry for the long delay but i was on holiday together
with my children).

I'll post the fixed version of csg.cpp to povray.binaries.programming.

Andreas

Post a reply to this message