On Wednesday, 3 June 2015 at 10:21:20 UTC, Kyoji Klyden wrote:
> Also the one part I don't understand is with &sources. So is this passing sources as a reference, but sources itself is a pointer to a pointer? I'm just a tad confused on how this part works :S

For some weird reason the function accepts an array of strings for shader source instead of one string. In C speak char* is a string, char** is an array of strings - that's passed to the function.

On Wednesday, 3 June 2015 at 11:46:25 UTC, Kagamin wrote:
> On Wednesday, 3 June 2015 at 10:21:20 UTC, Kyoji Klyden wrote:
>> Also the one part I don't understand is with &sources. So is this passing sources as a reference, but sources itself is a pointer to a pointer? I'm just a tad confused on how this part works :S
>
> For some weird reason the function accepts an array of strings for shader source instead of one string. In C speak char* is a string, char** is an array of strings - that's passed to the function.

That's what I found so confusing about the opengl docs. Just guessing here but char* is a pointer to the first char in the string, then what exactly is char**? Is it pointing to the first char of the first string in an array?

Does C/D just scrub through memory until it finds the end of an array? Also what signifies an end of array, or any other keypoints?

aaaaahh I have so many questions O_o

On Wednesday, 3 June 2015 at 11:59:56 UTC, Kyoji Klyden wrote:
> That's what I found so confusing about the opengl docs. Just guessing here but char* is a pointer to the first char in the string, then what exactly is char**? Is it pointing to the first char of the first string in an array?

If you use a pointer for a string, you can have an array of such pointers as array of strings, then char** would point to the first pointer in that array.

> Does C/D just scrub through memory until it finds the end of an array? Also what signifies an end of array, or any other keypoints?

C has various conventions to indicate the length, this function uses three conventions simultaneously, so you can choose, which suits you the best.

On Wed, 03 Jun 2015 11:59:56 +0000, Kyoji Klyden wrote:

> That's what I found so confusing about the opengl docs. Just guessing here but char* is a pointer to the first char in the string, then what exactly is char**? Is it pointing to the first char of the first string in an array?

it's a pointer to array of pointers to first chars of strings. ;-)

On Thursday, 4 June 2015 at 03:25:24 UTC, ketmar wrote:
> On Wed, 03 Jun 2015 11:59:56 +0000, Kyoji Klyden wrote:
>
>> That's what I found so confusing about the opengl docs. Just guessing
>> here but char* is a pointer to the first char in the string, then what
>> exactly is char**? Is it pointing to the first char of the first string
>> in an array?
>
> it's a pointer to array of pointers to first chars of strings. ;-)

Ohh okay. So this is how the function is able to take multiple strings then..
How was I supposed to know it was an array though? Is it because it was a string type pointer?

Also does D primarily use explicit length field strings?

Thanks!

On Thursday, 4 June 2015 at 21:35:40 UTC, Kyoji Klyden wrote:
> On Thursday, 4 June 2015 at 03:25:24 UTC, ketmar wrote:
>> On Wed, 03 Jun 2015 11:59:56 +0000, Kyoji Klyden wrote:
>>
[...]
>>> what
>>> exactly is char**? Is it pointing to the first char of the first string
>>> in an array?
>>
>> it's a pointer to array of pointers to first chars of strings. ;-)
>
> Ohh okay. So this is how the function is able to take multiple strings then..
> How was I supposed to know it was an array though? Is it because it was a string type pointer?

Generally, a `char**` is a pointer to a pointer to a char. There may be more pointers to chars behind the pointed-to one. And there may be more chars behind the pointed-to ones. You can't know just from the type. You have to read the documentation of the involved functions for the specifics.

> Also does D primarily use explicit length field strings?

I'm not sure if I understand you right, but yes, D arrays carry their length. And D `string`s are arrays. You should encounter things like `char**` pretty much only when talking to C code.

