Re: [OT] Re: Problems with -fPIC, libraries and exceptions (in linux?)

2016-07-16 Thread Basile B. via Digitalmars-d-learn
On Sunday, 17 July 2016 at 05:07:00 UTC, Basile B. wrote: On Saturday, 16 July 2016 at 20:13:00 UTC, Seb wrote: On Friday, 15 July 2016 at 08:40:02 UTC, Arafel wrote: Just as a follow-up, I think it's looking more and more like a compiler bug. It works properly both with gdc and ldmd2. Should

[OT] Re: Problems with -fPIC, libraries and exceptions (in linux?)

2016-07-16 Thread Basile B. via Digitalmars-d-learn
On Saturday, 16 July 2016 at 20:13:00 UTC, Seb wrote: On Friday, 15 July 2016 at 08:40:02 UTC, Arafel wrote: Just as a follow-up, I think it's looking more and more like a compiler bug. It works properly both with gdc and ldmd2. Should I make a bug report about that? Yes please. Hi, you

Re: unittests not being run

2016-07-16 Thread Bahman Movaqar via Digitalmars-d-learn
On 07/17/2016 12:38 AM, Seb wrote: > There is no need for a module, but dub by default only checks files in > the 'source' folder. The file is already in the 'source' folder. > For such simple tests you could also run them directly with rdmd > -unittest. There is an additional -main flag if you

Re: to auto or not to auto ( in foreach )

2016-07-16 Thread ketmar via Digitalmars-d-learn
On Sunday, 17 July 2016 at 02:04:50 UTC, Adam D. Ruppe wrote: (x) => x; // defines a new variable foreach isn't alone. compiler should allow `auto` here too.

Re: to auto or not to auto ( in foreach )

2016-07-16 Thread Adam D. Ruppe via Digitalmars-d-learn
On Sunday, 17 July 2016 at 01:57:21 UTC, pineapple wrote: Chipping in my agreement. foreach(x; y) makes as much syntactic sense as for(x = 0; x < y; x++) where x was not previously defined. One does not expect something that does not look like every other variable definition in the language to

Re: to auto or not to auto ( in foreach )

2016-07-16 Thread pineapple via Digitalmars-d-learn
On Sunday, 17 July 2016 at 01:57:21 UTC, pineapple wrote: On Saturday, 16 July 2016 at 22:05:49 UTC, ketmar wrote: actually, `foreach (v; rng)` looks like `foreach` is *reusing* *existing* *variable*. most of the time you can put `immutable` or something like that there to note that it is not

Re: to auto or not to auto ( in foreach )

2016-07-16 Thread pineapple via Digitalmars-d-learn
On Saturday, 16 July 2016 at 22:05:49 UTC, ketmar wrote: actually, `foreach (v; rng)` looks like `foreach` is *reusing* *existing* *variable*. most of the time you can put `immutable` or something like that there to note that it is not reusing (purely cosmetical thing), but sometimes you

Re: to auto or not to auto ( in foreach )

2016-07-16 Thread ketmar via Digitalmars-d-learn
On Saturday, 16 July 2016 at 21:39:42 UTC, cym13 wrote: However auto should be allowed here. You are defining a variable and the fact that it's in a foreach shouldn't be of any importance. The language should enforce orthogonality of orthogonal things, not break it. A variable definition in a

Re: to auto or not to auto ( in foreach )

2016-07-16 Thread cym13 via Digitalmars-d-learn
On Saturday, 16 July 2016 at 21:39:42 UTC, cym13 wrote: A variable definition in a foreach -> A variable definition *with auto* in a foreach

Re: to auto or not to auto ( in foreach )

2016-07-16 Thread cym13 via Digitalmars-d-learn
On Saturday, 16 July 2016 at 20:00:39 UTC, Seb wrote: On Saturday, 16 July 2016 at 14:11:34 UTC, cym13 wrote: On Saturday, 16 July 2016 at 14:00:56 UTC, dom wrote: foreach(auto v; msg) writeln(v); gives an error that a basic type is expected foreach(v; msg) writeln(v); works .. but

Re: Some asm help for the 'thiscall' calling convention?

2016-07-16 Thread Andrew Godfrey via Digitalmars-d-learn
On Thursday, 14 July 2016 at 14:01:29 UTC, Kagamin wrote: On Wednesday, 13 July 2016 at 22:30:51 UTC, Adam Sansier wrote: Um, no, I revived it so that people searching for answers wouldn't be led astray by idiots who pretend to know everything. My word is not COM specification of course,

Re: Some asm help for the 'thiscall' calling convention?

2016-07-16 Thread Adam Sansier via Digitalmars-d-learn
On Thursday, 14 July 2016 at 00:51:16 UTC, ethgeh wrote: On Wednesday, 13 July 2016 at 23:06:44 UTC, flamencofantasy wrote: On Wednesday, 13 July 2016 at 22:30:51 UTC, Adam Sansier wrote: On Wednesday, 13 July 2016 at 22:09:05 UTC, flamencofantasy wrote: On Wednesday, 13 July 2016 at 20:39:00

Re: Some asm help for the 'thiscall' calling convention?

2016-07-16 Thread Adam Sansier via Digitalmars-d-learn
On Thursday, 14 July 2016 at 14:01:29 UTC, Kagamin wrote: On Wednesday, 13 July 2016 at 22:30:51 UTC, Adam Sansier wrote: Um, no, I revived it so that people searching for answers wouldn't be led astray by idiots who pretend to know everything. My word is not COM specification of course,

