Anders F Björklund wrote:
> John Reimer wrote:
> 
>> Yes, this is true, I believe, due to it's nature of not using a compile time link.  But you should be able to call these function "pointers" just like normal functions in D (unlike C).
> 
> 
> You can call function pointers in C too, and take them too - I think ?
> 
> The compiler will (should?) insert the necessary (*p) and &p for you...

Yes, I realize that C can call function pointers.  It's the manner in which these calls are made, that makes all the difference between C and D.

For example (using derelict as an example):

while C can only do (given that glViewport symbol is defined as a function pointer):

(*glViewport) (0, 0, 640, 480);

D can use the function directly:

glViewport( 0, 0, 640, 480 );

if glViewport has been defined as a function(GLint, Glint, GLsizei, GLsizei ).

It's much neater in D, I think.

>> But really, I think he was just responding to my interest in getting the linux version of Derelict up and running (currently a linux version is not available in the base project distribution).  Separate packaging of the opengl and sdl imports, as you were working on, is still of great usefulness.
> 
> 
> One could wrap that in separate loaders, to make it easier to maintain ?
> 
> There is no point in having *two* wrapper projects, if they are similar.

I don't think I understand you here.  Derelict is decidedly different in that it's purpose is to prevent you from having to use an import library  during the linking phase (very useful feature).  Yet for some of us, it may be still useful to have a "quick and dirty" C library linkage for experimentation.  Having the gl, glu, glut, and sdl available in there library linkage forms is still a useful project.  People tend to hunt around for these when they first come to D.

> --anders
> 
> PS. I think that wgl/glx/cgl should stay out of the core gl/glu + glut,
>     since one could just use glut instead of those platform-specifics ?
> 
>     At least, it (wgl) should stay out of the "gl.d" module altogether!
>     And while glext and glee are nice, they are kinda huge compared...

Well, I liked your idea.  But remember, you can always use the "version" statements within gl and glu to accomplish the same purpose: version(Win32) and version (linux).

John Reimer wrote:

While C can only do (given that glViewport symbol is defined as a
> function pointer):
> 
> (*glViewport) (0, 0, 640, 480);
> 
> D can use the function directly:
> 
> glViewport( 0, 0, 640, 480 );
> 
> if glViewport has been defined as a function(GLint, Glint, GLsizei, GLsizei ).
> 
> It's much neater in D, I think.

Could be a local C compiler dialect, but it does do the second version?
Either way, there is still a function pointer involved. (sugar or not)

>> There is no point in having *two* wrapper projects, if they are similar.
> 
> I don't think I understand you here.  Derelict is decidedly different in that it's purpose is to prevent you from having to use an import library  during the linking phase (very useful feature).  Yet for some of us, it may be still useful to have a "quick and dirty" C library linkage for experimentation.  Having the gl, glu, glut, and sdl available in there library linkage forms is still a useful project.  People tend to hunt around for these when they first come to D.

What I meant was that the function-wrapping-project could link to the
simple-mapping-project, thus avoiding to do all the versioning and such?

> Well, I liked your idea.  But remember, you can always use the "version" statements within gl and glu to accomplish the same purpose: version(Win32) and version (linux).

That's how it works now. Makes for one big module, "hard" to divide...
I think it should be several modules, all within the same package.

--anders

Anders F Björklund wrote:
> John Reimer wrote:
> 
> While C can only do (given that glViewport symbol is defined as a
> 
>> function pointer):
>>
>> (*glViewport) (0, 0, 640, 480);
>>
>> D can use the function directly:
>>
>> glViewport( 0, 0, 640, 480 );
>>
>> if glViewport has been defined as a function(GLint, Glint, GLsizei, GLsizei ).
>>
>> It's much neater in D, I think.
> 
> 
> Could be a local C compiler dialect, but it does do the second version?
> Either way, there is still a function pointer involved. (sugar or not)

No, that was just me forgetting some basic C language concepts.  I must forgot how function pointers work in C  ... Sorry, it's been awhile since I've used pure C.  That was very polite of you to relate the issue to local C compiler dialect. :-)

As for the function pointer, why does it matter that it exists?  You don't notice it in your own application code.

