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.

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.

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.

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.

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.

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)

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?

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.

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.

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