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.


that the template parameter "name" is to be literally replaced
by what is written at the respective point in the template

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);
/*...*/
}


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