>>> There is no point in having *two* wrapper projects, if they are similar.
>>
>>
>> I don't think I understand you here.  Derelict is decidedly different in that it's purpose is to prevent you from having to use an import library  during the linking phase (very useful feature).  Yet for some of us, it may be still useful to have a "quick and dirty" C library linkage for experimentation.  Having the gl, glu, glut, and sdl available in there library linkage forms is still a useful project.  People tend to hunt around for these when they first come to D.
> 
> 
> What I meant was that the function-wrapping-project could link to the
> simple-mapping-project, thus avoiding to do all the versioning and such?

Ah, I see.  Well that won't work properly with Derelict because of it's dependency on function pointers in this case.

>> Well, I liked your idea.  But remember, you can always use the "version" statements within gl and glu to accomplish the same purpose: version(Win32) and version (linux).
> 
> 
> That's how it works now. Makes for one big module, "hard" to divide...
> I think it should be several modules, all within the same package.
> 
> --anders

Okay, I understand what you are getting at.  I don't mind it either way, but I agree that your method makes things clearer.  Maybe some more opinions would be useful.

Later,

John

John Reimer wrote:

> As for the function pointer, why does it matter that it exists?
> You don't notice it in your own application code.

I doubt the runtime "overhead" makes any impact at all...
(the function location has to be loaded from *somewhere*)

It mostly the *code* required to declare the pointer type,
the global for storing the pointer, and then populate it
using the proper platform version of loading the library...

However, it *already* needs that for versions above GL 1.1
so a nice side effect is that it does makes the OpenGL API
the same - no matter what GL version you are targetting...

Hey, wouldn't it be neat if one could weak-link functions ? ;-)


I guess one *could* make a version with function pointers
and then just stuff them all with &function, as a variant...

So I suppose best would be for the GL/SDL "projects" to merge.
But the function pointer types and their globals could still be
separate from the declaration of the C exports (from the libs) ?

Another thing is that OpenGL 1.5 contains a *huge* number of GL
extensions. (the glext.h *source code* is over 300KB/6000 lines)
Just doing 1.1 or 1.2 as a base, would make it a smaller lib.

But like I said, the function-pointer could just wrap the other?

--anders

I find the function pointer way more convenient, due to three things:
- easier linking
- error diagnostics in case of missing libraries, even the possibility to try to load some other library; dynamic linking is your friend :)
- the extra options you have with function pointers; graphics engines especially use function pointers quite a lot, as it can make the render loops more flexible and powerful.

All-in-all; I'd use pointers over static linking any time. IMHO.

Lars Ivar Igesund

Anders F Björklund wrote:
> John Reimer wrote:
> 
>> As for the function pointer, why does it matter that it exists?
>> You don't notice it in your own application code.
> 
> 
> I doubt the runtime "overhead" makes any impact at all...
> (the function location has to be loaded from *somewhere*)
> 
> It mostly the *code* required to declare the pointer type,
> the global for storing the pointer, and then populate it
> using the proper platform version of loading the library...
> 
> However, it *already* needs that for versions above GL 1.1
> so a nice side effect is that it does makes the OpenGL API
> the same - no matter what GL version you are targetting...
> 
> Hey, wouldn't it be neat if one could weak-link functions ? ;-)
> 
> 
> I guess one *could* make a version with function pointers
> and then just stuff them all with &function, as a variant...
> 
> So I suppose best would be for the GL/SDL "projects" to merge.
> But the function pointer types and their globals could still be
> separate from the declaration of the C exports (from the libs) ?
> 
> Another thing is that OpenGL 1.5 contains a *huge* number of GL
> extensions. (the glext.h *source code* is over 300KB/6000 lines)
> Just doing 1.1 or 1.2 as a base, would make it a smaller lib.
> 
> But like I said, the function-pointer could just wrap the other?
> 
> --anders

Lars Ivar Igesund wrote:

> I find the function pointer way more convenient, due to three things:
> - easier linking

Albeit trickier to do cross-platform, or derelict would be up-to-date...

> - error diagnostics in case of missing libraries, even the possibility to try to load some other library; dynamic linking is your friend :)

Well, you instead have the fun part of library versioning: "DLL Hell"

> - the extra options you have with function pointers; graphics engines especially use function pointers quite a lot, as it can make the render loops more flexible and powerful.

We were just talking about the OpenGL functions here, not in general.

