If I just type out sqrt(2.0) in D, is that automatically made
into a constant for me?
Thanks.
On Thursday, 11 February 2016 at 05:05:22 UTC, tsbockman wrote:
On Thursday, 11 February 2016 at 04:51:39 UTC, Matt Elkins
wrote:
- Syntactic sugars (associtive arrays, powerful foreach,
slices...)
I'm still adjusting to the idea of AAs as part of the language
rather than library. Not sure I
On Thursday, 11 February 2016 at 04:51:39 UTC, Matt Elkins wrote:
- Syntactic sugars (associtive arrays, powerful foreach,
slices...)
I'm still adjusting to the idea of AAs as part of the language
rather than library. Not sure I like it, but on the other hand
it doesn't really hurt. The forea
On Tuesday, 9 February 2016 at 13:41:30 UTC, NX wrote:
There are several reasons I want to use D rather than C# / Go /
something else:
I will focus on comparing against C++, because that has been my
favorite general purpose language for a long time. While I often
have to use C, Java, C#, etc.
On Thursday, 11 February 2016 at 04:31:12 UTC, cy wrote:
Oh, I get it. `as` is an array of 2 pointers to A objects, both
pointers set to null. So I need to say like:
as[0..$] = new A();
before accessing .stuff on as[0].
Pedantically, no. It's an array of two class references. I don't
thin
On Thursday, 11 February 2016 at 04:31:12 UTC, cy wrote:
as[0..$] = new A();
before accessing .stuff on as[0].
Loop through it and allocate each one rather than trying to do it
in a one liner like that.
Still no clue why it segfaulted on the allocation though,
rather than the statement wit
On Thursday, 11 February 2016 at 04:07:18 UTC, cy wrote:
A[] as = new A[2];
assert(as.length==2);
as[0].stuff = 42;
Oh, I get it. `as` is an array of 2 pointers to A objects, both
pointers set to null. So I need to say like:
as[0..$] = new A();
before accessing .stu
On Thursday, 11 February 2016 at 04:07:18 UTC, cy wrote:
The following program segfaults for me, compiling it with
dmdv2.070 as well as the latest git. I must be doing it wrong.
There's a way to specify class construction, or emplace, or
something. But I can't find it! How do I deal with arrays
On Thursday, 11 February 2016 at 03:09:51 UTC, rcorre wrote:
I recently tried compiling enumap with GDC, and found that it
disagrees with DMD on whether a function is @nogc. Here's a
semi-reduced test-case:
Here's an @nogc version of `byKeyValue()`:
@nogc auto byKeyValue() const {
static im
The following program segfaults for me, compiling it with
dmdv2.070 as well as the latest git. I must be doing it wrong.
There's a way to specify class construction, or emplace, or
something. But I can't find it! How do I deal with arrays of
objects?
class A {
int stuff;
}
void main(
On Thursday, 11 February 2016 at 03:47:09 UTC, Steven
Schveighoffer wrote:
Misunderstanding.
An AA under the hood is simply a pointer. Initialized to null.
When you pass it around, you are passing a pointer. AA assign
checks for null and allocates a new AA impl to hold the data.
But this does
On Wednesday, 10 February 2016 at 20:21:22 UTC, Chris Wright
wrote:
On Wed, 10 Feb 2016 08:57:51 +, thedeemon wrote:
Currently (at least last time I checked) GC pauses the world,
then does all the marking in one thread, then all the sweeping.
Right.
We can do the
marking in several para
On 2/10/16 10:10 PM, Matt Elkins wrote:
Consider the following definition of Foo and an accompanying unittest:
[code]
struct Foo
{
@property int[int] aa() {return m_aa;}
@property ref int[int] aaRef() {return m_aa;}
int[int] m_aa;
}
unittest
{
Foo foo;
assert(5 !in foo.
On Thursday, 11 February 2016 at 03:09:51 UTC, rcorre wrote:
GDC claims that byKeyValue() allocates a closure, but DMD is
just fine with me calling it @nogc. I'm inclined to agree with
GDC here, unless DMD is doing some magic so that actually
doesn't allocate a closure.
I cannot reproduce you
Consider the following definition of Foo and an accompanying
unittest:
[code]
struct Foo
{
@property int[int] aa() {return m_aa;}
@property ref int[int] aaRef() {return m_aa;}
int[int] m_aa;
}
unittest
{
Foo foo;
assert(5 !in foo.m_aa); // Sanity-check to start off
foo.a
I recently tried compiling enumap with GDC, and found that it
disagrees with DMD on whether a function is @nogc. Here's a
semi-reduced test-case:
---
import std.range;
import std.traits: EnumMembers;
import std.typecons : tuple, staticIota;
import std.algorithm : map;
struct Enumap(K, V)
On Wednesday, 10 February 2016 at 00:05:36 UTC, Peka wrote:
Hi!
I have class (or struct) which realises .length() and
.opIndex(size_t) methods.
It is possible to create from this class some sort of range
using template from std? (I mean that internal counter,
.popFront(), .empty() etc metho
On Wednesday, 10 February 2016 at 10:31:34 UTC, Voitech wrote:
Hi, why this is not working ?
class Base{
int a;
}
class BaseTemplate(E):Base{
E value;
this(E value){
this.value=value;
}
}
class Concrete:BaseTemplate!int{
this(int value){
On Wed, 10 Feb 2016 08:57:51 +, thedeemon wrote:
> Currently (at least last time I checked) GC pauses the world, then does
> all the marking in one thread, then all the sweeping.
Right.
> We can do the
> marking in several parallel threads (this is much harder to implement
> but still doable
On Tuesday, 9 February 2016 at 23:23:10 UTC, Jonathan M Davis
wrote:
On Tuesday, February 09, 2016 20:20:59 Suliman via
Digitalmars-d-learn wrote:
It's look like that I can only create one nesting level sub
folder, for example there is exists dir: D:\foo
I can't create dir D:\foo\bar\baz I can o
On Wednesday, 10 February 2016 at 07:20:03 UTC, Jakob Ovrum wrote:
You clearly didn't read the discussion in the link.
I did and I fully agree with jmdavis.
On Tuesday, 9 February 2016 at 21:03:34 UTC, anonymous wrote:
What's up with that garbled text?
https://issues.dlang.org/show_bug.cgi?id=2742
Hi, why this is not working ?
class Base{
int a;
}
class BaseTemplate(E):Base{
E value;
this(E value){
this.value=value;
}
}
class Concrete:BaseTemplate!int{
this(int value){
super(value);
}
}
unittest{
Alg
On Tuesday, 9 February 2016 at 17:41:34 UTC, NX wrote:
On Tuesday, 9 February 2016 at 14:35:48 UTC, Ola Fosheim
Grøstad wrote:
Not incredibly high level abstraction... But I get what you
mean. It is fairly high level for a low level language.
Coming from C#, it looks amazing but probably not t
On Tuesday, 9 February 2016 at 17:41:34 UTC, NX wrote:
I would want it to be solved rather than being worked on...
which requires design change which is probably not going to
happen. There is still room for improvement though.
Right. I think there are at least two things that can improve
cur
25 matches
Mail list logo
