www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is it possible to specify the address returned by the address of

reply DreadKyller <dreadkyller gmail.com> writes:
Been using D for a couple years now, however one problem I've 
had, more so recently since I've been dealing a lot with OpenGL 
is related to pointers.

I have a matrix object to aid with the matrix math required for 
working with 3D transforms. However OpenGL (I'm using DerelictGL3 
bindings) requires pointers to the data. I am currently doing the 
following:

Matrix!float ortho(float l, float r, float b, float t, float f, 
float n = -1)
{
	Matrix!float oMat = identity(); // Get default Identity Matrix
	
	oMat[0,0] =  2 / (r - l);
	oMat[1,1] =  2 / (t - b);
	oMat[2,2] = -2 / (f - n);
	
	oMat[3] = [-(r+l)/(r-l), -(t+b)/(t-b), -(f+n)/(f-n), 1];
	
	return oMat;
}

And then to use with OpenGL (passing as uniform into shader):

glUniformMatrix4fv(transform_uniform, 1, GL_FALSE, matrix.addr );

where addr is a property that returns the address of the first 
item in the Matrix's internal data. I know I can also use 
&matrix[0][0]

My question is about overloading, several operators can be 
overloaded in D, one of the ones that can't apparently is the 
address of operator (&object). My question is have I simply 
missed it or does it actually not exist, and if it's not 
overloadable, is there any reason why this was decided? Because 
there's been numerous times that it'd be useful to me, just 
recently with how much I use the operator because of OpenGL I 
decided to ask.
Sep 27 2017
next sibling parent reply nkm1 <t4nk074 openmailbox.org> writes:
On Wednesday, 27 September 2017 at 16:35:54 UTC, DreadKyller 
wrote:

 Been using D for a couple years now, however one problem I've 
 had, more so recently since I've been dealing a lot with OpenGL 
 is related to pointers.

 I have a matrix object to aid with the matrix math required for 
 working with 3D transforms. However OpenGL (I'm using 
 DerelictGL3 bindings) requires pointers to the data. I am 
 currently doing the following:

 Matrix!float ortho(float l, float r, float b, float t, float f, 
 float n = -1)
 {
 	Matrix!float oMat = identity(); // Get default Identity Matrix
 	
 	oMat[0,0] =  2 / (r - l);
 	oMat[1,1] =  2 / (t - b);
 	oMat[2,2] = -2 / (f - n);
 	
 	oMat[3] = [-(r+l)/(r-l), -(t+b)/(t-b), -(f+n)/(f-n), 1];
 	
 	return oMat;
 }

 And then to use with OpenGL (passing as uniform into shader):

 glUniformMatrix4fv(transform_uniform, 1, GL_FALSE, matrix.addr 
 );

 where addr is a property that returns the address of the first 
 item in the Matrix's internal data. I know I can also use 
 &matrix[0][0]

 My question is about overloading, several operators can be 
 overloaded in D, one of the ones that can't apparently is the 
 address of operator (&object). My question is have I simply 
 missed it or does it actually not exist, and if it's not 
 overloadable, is there any reason why this was decided? Because 
 there's been numerous times that it'd be useful to me, just 
 recently with how much I use the operator because of OpenGL I 
 decided to ask.


