Re: How to move from Unique(someClass) to Unique(someInterface)?
On Sunday, 27 November 2022 at 17:06:31 UTC, vushu wrote: On Saturday, 16 May 2020 at 17:45:56 UTC, Konstantin wrote: [...] I'm actually also very curious about this issue, since I come from c++ where this is possible, and it is a very common functionality for example for dependency inversion and dependency injection or mocking. It would be very nice to have this working. I _think_ it's not working here because `Unique` is a `struct`, so there's no concept of inheritance here, meanwhile that it possible in `C++`
Re: pragma(linkerDirective,_) removes double quotes, dmd ignores LIB
On Sunday, 27 November 2022 at 17:37:50 UTC, kinke wrote: For LDC, you shouldn't need any double quotes, the compiler quotes the linker flag if it contains spaces. Didn't work for me with LDC: This, which works at the command line with ```-L=```: ```enum LIBPATH = `/LIBPATH:"C:\Program Files (x86)\Windows Kits\NETFXSDK\4.7.2\Lib\um\x64"`; pragma(linkerDirective, LIBPATH);``` gave this: ```warning LNK4229: invalid directive '/LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.7.2\Lib\um\x64' encountered; ignored``` and without the double quotes gave this: ```fatal error LNK1276: invalid directive 'Files' found; does not start with '/'``` This, which also works at the command line with ```-L=```: ```enum LIBPATH = `"/LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.7.2\Lib\um\x64"`; pragma(linkerDirective, LIBPATH);``` gave this: ```warning LNK4229: invalid directive '/LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.7.2\Lib\um\x64' encountered; ignored``` So double quotes are not arriving at the destination.
Re: pragma(linkerDirective,_) removes double quotes, dmd ignores LIB
For LDC, you shouldn't need any double quotes, the compiler quotes the linker flag if it contains spaces.
pragma(linkerDirective,_) removes double quotes, dmd ignores LIB
Hello, using dmd 2.100.2 and ldc2 1.30.0, compiling to 64-bits, Windows 10. pragma(linkerDirective,_) strips double quotation marks, so how can a linker command line like /LIBPATH:"Path/containing spaces/to/needed/libs" be passed on to the linker via this pragma? Is this a bug? Note: the libs in question are installed in locations not determined by me. I worked around this by setting a LIB environment variable containing the extra path I needed, so I didn't need the pragma. But this only worked for ldc2; dmd still complained it cannot find the necessary, ignoring the LIB environment variable. Is this a bug?
Re: How to move from Unique(someClass) to Unique(someInterface)?
On Saturday, 16 May 2020 at 17:45:56 UTC, Konstantin wrote:
import std.stdio;
import automem;
import std.experimental.allocator.mallocator : Mallocator;
interface IGetInt
{
@nogc int GetInt();
}
class Foo : IGetInt
{
@nogc int GetInt()
{
return 42;
}
}
@nogc void main()
{
auto foo = Unique!(Foo, Mallocator).construct;
printf("Value is %d!\n", foo.GetInt());
// Unique!(IGetInt, Mallocator) ifoo = Unique!(Foo,
Mallocator).construct;
// printf("Value is %d!\n", ifoo.GetInt());
}
How to cast from a class to an interface in such situation? Is
it possible?
And one more question: Where can i find actual status(or plans)
of @nogc support for Phobos and language constructs?
I'm actually also very curious about this issue, since I come
from c++ where this is possible, and it is a very common
functionality for example for dependency inversion and dependency
injection or mocking. It would be very nice to have this working.
Re: pointer escaping return scope bug?
On Friday, 25 November 2022 at 15:03:57 UTC, ShadoLight wrote:
I don't grok how `lf` can survive the local scope. Or am I
missing something?
Perhaps because the local scope is not pushed as a separate
(anonymous) function on the stack... if true then, yes, then
`lf` will indeed have the same physical lifetime as main (and
`p`)...?
On the other hand, if you add a destructor to `LockedFile`, it
will be invoked at the end of the local scope, not the end of
main.
Yes, the actual code does have a destructor. It's analogous to
this:
```d
@safe:
struct S
{
private int* fps;
auto fp() return scope => fps;
this(int)
{
fps = new int;
}
@disable this();
@disable void opAssign(S);
~this() @trusted // how do we make this safe?
{
import core.memory;
GC.free(fps);
}
}
void main()
{
int* p;
{
auto lf = S(5);
p = lf.fp;
}
assert(p != null); // address escaped
}
```
That compiles with -dip1000. D doesn't seem to have a way to
prevent the memory outliving the struct.
Just to note there is another problem when the struct is
destroyed explicitly whilst the `fp` result is still live. But
that could be solved by making `object.destroy` and
`std.algorithm.move` be restricted to @system for certain structs
like this one (either opt-in or some other mechanism). The first
problem doesn't seem to have a solution.
