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

Christoph Hormann <chr### [at] gmxde> wrote:

>Mael wrote:
>>>Hmm, but this isn't benchmark.pov...
>> 
>> 
>> Does benchmark.pov have lot of intersections csg ? It seems fair to me to
>> test this patch on a scene that uses it (and perhaps even a lot of it to
>> clearly show the effect of the new algorithm)
>
>The benchmark scene uses a reasonable amount of CSG, a comparison with 

I don't think so.
Both of my private builds take about 38min for benchmark.pov (PIV
2.8GHz, 1GB RAM, options are -w384 -h384 +a0.3 +v -d -f -x).

Setting use_photons = use_area_light = show_clouds = show_objects to
false				==> about 114sec both.
Additionally remove the Sockets ==> about  79sec both.
So as a rough estimate the intersection objects only take about 2% of
the total time.

>this scene would show how much gain you can expect in a typical scene.
>You can of course construct a scene where POV-Ray spends 90% of the time 
>with CSG calculations but this would not be very realistic.

Yes and no.
Give me a ratio old version <-> new version and i'll give you a scene
that shows a better ratio :-).
This is a problem with benchmarks or measurements generally, you have
to have a close look at the boundary conditions.
IMHO benchmark.pov can be used to benchmark the hardware it is running
on but i wouldn't use it to profile/compare different versions of
POV-Ray on the same hardware.

Andreas

Post a reply to this message

> Yes and no.
> Give me a ratio old version <-> new version and i'll give you a scene
> that shows a better ratio :-).
> This is a problem with benchmarks or measurements generally, you have
> to have a close look at the boundary conditions.
> IMHO benchmark.pov can be used to benchmark the hardware it is running
> on but i wouldn't use it to profile/compare different versions of
> POV-Ray on the same hardware.
>
> Andreas

I agree. Just because a patch does not appreciably speed up benchmark.pov 
does not mean that the patch isn't worthwhile. Why is benchmark.pov 
arbitrarily declared to be the ideal or typical POV-Ray scene, anyway? 
With so many possibilities of doing things in POV-Ray, is there even such 
a thing as "the typical scene" ?


George


-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Post a reply to this message