On Monday, 8 June 2015 at 09:54:28 UTC, Kagamin wrote:
On Sunday, 7 June 2015 at 17:41:11 UTC, Kyoji Klyden wrote:
Do you perchance have any links to learning resources for the
D runtime(aside from just the github repository), and also
maybe x86 architecture stuff? (I know intel has some 1000+
On Sunday, 7 June 2015 at 17:41:11 UTC, Kyoji Klyden wrote:
Do you perchance have any links to learning resources for the D
runtime(aside from just the github repository), and also maybe
x86 architecture stuff? (I know intel has some 1000+ page pdf
on their site, but I think that's more for har
On Saturday, 6 June 2015 at 18:43:08 UTC, Marc Schütz wrote:
_d_arraybounds() always throws an error because that's its
purpose. It's implemented here:
https://github.com/D-Programming-Language/druntime/blob/master/src/core/exception.d#L640
My point was that _d_arraybounds never returns, inst
On Friday, 5 June 2015 at 19:18:39 UTC, anonymous wrote:
If you have a pointer to such a sequence, and you know the
number of elements (or what element is last), then you can
access them all.
I never really worked with C or C++, but I'm sure you also need
to know element size.
On Saturday, 6 June 2015 at 17:31:15 UTC, Kyoji Klyden wrote:
On Saturday, 6 June 2015 at 10:12:54 UTC, Marc Schütz wrote:
...
Almost correct :-) The part of "has nothing left, so go back"
is wrong. The call to _d_arraybounds doesn't return, because
it throws an Error.
...
Yes, inside t
On Saturday, 6 June 2015 at 10:12:54 UTC, Marc Schütz wrote:
...
Almost correct :-) The part of "has nothing left, so go back"
is wrong. The call to _d_arraybounds doesn't return, because it
throws an Error.
...
Yes, inside the `f` function, the compiler cannot know the
length of the ar
On Friday, 5 June 2015 at 19:19:23 UTC, Kyoji Klyden wrote:
On Friday, 5 June 2015 at 18:30:53 UTC, Kagamin wrote:
Well, reading assembler is good enough:
void f(int[] a)
{
a[0]=0;
a[1]=1;
a[2]=2;
}
Here pointer is passed in rsi register and length - in rdi:
void f(int[]):
push
On Friday, 5 June 2015 at 19:41:03 UTC, anonymous wrote:
On Friday, 5 June 2015 at 19:30:58 UTC, Kyoji Klyden wrote:
Okay, so it's primarily an interfacing with C problem that
started all this? (My brain is just completely scrambled at
this point xP )
Yeah, you wanted to call glShaderSource,
On Friday, 5 June 2015 at 19:30:58 UTC, Kyoji Klyden wrote:
Okay, so it's primarily an interfacing with C problem that
started all this? (My brain is just completely scrambled at
this point xP )
Yeah, you wanted to call glShaderSource, which is a C function
and as such it's not aware of D sli
On Friday, 5 June 2015 at 19:18:39 UTC, anonymous wrote:
On Friday, 5 June 2015 at 17:27:18 UTC, Kyoji Klyden wrote:
On Thursday, 4 June 2015 at 22:28:50 UTC, anonymous wrote:
[...]
By the way, there are subtly different meanings of "array"
and "string" which I hope you're aware of, but just t
On Friday, 5 June 2015 at 17:27:18 UTC, Kyoji Klyden wrote:
On Thursday, 4 June 2015 at 22:28:50 UTC, anonymous wrote:
[...]
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 poin
On Friday, 5 June 2015 at 18:30:53 UTC, Kagamin wrote:
Well, reading assembler is good enough:
void f(int[] a)
{
a[0]=0;
a[1]=1;
a[2]=2;
}
Here pointer is passed in rsi register and length - in rdi:
void f(int[]):
pushrax
testrdi, rdi
je .LBB0_4
Well, reading assembler is good enough:
void f(int[] a)
{
a[0]=0;
a[1]=1;
a[2]=2;
}
Here pointer is passed in rsi register and length - in rdi:
void f(int[]):
pushrax
testrdi, rdi
je .LBB0_4
mov dword ptr [rsi], 0
cmp rdi, 1
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
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
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
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:/
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 +, 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 a
On Thursday, 4 June 2015 at 03:25:24 UTC, ketmar wrote:
On Wed, 03 Jun 2015 11:59:56 +, 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
On Wed, 03 Jun 2015 11:59:56 +, 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
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 y
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
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 a
On Wednesday, 3 June 2015 at 11:28:14 UTC, anonymous wrote:
On Wednesday, 3 June 2015 at 11:23:09 UTC, Kyoji Klyden wrote:
Ooooh okay, I'm starting to get it. I think this last question
should clear it up for me: When a string is made, how is the
struct Slice handled? What does ptr get assigned
On Wednesday, 3 June 2015 at 11:23:09 UTC, Kyoji Klyden wrote:
Ooooh okay, I'm starting to get it. I think this last question
should clear it up for me: When a string is made, how is the
struct Slice handled? What does ptr get assigned?
ptr is a pointer to the first char, in other words the ad
Ooooh okay, I'm starting to get it. I think this last question
should clear it up for me: When a string is made, how is the
struct Slice handled? What does ptr get assigned?
On Wednesday, 3 June 2015 at 10:56:21 UTC, Kyoji Klyden wrote:
So in "const char* sources = source.ptr;" sources is just
turning the property ptr of source into a variable,
yes
and then in glShaderSource you're passing the memory address of
sources
yes
(which is technically source.ptr)
On Wednesday, 3 June 2015 at 10:21:20 UTC, Kyoji Klyden wrote:
On Wednesday, 3 June 2015 at 08:11:16 UTC, Kagamin wrote:
On Tuesday, 2 June 2015 at 16:41:38 UTC, Kyoji Klyden wrote:
[...]
string source = readText("test.glvert");
const char* sources = source.ptr;
[...]
On Wednesday, 3 June 2015 at 10:28:50 UTC, Marc Schütz wrote:
A string (or any other array slice for that matter) is
internally the equivalent of:
struct Slice(T) {
T* ptr;
size_t length;
}
(maybe the order of fields is different, I never remember that
part)
`&sour
On Wednesday, 3 June 2015 at 10:21:20 UTC, Kyoji Klyden wrote:
On Wednesday, 3 June 2015 at 08:11:16 UTC, Kagamin wrote:
On Tuesday, 2 June 2015 at 16:41:38 UTC, Kyoji Klyden wrote:
src:
string source = readText("test.glvert");
const string sources = source.toStringz;
On Wednesday, 3 June 2015 at 08:11:16 UTC, Kagamin wrote:
On Tuesday, 2 June 2015 at 16:41:38 UTC, Kyoji Klyden wrote:
src:
string source = readText("test.glvert");
const string sources = source.toStringz;
const int len = source.length;
GLuint ve
On Tuesday, 2 June 2015 at 16:41:38 UTC, Kyoji Klyden wrote:
src:
string source = readText("test.glvert");
const string sources = source.toStringz;
const int len = source.length;
GLuint vertShader = glCreateShader( GL_VERTEX_SHADER );
On Tuesday, 2 June 2015 at 17:03:32 UTC, Alex Parrill wrote:
On Tuesday, 2 June 2015 at 16:41:38 UTC, Kyoji Klyden wrote:
src:
string source = readText("test.glvert");
const string sources = source.toStringz;
const int len = source.length;
GLuin
On Tuesday, 2 June 2015 at 16:41:38 UTC, Kyoji Klyden wrote:
src:
string source = readText("test.glvert");
const string sources = source.toStringz;
const int len = source.length;
GLuint vertShader = glCreateShader( GL_VERTEX_SHADER );
On Tuesday, 2 June 2015 at 16:26:30 UTC, Alex Parrill wrote:
On Tuesday, 2 June 2015 at 16:23:26 UTC, Kyoji Klyden wrote:
On Tuesday, 2 June 2015 at 15:53:33 UTC, Alex Parrill wrote:
On Tuesday, 2 June 2015 at 15:07:58 UTC, Kyoji Klyden wrote:
quick question: What is the most efficient way to c
On Tuesday, 2 June 2015 at 16:23:26 UTC, Kyoji Klyden wrote:
On Tuesday, 2 June 2015 at 15:53:33 UTC, Alex Parrill wrote:
On Tuesday, 2 June 2015 at 15:07:58 UTC, Kyoji Klyden wrote:
quick question: What is the most efficient way to covert a
string to a char array?
A string is, by definition
On Tuesday, 2 June 2015 at 15:53:33 UTC, Alex Parrill wrote:
On Tuesday, 2 June 2015 at 15:07:58 UTC, Kyoji Klyden wrote:
quick question: What is the most efficient way to covert a
string to a char array?
A string is, by definition in D, a character array,
specifically `immutable(char)[]`. It
On Tuesday, 2 June 2015 at 15:53:33 UTC, Alex Parrill wrote:
A string is, by definition in D, a character array,
specifically `immutable(char)[]`. It's not like, for example,
Java in which it's a completely separate type; you can perform
all the standard array operations on strings.
Yes, I be
On Tuesday, 2 June 2015 at 15:07:58 UTC, Kyoji Klyden wrote:
quick question: What is the most efficient way to covert a
string to a char array?
A string is, by definition in D, a character array, specifically
`immutable(char)[]`. It's not like, for example, Java in which
it's a completely sep
On Tuesday, 2 June 2015 at 15:32:12 UTC, Kyoji Klyden wrote:
On Tuesday, 2 June 2015 at 15:26:50 UTC, Dennis Ritchie wrote:
On Tuesday, 2 June 2015 at 15:07:58 UTC, Kyoji Klyden wrote:
quick question: What is the most efficient way to covert a
string to a char array?
string s = "str";
char[]
On Tuesday, 2 June 2015 at 15:26:50 UTC, Dennis Ritchie wrote:
On Tuesday, 2 June 2015 at 15:07:58 UTC, Kyoji Klyden wrote:
quick question: What is the most efficient way to covert a
string to a char array?
string s = "str";
char[] strArr = s.dup;
Thanks! :)
On Tuesday, 2 June 2015 at 15:07:58 UTC, Kyoji Klyden wrote:
quick question: What is the most efficient way to covert a
string to a char array?
string s = "str";
char[] strArr = s.dup;
quick question: What is the most efficient way to covert a string
to a char array?
43 matches
Mail list logo
