On Saturday, 4 May 2019 at 15:36:51 UTC, Nicholas Wilson wrote:
On Saturday, 4 May 2019 at 15:18:58 UTC, Random D user wrote:
I wanted to make a 2D array like structure and support D slice
like operations,
but I had surprisingly bad experience.
The de facto multi dimensional array type in D
On Saturday, 4 May 2019 at 16:10:36 UTC, Adam D. Ruppe wrote:
On Saturday, 4 May 2019 at 15:18:58 UTC, Random D user wrote:
But array copy and setting/clearing doesn't:
int[] bar = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
14, 15 ];
foo[] = bar[];
Generally speaking, opIndex is for
I wanted to make a 2D array like structure and support D slice
like operations,
but I had surprisingly bad experience.
I quickly copy pasted the example from the docs:
https://dlang.org/spec/operatoroverloading.html#array-ops
It's something like this:
struct Array2D(E)
{
E[] impl;
On Friday, 29 December 2017 at 12:03:59 UTC, Mike Franklin wrote:
In C#, structs can inherit from and implement interfaces.
Is that simply because it hasn't been implemented or suggested
yet for D, or was there a deliberate design decision?
Thanks for your insight,
Mike
I think it's
On Sunday, 12 March 2017 at 01:55:20 UTC, ketmar wrote:
Random D user wrote:
How come string* suddenly has a .length property?
due to automatic pointer dereferencing that `.` does. no, not a
bug.
Ah... right. Silly me. Of course, since string is actually
immutable(char)[].
That's bit of
int*[] foo;
foo.length = 5;
import std.c.string;
int* baz = cast(string*)malloc(50);
import std.c.stdio;
printf("%d %d", foo.length, baz.length );
prints:
Error: no property 'length' for type 'int*'
BUT:
string*[] foo;
foo.length = 5;
import std.c.string;
string* baz =
I can init a variable from mutable source without defining any
constructor or assignment operators, but not if the source is
const. I would imagine the behavior to be the same with mutable
and const source, since it's just reading the source and copying
it.
Is there a reason for this? Or is
On Saturday, 11 June 2016 at 20:30:47 UTC, Basile B. wrote:
On Saturday, 11 June 2016 at 19:45:56 UTC, Random D user wrote:
Any good ideas how to do that?
I couldn't figure it out in a short amount of time, but I
expect that it's possible. I'm probably missing something
obvious here.
Any good ideas how to do that?
I couldn't figure it out in a short amount of time, but I expect
that it's possible. I'm probably missing something obvious here.
Probably because D's reflection/meta programming facilities are a
bit all over the place (and unnecessarily convoluted IMO).
Also
On Tuesday, 8 December 2015 at 11:04:49 UTC, Random D user wrote:
I need to look into this more.
Ok. This is minimal app that crashes for me. If someone could try
this:
class App
{
this()
{
}
void crash( int val )
in
{
assert( val == 1 );
}
body
On Tuesday, 8 December 2015 at 01:23:40 UTC, Ivan Kazmenko wrote:
On Monday, 7 December 2015 at 22:03:42 UTC, Alex Parrill wrote:
On Monday, 7 December 2015 at 18:48:18 UTC, Random D user
Tested the same code with -m32 and -m64 on Windows. Works for
me, too.
I tried this again. And it seems
On Monday, 7 December 2015 at 20:03:07 UTC, Namespace wrote:
This seems to work:
struct RefVal(T) {
private T* ptr;
this(T* val) {
ptr = val;
}
ref auto opAssign(U)(auto ref U value) {
*ptr = value;
On Tuesday, 8 December 2015 at 10:26:18 UTC, Random D user wrote:
On Monday, 7 December 2015 at 20:03:07 UTC, Namespace wrote:
This seems to work:
struct RefVal(T) {
private T* ptr;
this(T* val) {
ptr = val;
}
ref auto
struct Foo
{
this( int k )
{
a = k;
}
int a;
}
Foo foo;
int[ Foo ] map;
map[ foo ] = 1; // Crash! bug?
// This also crashes. I believe crash above makes a call like
this (or similar) in the rt.
//auto h = typeid( foo ).getHash( ); // Crash!
win64 & dmd 2.69.2
I kind of miss reference values on stack, so I attempted to make
one in a struct.
Pointers are pretty good (since d doesn't have ->), but it would
be nice to avoid dereferencing them explicitly on assignment.
Since reference is a pointer that you can't change afterwards.
I tried something like
Ah missed your post before replying to H.S. Teoh (I should
refresh more often).
Thanks for reply.
On Thursday, 15 October 2015 at 19:50:27 UTC, Steven
Schveighoffer wrote:
Without more context, I would say no. assumeSafeAppend is an
assumption, and therefore unsafe. If you don't know what
Thanks for thorough answer.
On Thursday, 15 October 2015 at 18:46:22 UTC, H. S. Teoh wrote:
It adjusts the size of the allocated block in the GC so that
subsequent appends will not reallocate.
So how does capacity affect this? I mean what is exactly a GC
block here.
Shrink to fit bit
So I was doing some optimizations and I came up with couple basic
questions...
A)
What does assumeSafeAppend actually do?
A.1) Should I call it always if before setting length if I want
to have assumeSafeAppend semantics? (e.g. I don't know if it's
called just before the function I'm in)
A.2)
On Saturday, 19 September 2015 at 07:25:58 UTC, ponce wrote:
On Friday, 18 September 2015 at 22:54:43 UTC, Random D user
wrote:
So I tried to build my project in release for the first time
in a long while. It takes like 25x longer to compile and
finally the compiler crashes. It seems to go
On Saturday, 19 September 2015 at 21:48:25 UTC, Random D user
wrote:
Assertion failure: 'type->ty != Tstruct || ((TypeStruct
*)type)->sym == this' on line 957 in file 'struct.c'
Ok managed to reduce this one to my own copy paste bug. This is
invalid code, but compiler shouldn't crash...
I'm
So I tried to build my project in release for the first time in a
long while. It takes like 25x longer to compile and finally the
compiler crashes. It seems to go away if I disable the optimizer.
I get:
tym = x1d
Internal error: backend\cgxmm.c 547
Does anyone have a clue what might trigger
I'm trying to make a base class with get property and a sub class
with corresponding set property. The value for the base class is
set via constructor.
The intuitive way doesn't seem to work and workarounds are
unnecessarily ugly (considering you'll sprinkle them all over the
codebase).
On Wednesday, 16 September 2015 at 03:17:05 UTC, Meta wrote:
Considering Father defines the function `int eat()` and
Daughter defines the completely different function `int
eat(int)`, it doesn't surprise me. You're not using virtual
dispatch when you do `return super.eat` or `d.Father.eat()`,
On Wednesday, 16 September 2015 at 03:54:34 UTC, Adam D. Ruppe
wrote:
On Wednesday, 16 September 2015 at 03:48:59 UTC, Random D user
Given that, normally properties are just overloaded methods in
D, it's pretty sad classes break this behavior/convention.
The D behavior for overloading is
On Saturday, 12 September 2015 at 18:28:02 UTC, Random D user
wrote:
or is it some obscure feature conflict?
[...]
Oh... and I'm using win 64-bit and dmd 2.068.1, but this behavior
was present earlier than that...
or is it some obscure feature conflict?
struct Foo
{
this( float x_, float y_ )
{
// option A
//x = x_;
//y = y_;
// option B
v[0] = x_;
v[1] = y_;
}
union
{
struct
{
float x = 0;
float
26 matches
Mail list logo