& is not overloadable, presumably because some people were 
annoyed by abuse of operator overloading in C++. The reason is to 
improve readability (of other people's code).
Just rename matrix.addr to matrix.ptr... like in arrays: 
https://dlang.org/spec/arrays.html#array-properties
That would be clearer (opinion), since the reader of your code 
can assume that matrix.ptr does the same thing with your matrix 
as array.ptr does with arrays. OTOH, overloading &matrix to do 
something different from built in &matrix seems like a pointless 
obfuscation to me.
Sep 27 2017
parent reply DreadKyller <dreadkyller gmail.com> writes:
On Wednesday, 27 September 2017 at 19:55:07 UTC, nkm1 wrote:

 On Wednesday, 27 September 2017 at 16:35:54 UTC, DreadKyller 
 wrote:

 Been using D for a couple years now, however one problem I've 
 had, more so recently since I've been dealing a lot with 
 OpenGL is related to pointers.

 I have a matrix object to aid with the matrix math required 
 for working with 3D transforms. However OpenGL (I'm using 
 DerelictGL3 bindings) requires pointers to the data. I am 
 currently doing the following:

 Matrix!float ortho(float l, float r, float b, float t, float 
 f, float n = -1)
 {
 	Matrix!float oMat = identity(); // Get default Identity Matrix
 	
 	oMat[0,0] =  2 / (r - l);
 	oMat[1,1] =  2 / (t - b);
 	oMat[2,2] = -2 / (f - n);
 	
 	oMat[3] = [-(r+l)/(r-l), -(t+b)/(t-b), -(f+n)/(f-n), 1];
 	
 	return oMat;
 }

 And then to use with OpenGL (passing as uniform into shader):

 glUniformMatrix4fv(transform_uniform, 1, GL_FALSE, matrix.addr 
 );

 where addr is a property that returns the address of the first 
 item in the Matrix's internal data. I know I can also use 
 &matrix[0][0]

 My question is about overloading, several operators can be 
 overloaded in D, one of the ones that can't apparently is the 
 address of operator (&object). My question is have I simply 
 missed it or does it actually not exist, and if it's not 
 overloadable, is there any reason why this was decided? 
 Because there's been numerous times that it'd be useful to me, 
 just recently with how much I use the operator because of 
 OpenGL I decided to ask.


 & is not overloadable, presumably because some people were 
 annoyed by abuse of operator overloading in C++. The reason is 
 to improve readability (of other people's code).
 Just rename matrix.addr to matrix.ptr... like in arrays: 
 https://dlang.org/spec/arrays.html#array-properties
 That would be clearer (opinion), since the reader of your code 
 can assume that matrix.ptr does the same thing with your matrix 
 as array.ptr does with arrays. OTOH, overloading &matrix to do 
 something different from built in &matrix seems like a 
 pointless obfuscation to me.


I mean to an extent I agree, but I moved from using GLfloat 
arrays for matrix's to a Matrix object to aid in Matrix math like 
multiplication, so I have to go through my code and in many 
places change it to using matrix.ptr, considering that I have to 
do this for every object in a scene multiple times for the 
translation, scale, projection and etc matrix's it's more 
tedious, and I'm the only one working on the code and I comment 
and document my code a lot. If one thing annoys m e about 
language design, it's when peoples actions dictate the decisions 
of the language, it shouldn't be the responsibility of the 
language to limit users in order to prevent bad habits or 
practices, it should be the responsibility of education to do so. 
The attitude of "some people use this feature incorrectly, so 
let's ban it's use entirely" is honestly ridiculous to me, but oh 
well, that's apparently the modern philosophy.
Sep 27 2017
parent reply nkm1 <t4nk074 openmailbox.org> writes:
On Wednesday, 27 September 2017 at 20:24:24 UTC, DreadKyller 
wrote:

 The attitude of "some people use this feature incorrectly, so 
 let's ban it's use entirely" is honestly ridiculous to me, but 
 oh well, that's apparently the modern philosophy.


Not even modern, see Java :) ("I left out operator overloading as 
a fairly personal choice because I had seen too many people abuse 
it in C++." - James Gosling)
Sep 27 2017
parent reply DreadKyller <dreadkyller gmail.com> writes:
On Wednesday, 27 September 2017 at 21:18:50 UTC, nkm1 wrote:

 On Wednesday, 27 September 2017 at 20:24:24 UTC, DreadKyller 
 wrote:

 The attitude of "some people use this feature incorrectly, so 
 let's ban it's use entirely" is honestly ridiculous to me, but 
 oh well, that's apparently the modern philosophy.


 Not even modern, see Java :) ("I left out operator overloading 
 as a fairly personal choice because I had seen too many people 
 abuse it in C++." - James Gosling)


Oh don't get me wrong, I'm not saying that not allowing operator 
overloading is new, and Java doesn't allow any, like at all, 
compared to D just not allowing a handful. And I wasn't referring 
to operator overloading specifically, I was talking in general 
about how it's become more common with modern languages to try 
being overly safe, in attempt to prevent users from making 
mistakes. It's not that it's particularly problematic, but it 
does tend to make some more recent languages far more verbose and 
tedious to type. This philosophy has existed since very early on, 
it's just become more common in the last decade or so. I just 
disagree with the concept, I just happen to feel that had the 
effort that was put into the philosophy and design of making 
things safer had been put into educating and developing better 
tools and resources then the need for such restrictions would be 
less essential. In general I feel D has a good balance of this, 
there are restrictions that I dislike, but can work around them 
because or the benefits of the language, despite what I see as 
several flaws in the design personally, it's still currently my 
favorite language.

Also off-topic slightly, but am I the only one with massive 
latency on this site? It took like almost 2 minutes from me 
hitting reply before this page showed up, and my last few posts 
took like a minute to post, and all other sites I've been to 
don't have that problem, is that a problem with the site or am I 
the only one with this issue?
Sep 27 2017
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, September 27, 2017 22:01:26 DreadKyller via Digitalmars-d-
learn wrote:

 Also off-topic slightly, but am I the only one with massive
 latency on this site? It took like almost 2 minutes from me
 hitting reply before this page showed up, and my last few posts
 took like a minute to post, and all other sites I've been to
 don't have that problem, is that a problem with the site or am I
 the only one with this issue?


Historically, it's been lightning fast, so if it's slow right now, there's a
definite problem. There may be something else running on that server that's
causing problems. If the problem persists, I'd suggest opening a thread in
the main forum about it, and that might get Vladimir's attention.

Personally, I never use the website as the frontend to the newsgroup. I
always use the mailing list, so I have no clue how the website has been
performing lately.

- Jonathan M Davis
Sep 28 2017
parent kinke <kinke gmx.net> writes:
On Thursday, 28 September 2017 at 10:24:28 UTC, Jonathan M Davis 
wrote:

 On Wednesday, September 27, 2017 22:01:26 DreadKyller via 
 Digitalmars-d- learn wrote:

 Also off-topic slightly, but am I the only one with massive 
 latency on this site? It took like almost 2 minutes from me 
 hitting reply before this page showed up, and my last few 
 posts took like a minute to post, and all other sites I've 
 been to don't have that problem, is that a problem with the 
 site or am I the only one with this issue?


 Historically, it's been lightning fast, so if it's slow right 
 now, there's a definite problem. There may be something else 
 running on that server that's causing problems. If the problem 
 persists, I'd suggest opening a thread in the main forum about 
 it, and that might get Vladimir's attention.


I already tried, in vain so far, performance is lightning fast in 
about 90% of my requests, and catastrophic in the other 10%: 
https://forum.dlang.org/thread/vndgejrhmqynthwbfksf forum.dlang.org
Sep 28 2017
prev sibling next sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 27 September 2017 at 16:35:54 UTC, DreadKyller 
wrote:

 My question is about overloading, several operators can be 
 overloaded in D, one of the ones that can't apparently is the 
 address of operator (&object). My question is have I simply 
 missed it or does it actually not exist, and if it's not 
 overloadable, is there any reason why this was decided? Because 
 there's been numerous times that it'd be useful to me, just 
 recently with how much I use the operator because of OpenGL I 
 decided to ask.


My answer is that & is a defined operation on all addressable 
memory. Unlike other operators which don't exist until you 
"overload" them.

For example, if you store your Matrix in a custom container it 
could try to store pointer rather than the struct itself, if & is 
overloaded the generic implementation would be broken because it 
would no longer be a pointer to Matrix but to the inner element.

Whereas generic code which utilizes addition or append can assume 
the type appropriately defined the behavior to semantically match 
the desired use, generic code would be broken if the type changed 
& to do something different from what the language defines it to 
do.
Sep 27 2017
next sibling parent DreadKyller <dreadkyller gmail.com> writes:
On Wednesday, 27 September 2017 at 21:01:36 UTC, Jesse Phillips 
wrote:

 For example, if you store your Matrix in a custom container it 
 could try to store pointer rather than the struct itself, if & 
 is overloaded the generic implementation would be broken 
 because it would no longer be a pointer to Matrix but to the 
 inner element.

 Whereas generic code which utilizes addition or append can 
 assume the type appropriately defined the behavior to 
 semantically match the desired use, generic code would be 
 broken if the type changed & to do something different from 
 what the language defines it to do.


Alright, that makes sense, that's some valid reasoning, I can 
accept that.
Sep 27 2017
prev sibling parent reply user1234 <user1234 12.hu> writes:
On Wednesday, 27 September 2017 at 21:01:36 UTC, Jesse Phillips 
wrote:

 On Wednesday, 27 September 2017 at 16:35:54 UTC, DreadKyller 
 wrote:

 My question is about overloading, several operators can be 
 overloaded in D, one of the ones that can't apparently is the 
 address of operator (&object). My question is have I simply 
 missed it or does it actually not exist, and if it's not 
 overloadable, is there any reason why this was decided? 
 Because there's been numerous times that it'd be useful to me, 
 just recently with how much I use the operator because of 
 OpenGL I decided to ask.


 My answer is that & is a defined operation on all addressable 
 memory. Unlike other operators which don't exist until you 
 "overload" them.


Yes but the dereference operator can be overloaded. The reasoning 
doesn't stand, unless that's recognized as an inconsistency.
Sep 27 2017
parent reply DreadKyller <dreadkyller gmail.com> writes:
On Wednesday, 27 September 2017 at 23:24:58 UTC, user1234 wrote:

 On Wednesday, 27 September 2017 at 21:01:36 UTC, Jesse Phillips 
 wrote:

 On Wednesday, 27 September 2017 at 16:35:54 UTC, DreadKyller 
 wrote:

 My question is about overloading, several operators can be 
 overloaded in D, one of the ones that can't apparently is the 
 address of operator (&object). My question is have I simply 
 missed it or does it actually not exist, and if it's not 
 overloadable, is there any reason why this was decided? 
 Because there's been numerous times that it'd be useful to 
 me, just recently with how much I use the operator because of 
 OpenGL I decided to ask.


 My answer is that & is a defined operation on all addressable 
 memory. Unlike other operators which don't exist until you 
 "overload" them.


 Yes but the dereference operator can be overloaded. The 
 reasoning doesn't stand, unless that's recognized as an 
 inconsistency.


Except that no it actually doesn't. The Unary operator * doesn't 
overload the dereferencing of a pointer, take the following code:

class Test
{
	Test opUnary(string s)() if (s == "*")
     {
		writeln("Overloaded operator called");
		return this;
     }
}
void testFunc()
{
	Test test = new Test();
	Test* test_ptr = &test;
	writeln("== *test ==");
	Test other = *test;
	writeln("== *test_ptr ==");
	other = *test_ptr;
	writeln("== end ==");
}

This outputs:

== *test ==
Overloaded operator called
== *test_ptr ==
== end ==

Notice how dereferencing the pointer did not call the overloaded 
function, because a pointer to Test is not the same type as a 
Test.
Sep 27 2017
parent reply user1234 <user1234 12.hu> writes:
On Thursday, 28 September 2017 at 00:11:56 UTC, DreadKyller wrote:

 On Wednesday, 27 September 2017 at 23:24:58 UTC, user1234 wrote:
 Notice how dereferencing the pointer did not call the 
 overloaded function, because a pointer to Test is not the same 
 type as a Test.


Yeah, this is rather made to implement fat pointers.
Sep 28 2017
parent reply DreadKyller <dreadkyller gmail.com> writes:
On Thursday, 28 September 2017 at 14:01:33 UTC, user1234 wrote:

 On Thursday, 28 September 2017 at 00:11:56 UTC, DreadKyller 
 wrote:

 Notice how dereferencing the pointer did not call the 
 overloaded function, because a pointer to Test is not the same 
 type as a Test.


 Yeah, this is rather made to implement fat pointers.


I understand that, but because the operator isn't defined 
normally for classes unless overloaded, then your statement about 
this being an inconsistency on the concerns stated prior about 
wrecking implementation of standard features. If & can't be 
overloaded then the type of &object will always be a pointer, you 
can't override the dereference operator of the pointer itself as 
far as I can tell, overloading it on the class doesn't overload 
the pointer, thus any standard implementation that uses pointers 
to store an object would be completely unaffected by overloading 
the dereference operator. This I don't consider it an 
inconsistency.

Also Johnathan, yeah, the forum.dlang.org is the same for me as 
kinke said, most the time it goes thorugh nearly immediately, but 
sometimes (about 1/4'th) it takes multiple minutes. The thing is 
that I can open 3 tabs all loading the same page, on multiple web 
browsers, and they'll all stall, then suddenly all of them load 
at the same time. If it persists I may ry making a post as you 
suggested.
Sep 28 2017
parent reply Mengu <mengukagan gmail.com> writes:
On Friday, 29 September 2017 at 02:34:08 UTC, DreadKyller wrote:

 On Thursday, 28 September 2017 at 14:01:33 UTC, user1234 wrote:

 [...]


 I understand that, but because the operator isn't defined 
 normally for classes unless overloaded, then your statement 
 about this being an inconsistency on the concerns stated prior 
 about wrecking implementation of standard features. If & can't 
 be overloaded then the type of &object will always be a 
 pointer, you can't override the dereference operator of the 
 pointer itself as far as I can tell, overloading it on the 
 class doesn't overload the pointer, thus any standard 
 implementation that uses pointers to store an object would be 
 completely unaffected by overloading the dereference operator. 
 This I don't consider it an inconsistency.

 [...]


+1 for forum issue.
Sep 29 2017
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 29 September 2017 at 22:15:44 UTC, Mengu wrote:

 On Friday, 29 September 2017 at 02:34:08 UTC, DreadKyller wrote:

 [...]


 +1 for forum issue.


+1 please...
Sep 30 2017
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/27/17 12:35 PM, DreadKyller wrote:

 Been using D for a couple years now, however one problem I've had, more 
 so recently since I've been dealing a lot with OpenGL is related to 
 pointers.
 
 I have a matrix object to aid with the matrix math required for working 
 with 3D transforms. However OpenGL (I'm using DerelictGL3 bindings) 
 requires pointers to the data. I am currently doing the following:
 
 Matrix!float ortho(float l, float r, float b, float t, float f, float n 
 = -1)
 {
      Matrix!float oMat = identity(); // Get default Identity Matrix
 
      oMat[0,0] =  2 / (r - l);
      oMat[1,1] =  2 / (t - b);
      oMat[2,2] = -2 / (f - n);
 
      oMat[3] = [-(r+l)/(r-l), -(t+b)/(t-b), -(f+n)/(f-n), 1];
 
      return oMat;
 }
 
 And then to use with OpenGL (passing as uniform into shader):
 
 glUniformMatrix4fv(transform_uniform, 1, GL_FALSE, matrix.addr );
 
 where addr is a property that returns the address of the first item in 
 the Matrix's internal data. I know I can also use &matrix[0][0]


This is what I would do. For each prototype that takes a matrix pointer, 
I would create an overloaded prototype that takes a pointer to your 
matrix type instead. The overloaded prototype would then simply call the 
real function with the matrix.addr property.

Using metaprogramming, you could probably generate this based on the 
current opengl module.

Then your ported code doesn't need to change.

-Steve
Sep 28 2017