By the way, there are subtly different meanings of "array" and "string" which I hope you're aware of, but just to be sure:
"array" can refer to D array types, i.e. a pointer-length pair, e.g. char[]. Or it can refer to the general concept of a contiguous sequence of elements in memory.
And as a special case, "string" can refer to D's `string` type, which is an alias for `immutable(char)[]`. Or it can refer to a contiguous sequence of characters in memory.
And when ketmar writes: "it's a pointer to array of pointers to first chars of strings", then "array" and "string" are meant in the generic way, not in the D-specific way.

On 06/04/2015 03:28 PM, anonymous wrote:

> Generally, a `char**` is a pointer to a pointer to a char. There may be
> more pointers to chars behind the pointed-to one. And there may be more
> chars behind the pointed-to ones. You can't know just from the type.

Yep, "C's biggest mistake":


http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625

Ali

On Thursday, 4 June 2015 at 22:28:50 UTC, anonymous wrote:
>
> Generally, a `char**` is a pointer to a pointer to a char. There may be more pointers to chars behind the pointed-to one. And there may be more chars behind the pointed-to ones. You can't know just from the type. You have to read the documentation of the involved functions for the specifics.
>

Alright, kinda a bummer I need to do some digging for each third-party function I use, but oh well.
This probably comes from lack of experience but I can't really imagine ever writing something that is more than one or two pointers long.. like wouldn't that call for a redesign of whatever library was being written?



On Thursday, 4 June 2015 at 22:33:13 UTC, Ali Çehreli wrote:
>
> Yep, "C's biggest mistake":
>
>
> http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625
>
> Ali

Thx for the link. I think I read this a couple years ago, but at the time had no idea what Walter was talking about. (probably because I was only using Python back when I read it)


>> Also does D primarily use explicit length field strings?
>
> I'm not sure if I understand you right, but yes, D arrays carry their length. And D `string`s are arrays. You should encounter things like `char**` pretty much only when talking to C code.
>
> By the way, there are subtly different meanings of "array" and "string" which I hope you're aware of, but just to be sure:
> "array" can refer to D array types, i.e. a pointer-length pair, e.g. char[]. Or it can refer to the general concept of a contiguous sequence of elements in memory.
> And as a special case, "string" can refer to D's `string` type, which is an alias for `immutable(char)[]`. Or it can refer to a contiguous sequence of characters in memory.
> And when ketmar writes: "it's a pointer to array of pointers to first chars of strings", then "array" and "string" are meant in the generic way, not in the D-specific way.

Yeah that's what I meant. I just got the phrasing for that out of a compiler book I have.
I now see alot of my confusion is coming from me poorly assuming C, D, and sometimes C++ are functioning/handling data the same way. Clearly there's more to it than simply ProgrammingLanguage->IR->MachineCode (obviously to horribly simplify it).

So how does D store arrays in memory then?

I know you already explained this part, but..
Does the slice's pointer point to the slice's position in memory? Then if an array isn't sequential, is it atleast a sequence of pointers to the slice structs (& those are just in whatever spot in memory they could get?)
There's a slice for each array index..right? Or is it only for the first element?

Thanks!

On Friday, 5 June 2015 at 17:27:18 UTC, Kyoji Klyden wrote:
> Does the slice's pointer point to the slice's position in memory? Then if an array isn't sequential, is it atleast a sequence of pointers to the slice structs (& those are just in whatever spot in memory they could get?)

BTW, try to write in assembler, it will give you perfect understanding of all things like memory layout, calling conventions, alignment etc :3

On Friday, 5 June 2015 at 18:06:25 UTC, Kagamin wrote:
> On Friday, 5 June 2015 at 17:27:18 UTC, Kyoji Klyden wrote:
>> Does the slice's pointer point to the slice's position in memory? Then if an array isn't sequential, is it atleast a sequence of pointers to the slice structs (& those are just in whatever spot in memory they could get?)
>
> BTW, try to write in assembler, it will give you perfect understanding of all things like memory layout, calling conventions, alignment etc :3

I did a tiny bit before actually, but I wanna go back to it once I have the time soooo bad (it's pretty high up on my to-do list). I think it's really fun :D