Re: ImportC: Should this compile?
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 different default for libraries. Executables and libraries get the name of the first source file passed on the command line by default. This can be overridden with -of.
Re: ImportC: Should this compile?
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;
stb_easy_font_color c = { 255,255,255,255 }; // use structure
copying to avoid needing depending on memcpy()
```
LDC returns
```
stb_easy_font.c(892): Error: 3 extra initializer(s) for
`struct __tag21`
```
Is this a bug in ImportC or is it correct that it doesn't
compile? What's the best way to fix it while keeping the same
behavior and performance?
Unless C11 has changed the rules about nested initializers,
that should compile. You might try explicit nesting:
```d
stb_easy_font_color c = { {255,255,255,255} };
```
And please file an issue if there isn't one already.
(I don't know what struct __tag21 is. It's not anywhere in the
source. Assuming that's just a bad error message.)
A "tag" is the name of a struct or union, which follows the
keyword:
```c
struct Foo {};
```
Here, `Foo` is the tag. Instances of the struct must be
declared as `struct Foo`. Think of it like this: `int` is
required in declarations of instances of type `int`, so
`struct` is required in declarations of type `struct`; the
"tag" specifies which struct type, hence `struct Foo x`.
`typedef` introduces an alias:
```c
typedef struct Bar {} Bar;
```
So `Bar` is now an alias for `struct Bar`, and instances can be
declared as `Bar x`.
Your example is like this:
```c
typedef struct {} stb_easy_font_color;
```
No tag is specified, so the compiler must generate one. In your
case, it's `__tag21` and `stb_easy_font_color` is an alias for
`struct __tag21`.
And yes, using the generated tag in the error message is not at
all helpful without the alias. Please file an issue on this,
too.
Yes, using the nested initializer worked
```c
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()
```
d file:
```d
void main(){}
```
command line:
` dmd stuff.c main.d`
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`
Re: ImportC: Should this compile?
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
copying to avoid needing depending on memcpy()
```
LDC returns
```
stb_easy_font.c(892): Error: 3 extra initializer(s) for `struct
__tag21`
```
Is this a bug in ImportC or is it correct that it doesn't
compile? What's the best way to fix it while keeping the same
behavior and performance?
Unless C11 has changed the rules about nested initializers, that
should compile. You might try explicit nesting:
```d
stb_easy_font_color c = { {255,255,255,255} };
```
And please file an issue if there isn't one already.
(I don't know what struct __tag21 is. It's not anywhere in the
source. Assuming that's just a bad error message.)
A "tag" is the name of a struct or union, which follows the
keyword:
```c
struct Foo {};
```
Here, `Foo` is the tag. Instances of the struct must be declared
as `struct Foo`. Think of it like this: `int` is required in
declarations of instances of type `int`, so `struct` is required
in declarations of type `struct`; the "tag" specifies which
struct type, hence `struct Foo x`.
`typedef` introduces an alias:
```c
typedef struct Bar {} Bar;
```
So `Bar` is now an alias for `struct Bar`, and instances can be
declared as `Bar x`.
Your example is like this:
```c
typedef struct {} stb_easy_font_color;
```
No tag is specified, so the compiler must generate one. In your
case, it's `__tag21` and `stb_easy_font_color` is an alias for
`struct __tag21`.
And yes, using the generated tag in the error message is not at
all helpful without the alias. Please file an issue on this, too.
Re: Why does is the RandomAccessInfinite interface not a valid RandomAccessRange?
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?
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
```
stb_easy_font.c(892): Error: 3 extra initializer(s) for `struct
__tag21`
```
Is this a bug in ImportC or is it correct that it doesn't
compile? What's the best way to fix it while keeping the same
behavior and performance? (I don't know what struct __tag21 is.
It's not anywhere in the source. Assuming that's just a bad error
message.)
Why does is the RandomAccessInfinite interface not a valid RandomAccessRange?
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 what the reasoning is behind this choice?
Re: This is bug or not? (immutable class containing struct with dtor)
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: https://issues.dlang.org/show_bug.cgi?id=13628
Re: This is bug or not? (immutable class containing struct with dtor)
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
implements same functionality as dtor and called explictly at
each appropriate place.
So for dirty fix I just created
```d
void __custom_dtor() const
{ ... }
```
And then called this __custom_dtor at each dtor what uses this
struct.
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)
Re: This is bug or not? (immutable class containing struct with dtor)
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 appropriate place.
So for dirty fix I just created
```d
void __custom_dtor() const
{ ... }
```
And then called this __custom_dtor at each dtor what uses this
struct.
