Dne 14.2.2017 v 07:48 TheGag96 via Digitalmars-d-learn napsal(a):
https://dpaste.dzfl.pl/adc05892344f (btw, any reason why certificate
validation on dpaste fails right now?)
Because certificate is expired, dpaste use certs from Lets Encrypt which
has short time of validity
I have same issue
Tonight I stumbled upon Andrei's concept of policy-based design
(https://en.wikipedia.org/wiki/Policy-based_design) and tried to
implement their example in D with the lack of multiple
inheritance in mind.
https://dpaste.dzfl.pl/adc05892344f (btw, any reason why
certificate validation on
On Monday, 13 February 2017 at 22:59:11 UTC, John Colvin wrote:
[ snip ]
sorry, made a typo, that should have been
alias int1 = Initial!(int, 1);
static assert(int1.initial == 1); // typeof(int1.initial)
== int
static assert(int1.init == 1); // typeof(int1.init) == int1
On 02/13/2017 04:59 PM, David Zhang wrote:
I have a struct with two immutable members, and I want to make an array
of them. How do I to this? I'm using allocators for this.
I realize that I misunderstood you; see below for a mutable array.
The following code produces an immutable array
Hi,
I have a struct with two immutable members, and I want to make an
array of them. How do I to this? I'm using allocators for this.
string[] paths;
struct FileDesc {
immutable string path;
immutable uint index;
}
_fileDesc = /*something*/;
You can't use alloc.makeArray because it
On Monday, 13 February 2017 at 22:16:36 UTC, Bastiaan Veelo wrote:
On Monday, 13 February 2017 at 16:40:02 UTC, Daniel Kozak wrote:
https://dlang.org/phobos/std_typecons.html#.Typedef
Thanks for the pointers. Both Typedef and Proxy create types
that don't mix with the base type, which I want
On Monday, 13 February 2017 at 16:40:02 UTC, Daniel Kozak wrote:
https://dlang.org/phobos/std_typecons.html#.Typedef
Thanks for the pointers. Both Typedef and Proxy create types that
don't mix with the base type, which I want to the contrary. So I
guess I'll go with
struct Initial(T, T
On Monday, 13 February 2017 at 14:20:05 UTC, Kagamin wrote:
Thread unsafe methods shouldn't be marked shared, it doesn't
make sense. If you don't want to provide thread-safe interface,
don't mark methods as shared, so they will not be callable on a
shared instance and thus the user will be
Dne 13.2.2017 v 17:40 Daniel Kozak napsal(a):
Dne 13.2.2017 v 16:28 Bastiaan Veelo via Digitalmars-d-learn napsal(a):
Hi,
In Extended Pascal, you can derive from a basic type and change the
default initialiser like so:
type int1 = integer value 1;
var i : int1;
ii : int1 value
Dne 13.2.2017 v 16:28 Bastiaan Veelo via Digitalmars-d-learn napsal(a):
Hi,
In Extended Pascal, you can derive from a basic type and change the
default initialiser like so:
type int1 = integer value 1;
var i : int1;
ii : int1 value 2;
assert(i = 1);
assert(ii = 2);
I have it
Hi,
In Extended Pascal, you can derive from a basic type and change
the default initialiser like so:
type int1 = integer value 1;
var i : int1;
ii : int1 value 2;
assert(i = 1);
assert(ii = 2);
I have it working in D, but it seems a little clumsy. Is there a
better way?
On Sunday, 12 February 2017 at 20:08:05 UTC, bitwise wrote:
Given that both the data and the method are 'shared', a caller
should know that race conditions are possible and that they
should aquire a lock before accessing either of them...or so it
would seem.
Thread unsafe methods shouldn't
12 matches
Mail list logo
