José Fonseca [EMAIL PROTECTED] writes:
| On Mon, Mar 10, 2003 at 11:59:05PM +, Keith Whitwell wrote:
|
| Unless C++ can figure out at compile time *exactly* which class is being
| invoked, I think... It's hard to know.
|
| It can, with templates.
Even with no templates, current C++
No, because one of the things C++ does is pass around an extra parameter --
namely the 'self' pointer. The 'real' prototype looks something like:
void Context::BlendFunc( Context *self, GLenum sfactor, GLenum dfactor )
Thats correct, but not with static methods (please correct me, if
Gabriel Dos Reis wrote:
Keith Whitwell [EMAIL PROTECTED] writes:
[...]
| struct function_table {
|...
|void (*BlendFunc)(GLcontext *ctx, GLenum sfactor, GLenum dfactor);
|...
| } driver;
| and
| class Context {
|...
|void BlendFunc(GLenum sfactor, GLenum dfactor);
|
Keith Whitwell [EMAIL PROTECTED] writes:
[...]
| struct function_table {
|...
|void (*BlendFunc)(GLcontext *ctx, GLenum sfactor, GLenum dfactor);
|...
| } driver;
| and
| class Context {
|...
|void BlendFunc(GLenum sfactor, GLenum dfactor);
|...
| } ;
| You can't
I'm just giving a quick update of the Mesa C++ wrappers, in case anybody
wants to discuss it a little in today's meeting.
Wrappers C functions to all the GL context callbacks are already in
place at http://jrfonseca.dyndns.org/projects/dri/cpp/mesa.cxx . (These
were first generated by a little
José Fonseca wrote:
I'm just giving a quick update of the Mesa C++ wrappers, in case anybody
wants to discuss it a little in today's meeting.
Wrappers C functions to all the GL context callbacks are already in
place at http://jrfonseca.dyndns.org/projects/dri/cpp/mesa.cxx . (These
were first
On Mon, Mar 10, 2003 at 08:32:18PM +, Keith Whitwell wrote:
José Fonseca wrote:
Once textures are finished, the most tricky will be the software
rasterizer and the TnL module. For these my idea is to make the
driver
able to switch rasterizers and/or TnL modules in real time, with
the
José Fonseca wrote:
On Mon, Mar 10, 2003 at 08:32:18PM +, Keith Whitwell wrote:
José Fonseca wrote:
Once textures are finished, the most tricky will be the software
rasterizer and the TnL module. For these my idea is to make the
driver
able to switch rasterizers and/or TnL modules in real
On Mon, Mar 10, 2003 at 09:11:06PM +, Keith Whitwell wrote:
José Fonseca wrote:
What disptach table would you be referring to, glapi or the TnL
one? The
problem with disptach tables is that they completely break the OOP
concept as they work with regular functions instead of object
José Fonseca wrote:
On Mon, Mar 10, 2003 at 09:11:06PM +, Keith Whitwell wrote:
José Fonseca wrote:
What disptach table would you be referring to, glapi or the TnL
one? The
problem with disptach tables is that they completely break the OOP
concept as they work with regular functions instead
On Mon, Mar 10, 2003 at 10:36:21PM +, Keith Whitwell wrote:
No, because one of the things C++ does is pass around an extra parameter --
namely the 'self' pointer. The 'real' prototype looks something like:
void Context::BlendFunc( Context *self, GLenum sfactor, GLenum
José Fonseca wrote:
On Mon, Mar 10, 2003 at 10:36:21PM +, Keith Whitwell wrote:
No, because one of the things C++ does is pass around an extra parameter --
namely the 'self' pointer. The 'real' prototype looks something like:
void Context::BlendFunc( Context *self, GLenum sfactor, GLenum
On Mon, 10 Mar 2003 22:23:07 +
José Fonseca [EMAIL PROTECTED] wrote:
[snip]
As I said above this can be done in C++, and without damage to
efficiency.
Imagine you have a TnL abstract class:
class TNL {
// A OpenGL function
virtual void Coord3f(GLfloat x, GLfloat y, GLfloat z) =
On Mon, Mar 10, 2003 at 10:23:07PM +, José Fonseca wrote:
struct function_table {
...
void (*BlendFunc)(GLcontext *ctx, GLenum sfactor, GLenum dfactor);
...
} driver;
and
class Context {
...
void BlendFunc(GLenum sfactor, GLenum dfactor);
...
} ;
Felix Kühling wrote:
On Mon, 10 Mar 2003 22:23:07 +
José Fonseca [EMAIL PROTECTED] wrote:
[snip]
As I said above this can be done in C++, and without damage to
efficiency.
Imagine you have a TnL abstract class:
class TNL {
// A OpenGL function
virtual void Coord3f(GLfloat x, GLfloat y,
--- José Fonseca [EMAIL PROTECTED]
wrote:
Yes, this works as you say _if_ the method isn't
virtual, or at least
the exact type of the class is known at compile
time, i.e., it's not an
abstract Context *, but actually a non-abstract
RadeonContext *.
It works for virtual methods and abstract
Marcelo E. Magallon wrote:
On Mon, Mar 10, 2003 at 10:23:07PM +, José Fonseca wrote:
struct function_table {
...
void (*BlendFunc)(GLcontext *ctx, GLenum sfactor, GLenum dfactor);
...
} driver;
and
class Context {
...
void BlendFunc(GLenum sfactor, GLenum
On Mon, Mar 10, 2003 at 11:08:23PM +, José Fonseca wrote:
But the function I put in the table _was_ an ordinary function, and
not a C++ method, and no redirection call would take place with
inlining. That was the point of the explanation...
Uhm... how do you inline a function call
On Tue, Mar 11, 2003 at 12:33:53AM +0100, Felix Kühling wrote:
On Mon, 10 Mar 2003 22:23:07 +
José Fonseca [EMAIL PROTECTED] wrote:
[snip]
As I said above this can be done in C++, and without damage to
efficiency.
Imagine you have a TnL abstract class:
class TNL {
// A
Jon Smirl wrote:
--- José Fonseca [EMAIL PROTECTED]
wrote:
Yes, this works as you say _if_ the method isn't
virtual, or at least
the exact type of the class is known at compile
time, i.e., it's not an
abstract Context *, but actually a non-abstract
RadeonContext *.
It works for virtual methods
On Mon, 10 Mar 2003 23:43:37 +
José Fonseca [EMAIL PROTECTED] wrote:
Jon Smirl,
I took the liberty of CC'ing the lists again as it is a very valid point
you make here.
On Mon, Mar 10, 2003 at 03:17:56PM -0800, Jon Smirl wrote:
[snip]
_cdecl handler(Context* self, sfactor, dfactor)
On Mon, Mar 10, 2003 at 11:59:05PM +, Keith Whitwell wrote:
class TNL {
// A OpenGL function
virtual void Coord3f(GLfloat x, GLfloat y, GLfloat z) = 0;
^^^
pure virtual method. Depending on what you want to do with this,
this will incur in a
Marcelo E. Magallon wrote:
On Mon, Mar 10, 2003 at 11:08:23PM +, José Fonseca wrote:
But the function I put in the table _was_ an ordinary function, and
not a C++ method, and no redirection call would take place with
inlining. That was the point of the explanation...
Uhm... how do you
On Mon, Mar 10, 2003 at 11:59:05PM +, Keith Whitwell wrote:
Unless C++ can figure out at compile time *exactly* which class is being
invoked, I think... It's hard to know.
It can, with templates.
Anyway, I don't think Jose really wanted a virtual member here, as he
definitely seems
Keith Whitwell wrote:
libGL.so provides a dispatch table that can be efficiently switched. The
real
'gl' entrypoints basically just look up an offset in this table and jump
to
it. No new arguments, no new stack frame, nada -- just an extremely
efficient
jump. Note that this is the
On Tue, Mar 11, 2003 at 12:01:16AM +, Keith Whitwell wrote:
Jon Smirl wrote:
--- José Fonseca [EMAIL PROTECTED]
wrote:
Yes, this works as you say _if_ the method isn't
virtual, or at least
the exact type of the class is known at compile
time, i.e., it's not an
abstract Context *, but
José Fonseca wrote:
On Tue, Mar 11, 2003 at 12:01:16AM +, Keith Whitwell wrote:
Jon Smirl wrote:
--- José Fonseca [EMAIL PROTECTED]
wrote:
Yes, this works as you say _if_ the method isn't
virtual, or at least
the exact type of the class is known at compile
time, i.e., it's not an
abstract
On Mon, Mar 10, 2003 at 11:50:23PM +, Keith Whitwell wrote:
There's a slight misconception happening here -- the 'ctx' argument doesn't
exist. The function should read something like:
void swv3f( GLfloat x, GLfloat y, GLfloat z )
{
28 matches
Mail list logo
