about const ref
I need to be sure about "const ref". Based on the following
function, does it mean:
Type can be string or an integral type.
(a) k1 is not copied on function calls
(b) k1 cannot be modified inside function
Please correct me if I am wrong. Can storage class "in" be used
to satisfy (a) and (b)?
void doIt(const ref Type k1){
}
Type k = ...;
doit(k);
Re: Dynamically calling shared objects from statically build executable allowed
On Monday, 10 February 2020 at 19:00:36 UTC, Andre Pany wrote: On Monday, 10 February 2020 at 13:14:50 UTC, Ernesto Castellotti wrote: On Monday, 10 February 2020 at 04:41:31 UTC, Andre Pany wrote: Is this a bug with LDC and DMD, or is it not allowed to dynamically call a SO from a statically build executable on linux On Unix systems it is not possible to dynamically load a library shared by a static executable, I don't know if it works differently for Windows. This is because it is absolutely necessary to link libdl dynamically, you cannot link static. For GNU/Linux systems there is this alternative to dlopen/dlsym that does not require dynamic link: https://www.gnu.org/software/libtool/manual/html_node/Dlpreopening.html This is a topic I almost have no knowledge, therefore a question. If I understand this StackOverflow question correctly, it is possible to call dynamically a shared object from a static library (with dlopen): https://stackoverflow.com/questions/17862272/dlopen-a-dynamic-library-from-a-static-library-linux-c But I understand from you it is not possible dynamically call a shared object from a static executable. Therefore it works for static libraries but not for statically executables? Kind regards Andre Static libraries are simple collections of object files, there is no difference between linking a static library or several object files If you notice when going to compile the executable linka libdl and the static library, then the executable will be linked to dynamic library and will not be a static executable.
Re: Dynamically calling shared objects from statically build executable allowed
On Monday, 10 February 2020 at 13:14:50 UTC, Ernesto Castellotti wrote: On Monday, 10 February 2020 at 04:41:31 UTC, Andre Pany wrote: Is this a bug with LDC and DMD, or is it not allowed to dynamically call a SO from a statically build executable on linux On Unix systems it is not possible to dynamically load a library shared by a static executable, I don't know if it works differently for Windows. This is because it is absolutely necessary to link libdl dynamically, you cannot link static. For GNU/Linux systems there is this alternative to dlopen/dlsym that does not require dynamic link: https://www.gnu.org/software/libtool/manual/html_node/Dlpreopening.html This is a topic I almost have no knowledge, therefore a question. If I understand this StackOverflow question correctly, it is possible to call dynamically a shared object from a static library (with dlopen): https://stackoverflow.com/questions/17862272/dlopen-a-dynamic-library-from-a-static-library-linux-c But I understand from you it is not possible dynamically call a shared object from a static executable. Therefore it works for static libraries but not for statically executables? Kind regards Andre
Re: Default value for member class
On 2/10/20 1:18 PM, JN wrote:
class IntValue
{
int x = 5;
}
class Foo
{
IntValue val = new IntValue();
}
void main()
{
Foo f1 = new Foo();
Foo f2 = new Foo();
assert(f1.val == f2.val);
}
Is this expected?
Define "expected" ;)
It's been this way for a while actually. It's the way it's currently
implemented, but I wouldn't say that anyone really expects this. The end
result is you just shouldn't create default values for object members.
Or should each Foo have their own IntValue object?
That would be ideal.
They're equal right now, changing one changes the other. When exactly is
the "new IntValue" happening? On program init, or when calling new Foo()
for the first time?
The new IntValue is happening at compile-time and stuck in the static
data segment. Then every new instance of Foo gets a pointer to that one
instance.
-Steve
Re: Default value for member class
On Monday, 10 February 2020 at 18:18:16 UTC, JN wrote: Is this expected? Yes, it is per the spec, though new users find it weird. Maybe we should change this but any static initializer is run at CTFE. Then the *static pointer* is put into the static initializer, which is just copied over before the constructor. So it ends up being an instance reference to a static object. If you want a new one, call `new Foo` in a regular constructor.
Default value for member class
class IntValue
{
int x = 5;
}
class Foo
{
IntValue val = new IntValue();
}
void main()
{
Foo f1 = new Foo();
Foo f2 = new Foo();
assert(f1.val == f2.val);
}
Is this expected? Or should each Foo have their own IntValue
object? They're equal right now, changing one changes the other.
When exactly is the "new IntValue" happening? On program init, or
when calling new Foo() for the first time?
Re: Is it possible to use DMD as a library to compile strings at runtime?
On Monday, 10 February 2020 at 12:31:03 UTC, Basile B. wrote: On Friday, 31 January 2020 at 14:25:30 UTC, Basile B. wrote: [...] about [1] (llvm) I've made a better binding this weekend: https://gitlab.com/basile.b/llvmd-d Seriouly I cant believe that at some point in the past I translated by hand. dstep can handle big C libraries. ah ah ah, I meant https://gitlab.com/basile.b/llvm-d
Re: Dynamically calling shared objects from statically build executable allowed
On Monday, 10 February 2020 at 04:41:31 UTC, Andre Pany wrote: Is this a bug with LDC and DMD, or is it not allowed to dynamically call a SO from a statically build executable on linux On Unix systems it is not possible to dynamically load a library shared by a static executable, I don't know if it works differently for Windows. This is because it is absolutely necessary to link libdl dynamically, you cannot link static. For GNU/Linux systems there is this alternative to dlopen/dlsym that does not require dynamic link: https://www.gnu.org/software/libtool/manual/html_node/Dlpreopening.html
Re: Is it possible to use DMD as a library to compile strings at runtime?
On Friday, 31 January 2020 at 14:25:30 UTC, Basile B. wrote: On Friday, 31 January 2020 at 11:19:37 UTC, Saurabh Das wrote: I see that DUB has DMD as a library package, but I was not able to understand how to use it. Is it possible to use DMD as a library within a D program to compile a string to machine code and run the compiled code at runtime? Thanks, Saurabh Fundamentally DMD as a library is a front-end. Jitting is to the backend side. You'll be able to lex and parse the source to get an AST, to perform the semantic passes on this AST and that's all. Then to run this code you would need to make an AST visitor that will generate the binary code to execute. Even using a specialized library with jitting abilities, such as LLVM-d [1] or libfirm-d [2], this would be *quite* a journey. [1] https://github.com/MoritzMaxeiner/llvm-d [2] https://gitlab.com/basile.b/libfirm-d about [1] (llvm) I've made a better binding this weekend: https://gitlab.com/basile.b/llvmd-d Seriouly I cant believe that at some point in the past I translated by hand. dstep can handle big C libraries.
Re: GtkD on Windows: notes + question
On Sunday, 9 February 2020 at 14:08:02 UTC, Daniel Kozak wrote: "lflags-windows": ["/SUBSYSTEM:WINDOWS", "/ENTRY:mainCRTStartup"], [snip] Is there a way to avoid the console Window, at least for release builds? Thank you! Your solution I guess is for dub.json. For those using dub.sdl the necessary line is: lflags "/SUBSYSTEM:WINDOWS" "/ENTRY:mainCRTStartup" platform="windows"
Re: GtkD on Windows: notes + question
On Sunday, 9 February 2020 at 14:08:02 UTC, Daniel Kozak wrote: "lflags-windows": ["/SUBSYSTEM:WINDOWS", "/ENTRY:mainCRTStartup"], [snip] Is there a way to avoid the console Window, at least for release builds? Thank you! Your solution I guess is for dub.json. For those using dub.sdl the necessary line is: lflags "/SUBSYSTEM:WINDOWS" "/ENTRY:mainCRTStartup" platform="windows"
