Re: Obtain pointer from static array literal
On Friday, 8 October 2021 at 05:01:00 UTC, Nicholas Wilson wrote: For simple types (i.e. ones with no destructor), like int, IIRC this is fine. Thanks, perfect! note that if the pointer is not escaped from the function (i.e. thing is void thing(scope int* abc)note the addition of scope) LDC will perform promotion of GC allocation to stack of the array literal even if you don't use .staticArray. Interesting, I think you meant "even if you do use .staticArray"; not sure why it would do that, but it doesn't matter because my code is betterC and therefore nogc so it *should* allocate it on the stack, I think
Re: Obtain pointer from static array literal
On Friday, 8 October 2021 at 02:49:17 UTC, codic wrote:
I am working with a C API (XCB) which uses `void*` a lot to
obtain parameter packs; these are very small and throwaway so I
want them to be allocated to the stack.
CUDA has something similar that I have to deal with for
dcompute[1]. The trick is that the parameter packs always have
some sort of underlying structure to them and in D it is possible
to exploit that structure at compile time to ensure that you
don't break type safety. I can't give a more specific answer
without some more concrete examples from XCB, but for CUDA the
function signature of the kernel you are trying to launch
dictates what goes into the parameter pack.
The best way is to generate (or write) wrapper functions that do
this for you such that you can call `wrappedFunc(x,y,w,h)` and
statically verify through its type signature that
uint[4] params=[x,y,width,height];
func(params.ptr);
is a valid call to func.
Of course, this is valid, but a bit painful:
```d
uint[4] params=[x,y,width,height];
func(params.ptr);
```
especially when you have lots of calls. now, this compiles:
```d
// (import std.array)
func([x,y,width,height].staticArray.ptr);
```
but is it well-formed? or is it UB because it is a rvalue and
scope ends?
For simple types (i.e. ones with no destructor), like int, IIRC
this is fine.
When you have a static array of objects that need to be
destructed, then end of scope becomes important.
i.e. here is an example program, is it well formed?
```d
import core.stdc.stdio, std.array;
void thing(int* abc) {
printf("%d\n", *abc);
}
extern(C) void main() {
thing([1].staticArray.ptr);
}
```
At any rate, it runs fine consistently with ldc:
```
$ ldc2 test.d -fsanitize=address
$ ./test
1
```
I don't know if it is spec-compliant though, or if it is
actually causing UB here and I don't notice it.
note that if the pointer is not escaped from the function (i.e.
`thing` is `void thing(scope int* abc)`note the addition of
`scope`) LDC will perform promotion of GC allocation to stack of
the array literal even if you don't use `.staticArray`.
https://github.com/libmir/dcompute/blob/master/source/dcompute/driver/cuda/queue.d#L80-L92
Re: Windows printing
On Thursday, 7 October 2021 at 18:00:17 UTC, Imperatorn wrote: Oh, now I see. Sorry. I think that might depend on OS version iirc. Sidenote: shouldn't you use the unicode variant? 樂 Why? It shouldn't matter for this purpose.
Obtain pointer from static array literal
I am working with a C API (XCB) which uses `void*` a lot to
obtain parameter packs; these are very small and throwaway so I
want them to be allocated to the stack.
Of course, this is valid, but a bit painful:
```d
uint[4] params=[x,y,width,height];
func(params.ptr);
```
especially when you have lots of calls. now, this compiles:
```d
// (import std.array)
func([x,y,width,height].staticArray.ptr);
```
but is it well-formed? or is it UB because it is a rvalue and
scope ends?
i.e. here is an example program, is it well formed?
```d
import core.stdc.stdio, std.array;
void thing(int* abc) {
printf("%d\n", *abc);
}
extern(C) void main() {
thing([1].staticArray.ptr);
}
```
At any rate, it runs fine consistently with ldc:
```
$ ldc2 test.d -fsanitize=address
$ ./test
1
```
I don't know if it is spec-compliant though, or if it is actually
causing UB here and I don't notice it.
Re: Windows printing
On Thursday, 7 October 2021 at 17:13:45 UTC, frame wrote: On Thursday, 7 October 2021 at 15:38:27 UTC, Imperatorn wrote: On Thursday, 7 October 2021 at 01:55:15 UTC, frame wrote: Is there some Windows expert or someone you can tell me if I do things wrong? [...] Maybe I'm reading this wrong, but don't you want DM_OUT_BUFFER? No, please see: https://docs.microsoft.com/en-us/windows/win32/printdocs/documentproperties The output of mode DM_OUT_BUFFER is what I am tyring to import again. Oh, now I see. Sorry. I think that might depend on OS version iirc. Sidenote: shouldn't you use the unicode variant? 樂
Re: Windows printing
On Thursday, 7 October 2021 at 15:38:27 UTC, Imperatorn wrote: On Thursday, 7 October 2021 at 01:55:15 UTC, frame wrote: Is there some Windows expert or someone you can tell me if I do things wrong? [...] Maybe I'm reading this wrong, but don't you want DM_OUT_BUFFER? No, please see: https://docs.microsoft.com/en-us/windows/win32/printdocs/documentproperties The output of mode DM_OUT_BUFFER is what I am tyring to import again.
Re: Windows printing
On Thursday, 7 October 2021 at 01:55:15 UTC, frame wrote: Is there some Windows expert or someone you can tell me if I do things wrong? [...] Maybe I'm reading this wrong, but don't you want DM_OUT_BUFFER?
Re: Managing malloced memory
On 10/6/21 3:22 PM, anon wrote:
Sorry for messed up post, fixed it.
On Wednesday, 6 October 2021 at 18:29:34 UTC, Steven Schveighoffer wrote:
You can return this thing and pass it around, and the GC will keep it
alive until it's not needed. Then on collection, the value is freed.
Is the gc required to call ~this() on the struct? I remember it being
implementation defined. Probably doesn't matter for my usecase, just
curious.
The GC is technically not required to free any blocks ever. But in
general, it does.
When it does free a struct, as long as you allocated with `new`, it
should call the dtor.
Why is it a problem that it calls the dtor? I thought the whole point
of refcounting is for the dtor to decrement the refcount, and free the
malloc'd object only when the refcount has actually reached 0.
Yes I'm afraid of double freeing. How do I pass existing struct to
refcounted without the already existing copy calling destructed on
function exit.
Just FYI, you should reply to the posts that you quote, or at least copy
the "X Y wrote" line so people understand the thread. This question was
written by H.S. Teoh, but I'll respond.
The destructor is called once per copy. This is why disabling copy
prevents double freeing.
There are cases where the compiler avoids calling the destructor because
the instance is moved. Such as returning a newly constructed item
(typically referred to as an "rvalue"), or passing a newly constructed
item into a parameter. The parameter will be destroyed, but the
call-site constructed item will not.
e.g.:
```d
struct S
{
int x;
~this() { writeln("destructor called"); }
}
void foo(S s) {
// destructor for s called here
}
S makeS(int x)
{
return S(x); // no destructor called here.
}
void main()
{
foo(S(1)); // no destructor called for this rvalue
auto s = makeS(1);
// destructor for s called here.
foo(makeS(1)); // only one destructor called at the end of foo
}
```
You can also use std.algorithm.move to avoid calling destructors on live
data. However, the destructor will still be called, it just will be
called on an S.init value.
-Steve
