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

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

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.

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.

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.

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...