On Thursday, 26 January 2017 at 05:58:26 UTC, Profile Anaysis
wrote:
Since we do not have attributes for enums, I use _ in front of
the names for meta values.
[...]
This can be done with Ctfe mixins and __traits,
look at __traits(allMembers)
Since we do not have attributes for enums, I use _ in front of
the names for meta values.
I need to get the non-meta values for the enum so I can iterate
over it and use it properly.
enum myEnum
{
_Meta1 = 0,
A,B,C,
_Meta3 = 43,
D = 3,
}
The num, for all practical purposes
On Thursday, 26 January 2017 at 03:02:32 UTC, Jonathan M Davis
wrote:
On Thursday, January 26, 2017 01:47:53 Profile Anaysis via
Digitalmars-d- learn wrote:
[...]
Like in C/C++, types are mostly read outward from the variable
name in D. In both C/C++ and D,
[...]
Actually, I think
On Thursday, 26 January 2017 at 03:02:32 UTC, Jonathan M Davis
wrote:
On Thursday, January 26, 2017 01:47:53 Profile Anaysis via
Digitalmars-d- learn wrote:
[...]
Like in C/C++, types are mostly read outward from the variable
name in D. In both C/C++ and D,
[...]
Thanks. I'll just
On Thursday, 26 January 2017 at 02:29:07 UTC, Ivan Kazmenko wrote:
On Thursday, 26 January 2017 at 01:47:53 UTC, Profile Anaysis
wrote:
does this mean that have
int[][4][4] matrix_history;
backwards?
int[4][4][] matrix_history;
this creates even a more set of problems.
In short,
On Thursday, 26 January 2017 at 01:58:51 UTC, Adam Wilson wrote:
I'd recommend VSCode with Code-D works very well for me.
https://github.com/Pure-D/code-d
And with Microsoft C++ tools (ms-vscode.cpptools) it can debug D
too with x64 or -m32mscoff
On Thursday, January 26, 2017 01:47:53 Profile Anaysis via Digitalmars-d-
learn wrote:
> I'm a bit confused by how D does arrays.
>
> I would like to create a array of matrices but I do not seem to
> get the correct behavior:
>
> int[][4][4] matrix_history;
Like in C/C++, types are mostly
On Thursday, 26 January 2017 at 01:47:53 UTC, Profile Anaysis
wrote:
does this mean that have
int[][4][4] matrix_history;
backwards?
int[4][4][] matrix_history;
this creates even a more set of problems.
In short, you are right, `int[4][4][]` is a dynamic array of
`int[4][4]`. In
I was trying to figure out why calling an object's function from
a wndProc that modified the object's state didn't actually change
anything. Wrapping the GetWindowLongPtr in a cast(void*) seems to
make it work. What am I missing about this? I though that object
references were really just
On 1/25/17 5:22 PM, Lucas wrote:
On Wednesday, 25 January 2017 at 23:00:05 UTC, James Buren wrote:
On Wednesday, 25 January 2017 at 22:37:30 UTC, Lucas wrote:
[...]
Most likely, you are dealing with this issue:
https://github.com/aBothe/Mono-D/issues/648
MonoDevelop 5.x is the latest
I'm a bit confused by how D does arrays.
I would like to create a array of matrices but I do not seem to
get the correct behavior:
int[][4][4] matrix_history;
What I would like is to have a 4x4 matrix and have a history of
it. Just n 4x4 matrices but each matrix is a fixed size but
On Wednesday, 25 January 2017 at 23:00:05 UTC, James Buren wrote:
On Wednesday, 25 January 2017 at 22:37:30 UTC, Lucas wrote:
[...]
Most likely, you are dealing with this issue:
https://github.com/aBothe/Mono-D/issues/648
MonoDevelop 5.x is the latest version supported. They haven't
On Tuesday, 24 January 2017 at 12:01:35 UTC, Jonathan M Davis
wrote:
So, while it makes sense to say that .ptr can't be used in
@safe code, it really doesn't make sense to suggest [0] as
an alternative.
- Jonathan M Davis
Sure I see your point. But I feel like deprecations should also
list
On Wednesday, 25 January 2017 at 22:59:55 UTC, Jonathan M Davis
wrote:
Yes, but my point is that you're normally only going to use
.ptr to pass something to a C function, and even if you're
doing more with it in D, odds are, you're going to be doing
pointer arithmetic.
Wrong again. If this
On Wednesday, 25 January 2017 at 23:09:11 UTC, David Nadlinger
wrote:
This is a fallacy:
Ah, yes indeed, that was mentioned earlier in the thread too, it
just slipped my mind again.
On Wednesday, 25 January 2017 at 22:54:32 UTC, Adam D. Ruppe
wrote:
On Wednesday, 25 January 2017 at 22:46:10 UTC, David Nadlinger
wrote:
This is because every pointer in SafeD is dereferencable.
But null pointers are allowed in SafeD and arr.ptr is either
arr[0] or null
This is a
On Wednesday, 25 January 2017 at 18:12:18 UTC, Jonathan M Davis
wrote:
Fine, but in the vast majority of cases, you're calling .ptr,
because you're going to be passing the pointer to C code, in
which case, doing [0] buys you very little, since the C
code is inevitably going to be reading more
On Wednesday, 25 January 2017 at 22:37:30 UTC, Lucas wrote:
Looking forward to get back to programming in D, I went to set
up to my favorite environment: Mono D. After lots of download,
Mono, Gtk#, MSBuild tools, VS 13 commnunity... I get an error
saying it won't load my D language binding
On Wednesday, January 25, 2017 22:46:10 David Nadlinger via Digitalmars-d-
learn wrote:
> On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis
>
> wrote:
> > It seems _slightly_ better from a safety perspective but only
> > slightly.
>
> Wrong – one is correct, the other is not. This is
On Wednesday, 25 January 2017 at 22:46:10 UTC, David Nadlinger
wrote:
This is because every pointer in SafeD is dereferencable.
But null pointers are allowed in SafeD and arr.ptr is either
arr[0] or null
On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis
wrote:
It seems _slightly_ better from a safety perspective but only
slightly.
Wrong – one is correct, the other is not. This is because every
pointer in SafeD is dereferencable. Pointer arithmetic is not
allowed in SafeD, so your
Looking forward to get back to programming in D, I went to set up
to my favorite environment: Mono D. After lots of download, Mono,
Gtk#, MSBuild tools, VS 13 commnunity... I get an error saying it
won't load my D language binding because my current Mono version
is higher than D language
On Wednesday, 25 January 2017 at 21:04:50 UTC, Adam D. Ruppe
wrote:
On Wednesday, 25 January 2017 at 20:42:52 UTC, bitwise wrote:
Is it not possible to return a ref from an inout function?
It isn't the inout that's getting you, it is the const object
in main().
const(List!int) c;
Make
On Wednesday, 25 January 2017 at 20:42:52 UTC, bitwise wrote:
Is it not possible to return a ref from an inout function?
It isn't the inout that's getting you, it is the const object in
main().
const(List!int) c;
Make that mutable and it works. Why? Cuz the `C list` in the
iterator
On Tuesday, 24 January 2017 at 11:46:47 UTC, Jonathan M Davis
wrote:
On Monday, January 23, 2017 22:26:58 bitwise via
Digitalmars-d-learn wrote:
[...]
Moving structs is fine. The postblit constructor is for when
they're copied. A copy is unnecessary if the original isn't
around anymore -
Compiling the code below gives these errors:
main.d(92): Error:
cast(inout(int))this.list.data[cast(uint)(this.pos + i)] is not
an lvalue
main.d(101): Error: template instance
main.Iterator!(const(List!int)) error instantiating
main.d(108): instantiated from here: first!(const(List!int))
On Wednesday, January 25, 2017 10:52:51 Kagamin via Digitalmars-d-learn
wrote:
> On Tuesday, 24 January 2017 at 12:01:35 UTC, Jonathan M Davis
>
> wrote:
> > So, while it makes sense to say that .ptr can't be used in
> > @safe code, it really doesn't make sense to suggest [0] as
> > an
On Tuesday, 24 January 2017 at 22:53:14 UTC, bachmeier wrote:
On Tuesday, 24 January 2017 at 20:15:38 UTC, Dlearner wrote:
[...]
This sounds like exactly what you want:
https://www.packtpub.com/application-development/d-cookbook
It's not on sale right now, but if you've got the money, it's
On Tuesday, 24 January 2017 at 23:25:12 UTC, Profile Anaysis
wrote:
I am trying to compile some code and it takes around 6 seconds.
Even if I change one line in one module, it takes the same
time. There are about 20 different d modules.
[...]
yes the compiler can be used to profile itself.
On Tuesday, 24 January 2017 at 12:01:35 UTC, Jonathan M Davis
wrote:
So, while it makes sense to say that .ptr can't be used in
@safe code, it really doesn't make sense to suggest [0] as
an alternative.
When you ensure pointers point to existing data, you can
dereference them in safe code,
30 matches
Mail list logo
