Re: ImportC: Should this compile?

2021-12-18 Thread Mike Parker via Digitalmars-d-learn
On Sunday, 19 December 2021 at 03:27:50 UTC, Tejas wrote: Oh wow, the executable gets named `stuff` if that's the first file passed... always thought it would name it the same name as that file which contained `main` If the name of the file with `main` were used, you'd have to have a

Re: ImportC: Should this compile?

2021-12-18 Thread Tejas via Digitalmars-d-learn
On Sunday, 19 December 2021 at 02:57:35 UTC, Mike Parker wrote: On Saturday, 18 December 2021 at 22:31:38 UTC, bachmeier wrote: I've been trying to get the stb header library to compile. There's a single remaining failure: ``` typedef struct { unsigned char c[4]; } stb_easy_font_color;

Re: ImportC: Should this compile?

2021-12-18 Thread Mike Parker via Digitalmars-d-learn
On Saturday, 18 December 2021 at 22:31:38 UTC, bachmeier wrote: I've been trying to get the stb header library to compile. There's a single remaining failure: ``` typedef struct { unsigned char c[4]; } stb_easy_font_color; stb_easy_font_color c = { 255,255,255,255 }; // use structure

Re: Why does is the RandomAccessInfinite interface not a valid RandomAccessRange?

2021-12-18 Thread Paul Backus via Digitalmars-d-learn
On Saturday, 18 December 2021 at 19:48:00 UTC, D Lark wrote: Can someone please tell me if this is expected behaviour and what the reasoning is behind this choice? Looks like a bug. I've filed a report on the D issue tracker: https://issues.dlang.org/show_bug.cgi?id=22608

ImportC: Should this compile?

2021-12-18 Thread bachmeier via Digitalmars-d-learn
I've been trying to get the stb header library to compile. There's a single remaining failure: ``` typedef struct { unsigned char c[4]; } stb_easy_font_color; stb_easy_font_color c = { 255,255,255,255 }; // use structure copying to avoid needing depending on memcpy() ``` LDC returns ```

Why does is the RandomAccessInfinite interface not a valid RandomAccessRange?

2021-12-18 Thread D Lark via Digitalmars-d-learn
The following assertion fails: ```dlang assert(isRandomAccessRange!(RandomAccessInfinite!int)); ``` Whereas this one passes: ```dlang assert(isRandomAccessRange!(RandomAccessFinite!int)); ``` I have compiled this using dmd v2.098.0. Can someone please tell me if this is expected behaviour and

Re: This is bug or not? (immutable class containing struct with dtor)

2021-12-18 Thread Denis Feklushkin via Digitalmars-d-learn
On Saturday, 18 December 2021 at 12:50:17 UTC, Tejas wrote: As Ali said, this is an implementation issue. So I guess the answer to your question is that this is a bug. Please file a report at [issues.dlang.org](issues.dlang.org) Looks like this is same case:

Re: This is bug or not? (immutable class containing struct with dtor)

2021-12-18 Thread Tejas via Digitalmars-d-learn
On Saturday, 18 December 2021 at 11:01:53 UTC, Denis Feklushkin wrote: On Friday, 17 December 2021 at 19:03:05 UTC, Tejas wrote: Well, I got completely mislead by my experiment  ```d struct S { ~this() immutable {} } ``` Interesting what discussed behaviour isn't affects method what

Re: This is bug or not? (immutable class containing struct with dtor)

2021-12-18 Thread Denis Feklushkin via Digitalmars-d-learn
On Friday, 17 December 2021 at 19:03:05 UTC, Tejas wrote: Well, I got completely mislead by my experiment  ```d struct S { ~this() immutable {} } ``` Interesting what discussed behaviour isn't affects method what implements same functionality as dtor and called explictly at each