www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Either I'm just too stupid, or D is lacking something

reply Wolfgang Draxinger <wdraxinger darkstargames.de> writes:
As some might know I'm currently converting my 3D engine's source
code from C++ to D. But now I'm stuck with something of which I
can't believe that it might not be possible with D:

As one might expect the engine also manages textures, and OpenGL
textures have so called parameters. Now counting 2 and 2 I
thought: "OpenGL Texture parameters, hmm D supports parameter
assignment syntax, too, that makes things look much nicer":

class GLTexture : Texture
{
        GLint min_filter(GLint _filter) {
                glTexParameteri(Target, GL_TEXTURE_MIN_FILTER, _filter);
                return _filter;
        }
        GLint min_filter() {
                GLint _filter;
                glGetTexParameteri(Target, GL_TEXTURE_MIN_FILTER, &_filter);
                return _filter;
        }

        GLint mag_filter(GLint _filter) {
                glTexParameteri(Target, GL_TEXTURE_MAG_FILTER, _filter);
                return _filter;
        }
        GLint mag_filter() {
                GLint _filter;
                glGetTexParameteri(Target, GL_TEXTURE_MAG_FILTER, &_filter);
                return _filter;
        }
/*
...
*/

private:
        const GLenum Target;
}

However this looks rather crude and shouts for generic
programming. Instead just writing

        mixin GLTemplateParameter!(GL_TEXTURE_MIN_FILTER, min_filter);

or something similair would be much nicer, shorter and less error
prone. But there's the problem, that I don't know (or that there
might not be the possibility) to give a name as parameter, that
will be used for declaration naming.

Probably I'm just too stupid, but if that's really a missing
feature, then I plead to add it.

Wolfgang Draxinger
Jul 24 2006
next sibling parent Wolfgang Draxinger <wdraxinger darkstargames.de> writes:
Wolfgang Draxinger wrote:


         mixin GLTemplateParameter!(GL_TEXTURE_MIN_FILTER,
         min_filter);



Err, should be of course GLTextureParameter.

Wolfgang Draxinger
--
Jul 24 2006
prev sibling next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
how about something like this ?


template Mixer(T, int paramType) {
	void foo(T value) {
		static if (is(T == int)) {
			// glTexParameteri...
		}
		else static if (is(T == float)) {
			// glTexParameterf
		}
	}
	
	T foo() {
		// ...
		return 11111;
	}
}

const int GL_TEXTURE_MIN_FILTER = 666;

class Foo {
	mixin Mixer!(int, GL_TEXTURE_MIN_FILTER) min_filter_;
	alias min_filter_.foo min_filter;
}


void main () {
	auto f = new Foo;
	f.min_filter = 1;
	int a = f.min_filter;
}



btw, does your engine have some place in the net ? i'd be curious to see 
it :)



Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Jul 24 2006
parent Wolfgang Draxinger <wdraxinger darkstargames.de> writes:
X-Post to digitalmars.D due to language enhancement suggestion.

Tom S wrote:


 class Foo {
 mixin Mixer!(int, GL_TEXTURE_MIN_FILTER) min_filter_;
 alias min_filter_.foo min_filter;
 }



That's line to much. Otherwise I could also write

template GLTextureParameterI_Set(GLenum Param)(T value) {
glTexParameteri(Target, Param, value);
return value;
}

template GLTextureParameterI_Get(GLenum Param)() {
GLint value;
glGetTexParameteri(Target, Param, &value);
return value;
}

class Foo
{
        mixin GLTextureParameterI_Set(GL_TEXTURE_MIN_FILTER) min_filter;
        mixin GLTextureParameterI_Get(GL_TEXTURE_MIN_FILTER) min_filter;
};

My idea would have been, to extend the declaration of Templated
with something resembling marco unfolding without introducing
it's problems.

I'd like to write e.g the following (note the '#' indicating,
that the template parameter "name" is to be literally replaced
by what is written at the respective point in the template
instanciation. The rule would be, that what follows after a '#'
in a template must be a valid identifier and not a statement or
expression. The usage of such a parameter within a template
declaration would automatically limit it's usage to mixins;
implicit mixin expansion could be assumed, but I'd discourage
that):