> All-in-all; I'd use pointers over static linking any time. IMHO.

Function pointers are a nice addition, but they can be added on the
usual header ("static", or least directly-linked-to-a-dynamic-library)

It all looks like:

1) library function (optional)
extern (C) GLubyte * glGetString (GLenum name);

2) function pointer definition
extern (C) typedef GLubyte* function(GLenum) pfglGetString;

3) function pointer variable
pfglGetString           glGetString;

4) run-time loading from library
private void loadGL()
{
{
  glGetString = cast(pfglGetString)getProc("glGetString");
}
// throws Exception, if the symbol could not be found/loaded

5)
Lather, rinse, repeat... (a few hundred times)



Since the only thing usually provided "upstream" is number 1)
in form of a C header (.h) , it's at least three extra steps.

The only way to keep it remotely up-to-date is to automate,
but unfortunately H2D isn't all that self-going just yet...

It would be nice if there was some neat trick to get the
compiler or linker to do the dirty wrapping-and-loading ?

Managed languages like Java have some advantages here, even
if Sun has bungled it up badly with CLASSPATH and such cruft.


Meanwhile, we'll just use brute force. And lots of Perl. :-)
--anders

Anders F Björklund wrote:

> Lars Ivar Igesund wrote:
> 
>> I find the function pointer way more convenient, due to three things:
>> - easier linking
> 
> 
> Albeit trickier to do cross-platform, or derelict would be up-to-date...

Hmm, yes. The loader module in Phobos were supposed to rectify some of that.

> 
>> - error diagnostics in case of missing libraries, even the possibility to try to load some other library; dynamic linking is your friend :)
> 
> 
> Well, you instead have the fun part of library versioning: "DLL Hell"

Don't you love it.

> 
>> - the extra options you have with function pointers; graphics engines especially use function pointers quite a lot, as it can make the render loops more flexible and powerful.
> 
> 
> We were just talking about the OpenGL functions here, not in general.

And wouldn't OpenGL be an important part of many graphics engines?

Lars Ivar Igesund

Anders F Björklund wrote:
> Lars Ivar Igesund wrote:
> 
>> I find the function pointer way more convenient, due to three things:
>> - easier linking
> 
> 
> Albeit trickier to do cross-platform, or derelict would be up-to-date...
> 
>

Actually, the reason that derelict is not up-to-date on linux is not because of the trickiness of implementing this.  It's because the maintainer does not have a linux system and is not an active linux user.  So it was never a priority. Clayasaurus (what an alias, by the way! :) ) and another person were able to get derelict working on Linux independently with what appears to be little effort.  From the C linking perspective, Linux is often a lot easier to deal with than windows.

Lars Ivar Igesund wrote:

>> Albeit trickier to do cross-platform, or derelict would be up-to-date...
> 
> Hmm, yes. The loader module in Phobos were supposed to rectify some of that.

Right, I just have to "port" it to Darwin (could use the SDL code?)

>> Well, you instead have the fun part of library versioning: "DLL Hell"
> 
> Don't you love it.

Don't have it here. Everyone lugs their own Frameworks around.
(Something about disk being cheap. System libs do exist, but
they're all controlled by the mothership - here being Mac OS X)

>> We were just talking about the OpenGL functions here, not in general.
> 
> And wouldn't OpenGL be an important part of many graphics engines?

Well, yes it would. But function pointers for the OpenGL 1.1 stuff ?

Either way, I'll just add the function pointer types to "my own" gl.d
(a friendly gnome had already added all of them to the glext header)

--anders

I wrote earlier:

> Function pointers are a nice addition, but they can be added on the
> usual header ("static", or least directly-linked-to-a-dynamic-library)
> 
> It all looks like:
> 
> 1) library function (optional)
> extern (C) GLubyte * glGetString (GLenum name);
> 
> 2) function pointer definition
> extern (C) typedef GLubyte* function(GLenum) pfglGetString;
[...]
> 5)
> Lather, rinse, repeat... (a few hundred times)


It was trivial to do with Perl...

They will follow the same syntax as glext:
alias GLubyte * (*PFGLGETSTRINGPROC) (GLenum name);

gl and glext are done, glu and glut will be shortly.

The original headers, ported to D just as they are...
(loading from library left for derelict / the reader)

--anders