On Saturday, 6 February 2016 at 14:15:04 UTC, rsw0x wrote:
I was playing around with alias templates and came across this,
I reduced it to:
---
struct A(alias C c){
auto foo(){
return c.i;
}
}
struct B{
C c;
A!c a;
}
struct C{
int i;
}
---
It gives me a "need 'this' for 'i' of
When I factor out code from my modules, it really, really often
leaves import statements that just sit there doing nothing,
making it look like my program is more complex than it is. How do
I get warned for leaving those, and a list of which ones I can
safely remove?
On Sunday, 7 February 2016 at 20:25:44 UTC, Minas Mina wrote:
Just noticed that there's no example.
It's used like
shared(ulong) a;
atomicOp!"+="(a, 1);
Wow, that syntax sucks a lot.
a.atomicOp!"+="(1);
sounds better. You can alias it too.
V Mon, 08 Feb 2016 08:25:09 +
cy via Digitalmars-d-learn napsáno:
> When I factor out code from my modules, it really, really often
> leaves import statements that just sit there doing nothing,
> making it look like my program is more complex than it is. How do
> I get warned for leaving t
On Monday, 8 February 2016 at 07:08:58 UTC, Voitech wrote:
On Saturday, 6 February 2016 at 23:35:17 UTC, Ali Çehreli wrote:
On 02/06/2016 10:05 AM, Voitech wrote:
> [...]
You can use string mixins (makeCtor and makeCtors):
string makeCtor(T)() {
import std.string : format;
[...]
Thank
On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
What language semantics prevent precise & fast GC
implementations?
Unions and easy type casting prevent precise GC.
Lack of write barriers for reference-type fields prevent fast
(generational and/or concurrent) GC. Some more detailed
ex
On Tuesday, 22 December 2015 at 11:42:42 UTC, bachmeier wrote:
1. Downloads of the DMD compiler have been fluctuating between
1000 and 1600 per day:
http://erdani.com/d/downloads.daily.png
To this you can add 75dl per day for ldc:
http://www.somsubhra.com/github-release-stats/?username=ldc-d
On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote:
http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html
Well, the latest Intel CPUs have a theoretical throughput of
30GB/s... so that makes for up to 30MB/ms.
But language changes are needed, I think.
I also don't
On Monday, 8 February 2016 at 08:25:09 UTC, cy wrote:
How do I get warned for leaving those, and a list of which ones
I can safely remove?
Remove one, recompile. If it passes, leave it. If not, undo and
move on to the next one.
http://dpaste.dzfl.pl/1f25ac34c1ee
You need Tuple, not Algebraic. Algebraic stores only one value of
one type from a set, like Variant.
On Monday, 8 February 2016 at 15:09:30 UTC, Kagamin wrote:
http://dpaste.dzfl.pl/1f25ac34c1ee
You need Tuple, not Algebraic. Algebraic stores only one value
of one type from a set, like Variant.
Thank you for answering. You right if i would want to store all
types of T.. in an Inner instance.
On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote:
On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
What language semantics prevent precise & fast GC
implementations?
Unions and easy type casting prevent precise GC.
Lack of write barriers for reference-type fields prevent fas
On Mon, 08 Feb 2016 11:22:45 +, thedeemon wrote:
> On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
>> What language semantics prevent precise & fast GC implementations?
>
> easy type casting prevent precise GC.
To expand on this point:
A GC makes a tradeoff between allocating effici
On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:
On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:
I see... By any chance, can we solve this issue with GC
managed pointers?
Maybe we could. But it's never going to happen. Even if
Walter weren't fundamentally opposed to multiple
On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:
I see... By any chance, can we solve this issue with GC managed
pointers?
Maybe we could. But it's never going to happen. Even if Walter
weren't fundamentally opposed to multiple pointer types in D, it
wouldn't happen.
You asked abou
On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:
Maybe we could. But it's never going to happen. Even if
Walter weren't fundamentally opposed to multiple pointer types
in D, it wouldn't happen.
You asked about things that prevent improvement, right? Here's
the big one, and a major
On 02/08/2016 06:35 AM, Adam D. Ruppe wrote:
On Monday, 8 February 2016 at 08:25:09 UTC, cy wrote:
How do I get warned for leaving those, and a list of which ones I can
safely remove?
Remove one, recompile. If it passes, leave it. If not, undo and move on
to the next one.
Similarly, I commen
On Thursday, 28 January 2016 at 04:26:26 UTC, Taylor Hillegeist
wrote:
Just curious... I had a thought that perhaps since Objective C
was a replacement for Pascal on the mac. that they might have
the same interface. but I'm not savvy enough with fpc to figure
out how to try it.
As said in the
On Monday, 8 February 2016 at 08:50:17 UTC, Daniel Kozak wrote:
V Mon, 08 Feb 2016 08:25:09 +
cy via Digitalmars-d-learn
napsáno:
When I factor out code from my modules, it really, really
often leaves import statements that just sit there doing
nothing, making it look like my program is
On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote:
Otherwise, it sounds like a decent enhancement request for DMD.
I know other compilers who do this warning.
It definitely does sound like a decent enhancement request. I
didn't know it wasn't implemented yet, but it should be pretty
object.member lets me access the member of the object, but what
if I want to access those members in a generic way, but in a
different arrangement depending on context? Like if I wanted to
first follow a tree down, and second priority would be going left
to right, but then I wanted to first go
On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:
On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:
I see... By any chance, can we solve this issue with GC
managed pointers?
Maybe we could. But it's never going to happen. Even if
Walter weren't fundamentally opposed to multiple
On Monday, 8 February 2016 at 21:09:47 UTC, cy wrote:
object.member lets me access the member of the object, but what
if I want to access those members in a generic way, but in a
different arrangement depending on context? Like if I wanted to
first follow a tree down, and second priority would
This is what I have so far. Using mixin(rawstring~templatearg)
for every time I access the member is kind of cludgy though.
struct A {
string up;
string down;
string left;
string right;
}
template goPlaces(string D1, string D2, string D3) {
string goPlace
On Monday, 8 February 2016 at 22:38:45 UTC, Mengu wrote:
i believe you can use __traits(getMember) there.
Great! Should have refreshed before sending that reply...
I wonder if mixin("a."~member) is better or worse than
__traits(getMember,a,member)...
On Monday, 8 February 2016 at 22:46:06 UTC, cy wrote:
On Monday, 8 February 2016 at 22:38:45 UTC, Mengu wrote:
i believe you can use __traits(getMember) there.
Great! Should have refreshed before sending that reply...
I wonder if mixin("a."~member) is better or worse than
__traits(getMember,
On Monday, 8 February 2016 at 22:46:06 UTC, cy wrote:
On Monday, 8 February 2016 at 22:38:45 UTC, Mengu wrote:
i believe you can use __traits(getMember) there.
Great! Should have refreshed before sending that reply...
I wonder if mixin("a."~member) is better or worse than
__traits(getMember,
On Monday, 8 February 2016 at 07:31:07 UTC, Daniel Kozak wrote:
Seems to me too, please report it on issues.dlang.org
Reported: https://issues.dlang.org/show_bug.cgi?id=15661
On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote:
What I like most about your proposal is that it doesn't break
any existing code that wasn't broken before. That can't be
emphasized enough.
Although I wish more than 3 people had voted in my poll, two of
them did claim to need the
This:
double b = 1.0;
Variant[string] aa = ["b": &b];
writeln(aa["b"]);
fails with:
Error: cannot implicitly convert expression(["b":&b]) of type
double*[string] to VariantN!20u[string]
Helps please!
In the following sample program (which tries to set terminal to
raw mode and check for key presses), compiling as usual (dmd
t.d), the program works, but compiling in release mode (dmd
-release t.d) and the raw mode doesn't seem to work. Where do I
start looking to figure this out or if it is o
Ignore this -- this is probably due to how I am doing the
assert(). In the release build, it is getting compiled out and in
the process compiling out the tcgetattr and the tcsetattr.
On Tuesday, 9 February 2016 at 05:08:20 UTC, sanjayss wrote:
In the following sample program (which tries
Am Tue, 09 Feb 2016 00:38:10 +
schrieb tsbockman :
> On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote:
> > What I like most about your proposal is that it doesn't break
> > any existing code that wasn't broken before. That can't be
> > emphasized enough.
>
> Although I wish mor
On Tuesday, 9 February 2016 at 03:49:11 UTC, Enjoys Math wrote:
This:
double b = 1.0;
Variant[string] aa = ["b": &b];
writeln(aa["b"]);
fails with:
Error: cannot implicitly convert expression(["b":&b]) of type
double*[string] to VariantN!20u[string]
Helps please!
On 02/08/2016 07:49 PM, Enjoys Math wrote:
This:
double b = 1.0;
Variant[string] aa = ["b": &b];
writeln(aa["b"]);
fails with:
Error: cannot implicitly convert expression(["b":&b]) of type
double*[string] to VariantN!20u[string]
Helps please!
When initializing the array,
35 matches
Mail list logo