Re: Using C header libs with importC

2024-01-08 Thread Dennis via Digitalmars-d-learn

On Monday, 8 January 2024 at 21:56:10 UTC, Renato wrote:

but I tried exactly that! Which gives a seg fault.


Looks like there's a bug with the -H switch:
https://issues.dlang.org/show_bug.cgi?id=24326

But that shouldn't be necessary, you should just be able to 
import the c file.


I also tried just importing this little C file, but then no 
symbols from the h file are found at all. Kind of interesting, 
as if I just write the code using the library in the C file 
itself, that works fine.


That's weird, I'll see if I can reproduce this.



Re: Using C header libs with importC

2024-01-08 Thread Renato via Digitalmars-d-learn

On Monday, 8 January 2024 at 21:04:10 UTC, Dennis wrote:

On Monday, 8 January 2024 at 18:53:47 UTC, Renato wrote:
Perhaps using an intermediate C file to do this would work, 
but I wanted to know if D can do it.


Yes, your best options are either:

- rename the .h to .c and edit it so the 
`STB_DS_IMPLEMENTATION` check passes or is removed.

- create a C file with what you already wrote:


```c
#define STB_DS_IMPLEMENTATION
#include "stb_ds.h"
```


And import that.


You answered almost at the same time as I sent my previous 
answer, so I hadn't seen your comment, but I tried exactly that! 
Which gives a seg fault.


I also tried just importing this little C file, but then no 
symbols from the h file are found at all. Kind of interesting, as 
if I just write the code using the library in the C file itself, 
that works fine.


Importing .h files from d files isn't supported yet because of 
a dispute with the lookup priority:


https://issues.dlang.org/show_bug.cgi?id=23479
https://issues.dlang.org/show_bug.cgi?id=23547


Ah, too bad. Anyway, I was just playing around... disappointing 
that it doesn't work but I don't really need this for now.




Re: Using C header libs with importC

2024-01-08 Thread Renato via Digitalmars-d-learn

On Monday, 8 January 2024 at 19:17:06 UTC, Lance Bachmeier wrote:

On Monday, 8 January 2024 at 18:53:47 UTC, Renato wrote:

Is it possible to use C header-only libs from D?

In C, I would need to do this:

```c
#define STB_DS_IMPLEMENTATION
#include "stb_ds.h"
```

The definition must be done in a single C file before 
including the h file.


I tried this in D:

```d
enum STB_DS_IMPLEMENTATION = 1;
import stb_ds;
```

But it doesn't work. Any suggestions? Perhaps using an 
intermediate C file to do this would work, but I wanted to 
know if D can do it.


Without knowing the specifics of what you're trying to do, this 
automatic translation of C headers to D might be what you want:


I am trying to use a header-only C library. A h file from this 
project, specifically: https://github.com/nothings/stb



https://forum.dlang.org/post/ugvc3o$5t3$1...@digitalmars.com

The way "header-only" is usually used suggests you should 
change the file extension to .c and compile it directly.


That doesn't work without the `#define`, as I mentioned. Header 
libraries like this are designed to only be included once, given 
that they have impl code, so they rely on the C file defining a 
variable to explicitly "enable" the impl code to be included.


Based on that thread you've linked, I tried generating a di file 
from a basic C file that just has the define and include:


```c
#define STB_DS_IMPLEMENTATION
#include "stb_ds.h"
```

But that gets me a seg fault with DMD:

```
▶ dmd -c import_stb_ds.c -Hf=stb_ds.di
[1]73719 segmentation fault  dmd -c import_stb_ds.c 
-Hf=stb_ds.di

(dmd-2.106.1)
```

LDC also does:

```
▶ ldc2 -c import_stb_ds.c -Hf=stb_ds.di
Stack dump without symbol names (ensure you have llvm-symbolizer 
in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to 
point to it):
0  ldc2 0x00010f860d87 
llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 39
1  ldc2 0x00010f85fce6 
llvm::sys::RunSignalHandlers() + 198
2  ldc2 0x00010f8613e0 SignalHandler(int) 
+ 288

3  libsystem_platform.dylib 0x7ff8115bf37d _sigtramp + 29
4  libsystem_c.dylib0x7ff81143772b __sfvwrite + 355
[1]73787 segmentation fault  ldc2 -c import_stb_ds.c 
-Hf=stb_ds.di

(ldc-1.35.0)
```

Should I report a bug?


Re: Doubt about Struct and members

2024-01-08 Thread matheus via Digitalmars-d-learn

On Monday, 8 January 2024 at 17:56:19 UTC, H. S. Teoh wrote:

...
It's not recommended to use initializers to initialize mutable 
array-valued members, because it probably does not do what you 
think it does.  What the above code does is to store the array 
["ABC"] somewhere in the program's pre-initialized data segment 
and set s to point to that by default. It does NOT allocated a 
new array literal every time you create a new instance of S; 
every instance of S will *share* the same array value unless 
you reassign it.  As such, altering the contents array may 
cause the new contents to show up in other instances of S.


This behaviour is generally harmless if your array is 
immutable. In fact, it saves space in your executable by 
reusing the same data for multiple instances of s. It also 
avoids repeated GC allocations at runtime.

...


First of all thanks for replying,

Yes I understood the behavior since I even looked the code 
generated: https://godbolt.org/z/xnsbern9f


=]

Maybe my question was poorly written (I'm ESL), but you answered 
in the other Topic:


"(Whether the current behaviour should be changed is up for 
debate, though. This definitely isn't the first time users have 
run into this. In fact just today somebody else asked the same 
question on D.learn. So it's definitely in the territory of 
"does not do the expected thing", which is an indication that 
the default behaviour was poorly chosen.)"