Re: cant run unittests

2016-07-16 Thread Seb via Digitalmars-d-learn
On Thursday, 14 July 2016 at 10:13:38 UTC, dom wrote: On Thursday, 14 July 2016 at 00:33:50 UTC, ethgeh wrote: On Wednesday, 13 July 2016 at 19:41:53 UTC, dom wrote: how can i run my unittests for a dynamic library? some weird conflict is reported between main functions, my project doesnt

Re: Type constructor with new size

2016-07-16 Thread Seb via Digitalmars-d-learn
On Friday, 15 July 2016 at 01:10:09 UTC, Eppason wrote: How can I create a new type NT from type T that such that NT is compatible with T when reduced to the size of T, but has size n? Another way to see it is that I would like to construct a type at compile time that has the same layout as

Re: Problems with -fPIC, libraries and exceptions (in linux?)

2016-07-16 Thread Seb via Digitalmars-d-learn
On Friday, 15 July 2016 at 08:40:02 UTC, Arafel wrote: Just as a follow-up, I think it's looking more and more like a compiler bug. It works properly both with gdc and ldmd2. Should I make a bug report about that? Yes please.

Re: unittests not being run

2016-07-16 Thread Seb via Digitalmars-d-learn
On Friday, 15 July 2016 at 11:59:51 UTC, Bahman Movaqar wrote: On 07/15/2016 04:16 PM, Jerry wrote: Unittests have to be inside a module to be run on DMD atleast. So putting module foo at top should fix it. Strange. Still not getting picked up. $ dmd --version DMD64 D Compiler

Re: to auto or not to auto ( in foreach )

2016-07-16 Thread Seb via Digitalmars-d-learn
On Saturday, 16 July 2016 at 20:00:39 UTC, Seb wrote: On Saturday, 16 July 2016 at 14:11:34 UTC, cym13 wrote: [...] It's not arbitrary. It keeps the language simple and easy to read. After all the entire auto keyword is just there, because the compiler needs a keyword and in loops it's

Re: to auto or not to auto ( in foreach )

2016-07-16 Thread Seb via Digitalmars-d-learn
On Saturday, 16 July 2016 at 14:11:34 UTC, cym13 wrote: On Saturday, 16 July 2016 at 14:00:56 UTC, dom wrote: foreach(auto v; msg) writeln(v); gives an error that a basic type is expected foreach(v; msg) writeln(v); works .. but why? Arbitrary limitation. If you want to say how

build a subpackage in dub?

2016-07-16 Thread cy via Digitalmars-d-learn
Say I have a package called "main" and a sub-package in a "complicatedexample" directory, and my dub.json in "main" looks sort of like: "subPackages": [ "./complicatedexample/" ], Let's say I do *not* have ":complicatedexample" in my dependencies for "main", but "complicatedexample" itself

Re: extern (C++) including bodies of member functions?

2016-07-16 Thread Jacob Carlborg via Digitalmars-d-learn
On 2016-07-16 04:01, cy wrote: So, it applies to member functions too (for C++)? Just as if you passed an extern(C++) directive to each one? And only their signature/mangling is changed, so that say in gdb for instance, they represent Type::member instead of zzTypezdxqdstuffmember? Yes. It's

Re: to auto or not to auto ( in foreach )

2016-07-16 Thread ketmar via Digitalmars-d-learn
On Saturday, 16 July 2016 at 14:00:56 UTC, dom wrote: .. but why? because. i've lost that fight too.

Re: to auto or not to auto ( in foreach )

2016-07-16 Thread cym13 via Digitalmars-d-learn
On Saturday, 16 July 2016 at 14:00:56 UTC, dom wrote: foreach(auto v; msg) writeln(v); gives an error that a basic type is expected foreach(v; msg) writeln(v); works .. but why? Arbitrary limitation. If you want to say how surprising and uselessly limiting it is wait at the end of the

Re: to auto or not to auto ( in foreach )

2016-07-16 Thread Dennis Ritchie via Digitalmars-d-learn
On Saturday, 16 July 2016 at 14:00:56 UTC, dom wrote: foreach(auto v; msg) writeln(v); gives an error that a basic type is expected foreach(v; msg) writeln(v); works .. but why? `Note: The ForeachTypeAttribute is implicit, and when a type is not specified, it is inferred. In that

to auto or not to auto ( in foreach )

2016-07-16 Thread dom via Digitalmars-d-learn
foreach(auto v; msg) writeln(v); gives an error that a basic type is expected foreach(v; msg) writeln(v); works .. but why?

Re: Iterate through getOverloads trait

2016-07-16 Thread Ali Çehreli via Digitalmars-d-learn
On 07/15/2016 03:58 PM, Max Klimov wrote: > I'm wondering how I can use the output of __traits(getOverloads, a, > "name"). Apparently, it produces a delegate of calling name() on 'a'. > The example in the doc uses direct indexing (like > __traits(getOverloads, a, "name")[0](param)) and it

Re: Template args

2016-07-16 Thread Andrey via Digitalmars-d-learn
On Saturday, 16 July 2016 at 00:29:12 UTC, Max Klimov wrote: On Friday, 15 July 2016 at 23:07:20 UTC, Andrey wrote: Hi guys! Can any one tell me - how to pass an array of int's in to the template struct at compile-time, and how to use int there? Like this: