|
|
|
|
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: Improved intersection routine for CSG-Intersection objects
Date: 18 Dec 2003 16:45:00
Message: <3fe21fdc$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: Improved intersection routine for CSG-Intersection objects
Date: 18 Dec 2003 16:57:47
Message: <3fe222db$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Warp
Subject: Re: Improved intersection routine for CSG-Intersection objects
Date: 18 Dec 2003 19:44:35
Message: <3fe249f3@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Wolfgang Wieser
Subject: Re: Improved intersection routine for CSG-Intersection objects
Date: 20 Dec 2003 05:31:52
Message: <3fe42517@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Wolfgang Wieser
Subject: Re: Improved intersection routine for CSG-Intersection objects
Date: 20 Dec 2003 06:11:49
Message: <3fe42e74@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: Improved intersection routine for CSG-Intersection objects
Date: 20 Dec 2003 16:38:45
Message: <3fe4c165$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: Improved intersection routine for CSG-Intersection objects
Date: 20 Dec 2003 16:45:38
Message: <3fe4c302@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |