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