Re: Dynamic Ctors ?

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

Re: Things that keep D from evolving?

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

Re: How to warn of unused imports?

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 to warn of unused imports?

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?

Re: is increment on shared ulong atomic operation?

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.

Re: Bug or intended?

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'

Re: Dynamic Ctors ?

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

Re: Things that keep D from evolving?

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

Re: Things that keep D from evolving?

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

Re: How is D doing?

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:

Problem with release build.

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

Re: Is this a bug in std.typecons.Tuple.slice?

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

Re: How do you reference variables in an AA of Variants?

On Tuesday, 9 February 2016 at 03:49:11 UTC, Enjoys Math wrote: This: double b = 1.0; Variant[string] aa = ["b": ]; writeln(aa["b"]); fails with: Error: cannot implicitly convert expression(["b":]) of type double*[string] to VariantN!20u[string] Helps please!

Re: How do you reference variables in an AA of Variants?

On 02/08/2016 07:49 PM, Enjoys Math wrote: This: double b = 1.0; Variant[string] aa = ["b": ]; writeln(aa["b"]); fails with: Error: cannot implicitly convert expression(["b":]) of type double*[string] to VariantN!20u[string] Helps please! When initializing the array,

Re: Problem with release build.

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

How do you reference variables in an AA of Variants?

This: double b = 1.0; Variant[string] aa = ["b": ]; writeln(aa["b"]); fails with: Error: cannot implicitly convert expression(["b":]) of type double*[string] to VariantN!20u[string] Helps please!

Re: Dynamic Ctors ?

http://dpaste.dzfl.pl/1f25ac34c1ee You need Tuple, not Algebraic. Algebraic stores only one value of one type from a set, like Variant.

Re: How to warn of unused imports?

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.

Re: Things that keep D from evolving?

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

Re: Can D interface with Free Pascal?

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

Re: Things that keep D from evolving?

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

Re: Things that keep D from evolving?

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

Re: Things that keep D from evolving?

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

Re: How to warn of unused imports?

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

in a template argument, specify which object member to access?

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

Re: How to warn of unused imports?

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

Re: How to warn of unused imports?

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

Re: Things that keep D from evolving?

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

Re: in a template argument, specify which object member to access?

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

Re: in a template argument, specify which object member to access?

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)...

Re: in a template argument, specify which object member to access?

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

Re: in a template argument, specify which object member to access?

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

Re: Odd Destructor Behavior

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

Re: Is this a bug in std.typecons.Tuple.slice?

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

Re: in a template argument, specify which object member to access?

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