I was in doubt about if this was intended or not... and it seems 
the case.


I'm not saying it is wrong by any means, I just found a bit 
tricky based on the two ways it could change the value pointed by 
the address and/or the address of the member itself.


Again thanks,

Matheus.


Re: Using C header libs with importC

2024-01-08 Thread Lance Bachmeier via Digitalmars-d-learn

On Monday, 8 January 2024 at 18:53:47 UTC, Renato wrote:

Is it possible to use C header-only libs from D?

In C, I would need to do this:

```c
#define STB_DS_IMPLEMENTATION
#include "stb_ds.h"
```

The definition must be done in a single C file before including 
the h file.


I tried this in D:

```d
enum STB_DS_IMPLEMENTATION = 1;
import stb_ds;
```

But it doesn't work. Any suggestions? Perhaps using an 
intermediate C file to do this would work, but I wanted to know 
if D can do it.


Without knowing the specifics of what you're trying to do, this 
automatic translation of C headers to D might be what you want:


https://forum.dlang.org/post/ugvc3o$5t3$1...@digitalmars.com

The way "header-only" is usually used suggests you should change 
the file extension to .c and compile it directly.


Using C header libs with importC

2024-01-08 Thread Renato via Digitalmars-d-learn

Is it possible to use C header-only libs from D?

In C, I would need to do this:

```c
#define STB_DS_IMPLEMENTATION
#include "stb_ds.h"
```

The definition must be done in a single C file before including 
the h file.


I tried this in D:

```d
enum STB_DS_IMPLEMENTATION = 1;
import stb_ds;
```

But it doesn't work. Any suggestions? Perhaps using an 
intermediate C file to do this would work, but I wanted to know 
if D can do it.


Re: Doubt about Struct and members

2024-01-08 Thread H. S. Teoh via Digitalmars-d-learn
On Mon, Jan 08, 2024 at 05:28:50PM +, matheus via Digitalmars-d-learn wrote:
> Hi,
> 
> I was doing some tests and this code:
> 
> import std;
> 
> struct S{
> string[] s = ["ABC"];
> int i = 123;
> }
[...]

It's not recommended to use initializers to initialize mutable
array-valued members, because it probably does not do what you think it
does.  What the above code does is to store the array ["ABC"] somewhere
in the program's pre-initialized data segment and set s to point to that
by default. It does NOT allocated a new array literal every time you
create a new instance of S; every instance of S will *share* the same
array value unless you reassign it.  As such, altering the contents
array may cause the new contents to show up in other instances of S.

This behaviour is generally harmless if your array is immutable. In
fact, it saves space in your executable by reusing the same data for
multiple instances of s. It also avoids repeated GC allocations at
runtime.

However, if you're banking on each instance of S getting its own copy of
the array, you're in for a surprise. In this case, what you want is to
use a ctor to initialize it rather than the above initializer.


T

-- 
Right now I'm having amnesia and deja vu at the same time. I think I've 
forgotten this before.


Doubt about Struct and members

2024-01-08 Thread matheus via Digitalmars-d-learn

Hi,

I was doing some tests and this code:

import std;

struct S{
string[] s = ["ABC"];
int i = 123;
}

void foo(bool b, string str){
S t1;

writeln("t1.s: ", t1.s, ", t1.s.ptr: ", t1.s.ptr, " t1.i: ", 
t1.i);


if(b){
t1.s[0] = str;
}else{
t1.s = [str];
}

t1.i = 456;
S t2;

writeln("t1.s: ", t1.s, ", t1.s.ptr: ", t1.s.ptr, " t1.i: ", 
t1.i);


writeln("t2.s: ", t2.s, ", t2.s.ptr: ", t2.s.ptr, " t2.i: ", 
t2.i);

writeln("");
}

void main(){
foo(false, "DEF");
foo(true, "DEF");
foo(false, "XYZ");
}

Outputs:

t1.s: ["ABC"], t1.s.ptr: 56421C6D7010 t1.i: 123
t1.s: ["DEF"], t1.s.ptr: 7EFC725E6000 t1.i: 456
t2.s: ["ABC"], t2.s.ptr: 56421C6D7010 t2.i: 123

t1.s: ["ABC"], t1.s.ptr: 56421C6D7010 t1.i: 123
t1.s: ["DEF"], t1.s.ptr: 56421C6D7010 t1.i: 456
t2.s: ["DEF"], t2.s.ptr: 56421C6D7010 t2.i: 123

t1.s: ["DEF"], t1.s.ptr: 56421C6D7010 t1.i: 123
t1.s: ["XYZ"], t1.s.ptr: 7EFC725E6020 t1.i: 456
t2.s: ["DEF"], t2.s.ptr: 56421C6D7010 t2.i: 123

As you can see:

t1.s = [str];

Just changed generated a new address only for t1.s, on the other 
hand:


t1.s[0] = str;

Changed the value pointed by S.s entirely (The other "instance" 
t2 since points to the same address now has the new value too).


Is this intended?

Matheus.


Re: linux dynamic library __gshared var

2024-01-08 Thread d007 via Digitalmars-d-learn

On Monday, 8 January 2024 at 06:12:16 UTC, d007 wrote:
I just notice the __gshared is cross process shared.   I want a 
var exits in one process, but shared for multi thread with 
atomic for __gshared library.  how can I do this with d ?


my bad, is is process only .