www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Strange Issues regarding aliases

reply Joerg Joergonson <JJoergonson gmail.com> writes:
I have stuff like


public static class fGL
{
	nothrow  nogc extern(System)
	{
		alias CullFace = void function(tGL.Enum);
		alias FrontFace = void function(tGL.Enum);
		alias HInt = void function(tGL.Enum, tGL.Enum);
		alias LineWidth = void function(tGL.Float);
		alias PoIntSize = void function(tGL.Float);
                 ...
         }
}


public static struct tGL
{
	alias Void = void;
	alias IntPtr = ptrdiff_t;
	alias SizeInt = int;
	alias Char = char;
	alias CharARB = byte;
	alias uShort = ushort;
	alias Int64EXT = long;
	alias Short = short;
	alias uInt64 = ulong;
	alias HalfARB = ushort;
         alias BlendFunc = void function(tGL.Enum, tGL.Enum);
         ...

         __gshared {
	    CopyTexImage1D glCopyTexImage1D;
             TextureParameterf glTextureParameterf;
             VertexAttribI3ui glVertexAttribI3ui;
             VertexArrayElementBuffer glVertexArrayElementBuffer;
             BlendFunc glBlendFunc;
             ...
}


public struct eGL
{
	enum ubyte FALSE = 0;
	enum ubyte TRUE = 1;
	enum uint NO_ERROR = 0;
	enum uint NONE = 0;
	enum uint ZERO = 0;
	enum uint ONE = 1;
         ...
}


And when I use this stuff(which is clearly openGL being cleaned 
up a bit(I know I can use modules to essentially do this too but 
that is irrelevant):

I get errors like


Error: null has no effect in expression (null)	

Error: more than one argument for construction of extern 
(Windows) void function(uint, uint) nothrow  nogc	


This is when using it like

fGL.BlendFunc(eGL.SRC_ALPHA, eGL.ONE_MINUS_SRC_ALPHA);

What's going on? Please no responses about "You are going to run 
into a lot of problems since all the openGL code uses the flat 
accessing"... The whole point is to get away from that ancient 
way and backwards way.
Jun 14 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/14/16 11:29 AM, Joerg Joergonson wrote:

 I have stuff like


 public static class fGL
 {
     nothrow  nogc extern(System)
     {
         alias CullFace = void function(tGL.Enum);
         alias FrontFace = void function(tGL.Enum);
         alias HInt = void function(tGL.Enum, tGL.Enum);
         alias LineWidth = void function(tGL.Float);
         alias PoIntSize = void function(tGL.Float);
                 ...


Your aliases are a bunch of function pointer types. This isn't what you 
likely want.

I'm assuming you want to bring the existing functions into more 
categorized namespaces? What you need is to do this:

public static struct fGL
{
    alias CullFace = .CullFace; // or whatever the fully qualified name is.

I don't have much experience with the opengl modules, so I can't be more 
specific.

-Steve
Jun 14 2016
parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Tuesday, 14 June 2016 at 16:08:03 UTC, Steven Schveighoffer 
wrote:

 On 6/14/16 11:29 AM, Joerg Joergonson wrote:

                 [...]


 Your aliases are a bunch of function pointer types. This isn't 
 what you likely want.

 I'm assuming you want to bring the existing functions into more 
 categorized namespaces? What you need is to do this:

 public static struct fGL
 {
    alias CullFace = .CullFace; // or whatever the fully 
 qualified name is.

 I don't have much experience with the opengl modules, so I 
 can't be more specific.

 -Steve


This is how derelict does it, I simply moved them in to the class 
for simplicity.
Jun 14 2016
parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
 This is how derelict does it, I simply moved them in to the 
 class for simplicity.


I mean glad: http://glad.dav1d.de/
Jun 14 2016
parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Tuesday, 14 June 2016 at 17:34:42 UTC, Joerg Joergonson wrote:

 This is how derelict does it, I simply moved them in to the 
 class for simplicity.


 I mean glad: http://glad.dav1d.de/


It seems that a loader is required for some reason and that 
possibly could be one or both of the problems.
Jun 14 2016
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/14/16 1:37 PM, Joerg Joergonson wrote:

 On Tuesday, 14 June 2016 at 17:34:42 UTC, Joerg Joergonson wrote:

 This is how derelict does it, I simply moved them in to the class for
 simplicity.


 I mean glad: http://glad.dav1d.de/


 It seems that a loader is required for some reason and that possibly
 could be one or both of the problems.


I don't know what glad is doing. What I do know is that if you have an 
alias like this:

alias CullFace = void function(tGL.Enum);

This is type alias, saying variables of type CullFace will be pointers 
to functions that return void, and take tGL.Enum type.

If you attempt to "call" a type, then I don't think it works, you need a 
variable of that type to call it. I think this is why you see such 
strange errors.

It's possible a loader will fill in the details. I don't know.

-Steve
Jun 14 2016
prev sibling next sibling parent Alex Parrill <initrd.gz gmail.com> writes:
On Tuesday, 14 June 2016 at 17:37:40 UTC, Joerg Joergonson wrote:

 On Tuesday, 14 June 2016 at 17:34:42 UTC, Joerg Joergonson 
 wrote:

 This is how derelict does it, I simply moved them in to the 
 class for simplicity.


 I mean glad: http://glad.dav1d.de/


 It seems that a loader is required for some reason and that 
 possibly could be one or both of the problems.


You absolutely need a loader to load most opengl functions. They 
are not usually exposed in the shared object, as gl function 
pointers are tied to a specific opengl context.

You are trying to call function pointer types, which is invalid. 
You need to declare some variable with the type, load the 
function pointer into the variable (platform specific; there are 
plenty of tutorials on how to do this in C), and call that 
variable.


(Also I disagree that separating the opengl API based on what the 
symbol is is a step up from the "ancient and backwards flat 
access" way. Functions are, by neccessity, coupled to the types 
and enums they take. A better categorization would be based on 
version introduced or extension, iirc jogl does that)
Jun 14 2016
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 14 June 2016 at 17:37:40 UTC, Joerg Joergonson wrote:

 On Tuesday, 14 June 2016 at 17:34:42 UTC, Joerg Joergonson 
 wrote:

 This is how derelict does it, I simply moved them in to the 
 class for simplicity.


 I mean glad: http://glad.dav1d.de/


 It seems that a loader is required for some reason and that 
 possibly could be one or both of the problems.


Yes, Derelict and glad both work this way. A loader is required 
because you are using function pointers, which means you need the 
memory addresses of the functions in the library, which are only 
known at runtime when the library is loaded into memory. There's 
no way around it. You are doing manually what the system loader 
does when you declare a normal function and link with an import 
library (on Windows) or directly with a dynamic library (on Posix 
systems).

You should be declaring your functions something like this:

// Most functions in C libraries should be extern(C), but OpenGL 
needs to
// be extern(Windows) on Windows and extern(C) everywhere else. 
extern(System)
// handles that for you. Making them nothrow and  nogc is very 
handy for D
// code that needs those attributes.
extern(System)  nogc nothrow {
     alias aClear = void function(int);
}

struct GL {
    aClear clear;
}

void loadFuncs(ref GL gl) {
     // This is system specific. You can see the possibilities in
     // the module derelict.opengl3.gl3
     version(Windows) ennum libName = "OpenGL32.dll"

     // loadSharedLibrary should wrap OS-specific 
LoadLibrary/dlopen
     auto lib = loadSharedLibrary(libName);

     // loadFunc should wrap OS-specific GetProcAdress/dlsysm
     gl.clear = cast(aClear)lib.loadFunc("glClear");
}
Jun 15 2016