Re: Purpose of template DECLARE_HANDLE in druntime

2019-01-31 Thread Kagamin via Digitalmars-d-learn
It's a strong typed handle, in C it's declared as #ifdef STRICT typedef void *HANDLE; #if 0 && (_MSC_VER > 1000) #define DECLARE_HANDLE(name) struct name##__; typedef struct name##__ *name #else #define DECLARE_HANDLE(name) struct name##__{int unused;}; typedef struct name##__ *name #endif #e

Re: Purpose of template DECLARE_HANDLE in druntime

2019-01-31 Thread Adam D. Ruppe via Digitalmars-d-learn
On Thursday, 31 January 2019 at 20:51:37 UTC, Andre Pany wrote: I noticed in druntime this template is used often: package template DECLARE_HANDLE(string name, base = HANDLE) { mixin ("alias " ~ base.stringof ~ " " ~ name ~ ";"); If my memory is correct, it is actually for old D compatibil

Re: Purpose of template DECLARE_HANDLE in druntime

2019-01-31 Thread Seb via Digitalmars-d-learn
On Thursday, 31 January 2019 at 20:51:37 UTC, Andre Pany wrote: Hi, I noticed in druntime this template is used often: package template DECLARE_HANDLE(string name, base = HANDLE) { mixin ("alias " ~ base.stringof ~ " " ~ name ~ ";"); The disadvantage is, IDEs like IntelliJ are not able to

Re: Purpose of template DECLARE_HANDLE in druntime

2019-01-31 Thread Steven Schveighoffer via Digitalmars-d-learn
On 1/31/19 3:51 PM, Andre Pany wrote: Hi, I noticed in druntime this template is used often: package template DECLARE_HANDLE(string name, base = HANDLE) {     mixin ("alias " ~ base.stringof ~ " " ~ name ~ ";"); The disadvantage is, IDEs like IntelliJ are not able to find the symbols using t

Purpose of template DECLARE_HANDLE in druntime

2019-01-31 Thread Andre Pany via Digitalmars-d-learn
Hi, I noticed in druntime this template is used often: package template DECLARE_HANDLE(string name, base = HANDLE) { mixin ("alias " ~ base.stringof ~ " " ~ name ~ ";"); The disadvantage is, IDEs like IntelliJ are not able to find the symbols using this template e.g. mixin DECLARE_HANDLE!

Re: Filter out consecutive elements based on comparison between adiacent two

2019-01-31 Thread Langer via Digitalmars-d-learn
On Thursday, 31 January 2019 at 13:25:21 UTC, Alex wrote: On Thursday, 31 January 2019 at 13:18:39 UTC, Langer wrote: Hi all, Ditto... something like: filter!((a,b) => a.foo != b.foo) Thank you! but... why not ´´´ arr.uniq ´´´ thank you, uniq is perfect.

Re: Filter out consecutive elements based on comparison between adiacent two

2019-01-31 Thread Alex via Digitalmars-d-learn
On Thursday, 31 January 2019 at 13:18:39 UTC, Langer wrote: Hi all, Ditto... something like: filter!((a,b) => a.foo != b.foo) Thank you! but... why not ´´´ arr.uniq ´´´

Re: Filter out consecutive elements based on comparison between adiacent two

2019-01-31 Thread Alex via Digitalmars-d-learn
On Thursday, 31 January 2019 at 13:18:39 UTC, Langer wrote: Hi all, Ditto... something like: filter!((a,b) => a.foo != b.foo) Thank you! I would say: ´´´ arr.group.map!(el => el[0]) ´´´

Filter out consecutive elements based on comparison between adiacent two

2019-01-31 Thread Langer via Digitalmars-d-learn
Hi all, Ditto... something like: filter!((a,b) => a.foo != b.foo) Thank you!

Re: crashing with no stack trace, why?

2019-01-31 Thread DanielG via Digitalmars-d-learn
On Thursday, 31 January 2019 at 11:28:40 UTC, bauss wrote: Did you compile it with debug info? Eg. -g Yep, I use dub for builds which does that by default. Until this bug I was getting the usual stack traces with my project since the beginning.

Re: crashing with no stack trace, why?

2019-01-31 Thread NX via Digitalmars-d-learn
I can't say for sure, but there are some cases I know where you don't get stack trace (mostly dmd bugs): - inside module constructors `shared static this()` - null function pointer call

Re: crashing with no stack trace, why?

2019-01-31 Thread bauss via Digitalmars-d-learn
On Thursday, 31 January 2019 at 11:09:56 UTC, DanielG wrote: I have a program that was crashing due to a "Conversion positive overflow", specifically calling .to!int on a too-large unsigned value. However it was simply crashing with an exit code (-1073740771 / ‭0xC41D‬), and I was having

crashing with no stack trace, why?

2019-01-31 Thread DanielG via Digitalmars-d-learn
I have a program that was crashing due to a "Conversion positive overflow", specifically calling .to!int on a too-large unsigned value. However it was simply crashing with an exit code (-1073740771 / ‭0xC41D‬), and I was having a heck of a time trying to debug on Windows. (Shoutout to the

Re: Range with an alias parameter

2019-01-31 Thread Alex via Digitalmars-d-learn
On Thursday, 31 January 2019 at 02:41:00 UTC, Steven Schveighoffer wrote: Apples and oranges :) ReturnType!(produceS!(42)) is a TYPE, not a variable. When you apply the brackets, it's not calling your opindex, but rather changing it to an array. So let's make it clearer by saying: alias T =