template GLTexParameter(T type, GLenum Param, #name)
{
        T #name(T value)
        {
                static if ( is ( T == GLint ) ) {
                        glTexParameteri(Target, Param, value);
                } else static if ( is ( T == GLfloat ) ) {
                        glTexParameterf(Target, Param, value);
                }
                return value;
        }

        T #name()
        {
                T value;
                static if ( is ( T == GLint ) ) {
                        glGetTexParameteriv(Target, Param, &value);
                } else static if ( is ( T == GLfloat ) ) {
                        glGetTexParameterfv(Target, Param, &value);
                }
                return value;
        }
}

class Texture
{
        mixin GLTexParameter!(GLint, GL_TEXTURE_MIN_FILTER, min_filter);
        mixin GLTexParameter!(GLint, GL_TEXTURE_MAG_FILTER, mag_filter);
        mixin GLTexParameter!(GLfloat, GL_TEXTURE_PRIORITY, priority);
/*...*/
}

I used a '#' since it is not being assumed a token by the D specs
right now. I'd also like '$' like in shell scripts or Perl, but
that's a D token already, but right now I can't remember what it
is for, or if it's actually used.


 btw, does your engine have some place in the net ? i'd be
 curious to see it :)



There's nothing to be seen outstanding right now (except some
simple screenshots of single objects), because it's not done
yet. I switched to D, since I got sick with C++ during
development. Ever tried to make self reflecting components in
C++, _with_ template support?

D is a great language for this OTOH for a few reasons: It's easy
to parse. There exists a good frontend for GCC and it delivers
all data that is needed for self reflection.

About one year ago I was looking around for nicer methods on
implementing it, which was, when I came to D.

Rest assured, that as soon the engine is done I'm going to
announce it's release on the D newsgroups.

Check http://www.darkstargames.de/ and if you don't want to loose
your eyes for eye cancer better do it in about 2 months and then
go directly to http://www.darkstargames.de/even ;-) In about a
week the semester break begins and I got 3 months worth of time
to spend only my private projects, which one of them is to make
a new XHTML compliant homepage with sane CSS and modern look.

Wolfgang Draxinger
-- 
E-Mail address works, Jabber: hexarith jabber.org, ICQ: 134682867
Jul 24 2006
prev sibling parent reply Derek <derek psyc.ward> writes:
On Mon, 24 Jul 2006 22:14:30 +0200, Wolfgang Draxinger wrote:



 Probably I'm just too stupid, but if that's really a missing
 feature, then I plead to add it.



I have trouble understanding mixins too. They seem to solve half the
problem I have and create two more while doing so. I suspect that I'm
trying to do more than Walter believes should be allowed. The syntax and
usage is more obtuse and misleading than C++ templates IMHO.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Jul 24 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Derek wrote:

 On Mon, 24 Jul 2006 22:14:30 +0200, Wolfgang Draxinger wrote:
 
 

 Probably I'm just too stupid, but if that's really a missing
 feature, then I plead to add it.



 I have trouble understanding mixins too. They seem to solve half the
 problem I have and create two more while doing so. I suspect that I'm
 trying to do more than Walter believes should be allowed. The syntax and
 usage is more obtuse and misleading than C++ templates IMHO.



They work brilliantly for creating nested functions, but so far I 
haven't found them to be useful for anything else. I think they'll need 
to be totally revamped eventually; there's some serious problems with 
them in their current form. I'd advise against using them if there's a 
reasonable alternative.
Jul 25 2006
parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Don Clugston wrote:

 Derek wrote:
 

 On Mon, 24 Jul 2006 22:14:30 +0200, Wolfgang Draxinger wrote:



 Probably I'm just too stupid, but if that's really a missing
 feature, then I plead to add it.




 I have trouble understanding mixins too. They seem to solve half the
 problem I have and create two more while doing so. I suspect that I'm
 trying to do more than Walter believes should be allowed. The syntax and
 usage is more obtuse and misleading than C++ templates IMHO.



 
 They work brilliantly for creating nested functions, but so far I 
 haven't found them to be useful for anything else. I think they'll need 
 to be totally revamped eventually; there's some serious problems with 
 them in their current form. I'd advise against using them if there's a 
 reasonable alternative.



David Rushby's update of the Python header uses them in place of some 
macros in the original C version. Most of the raw Python/C API revolves 
around a series of structs, all of which share a certain series of 
fields in common. So at the root of all these structs is this template:

template PyObject_HEAD() {
     int ob_refcnt;         // The reference count of the object
     PyTypeObject *ob_type; // A pointer to the object's type object
}

Most operations in the API involve passing PyObject*s around; the 
PyObject struct is simply defined like this:

struct PyObject {
     mixin PyObject_HEAD;
}

And then, any other types defined in the API just add their own fields 
after the mixin:

struct PySomeType {
     mixin PyObject_HEAD;
     int some_field;
}

In this way is inheritance simulated in a C API. Where PyObject_HEAD is 
a macro in C, it is a much safer mixin in D.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki
Jul 25 2006