On Friday, 2 April 2021 at 19:49:30 UTC, ikod wrote:
On Thursday, 1 April 2021 at 22:35:01 UTC, tsbockman wrote:
Suppose I have a templated struct member function for which I
can compute at compile-time when the function is memory safe,
and when it is not. But, the compiler cannot correctly
de
On Saturday, 3 April 2021 at 20:55:40 UTC, Preetpal wrote:
On Saturday, 3 April 2021 at 19:02:34 UTC, Brad wrote:
Obviously it is a type mismatch - I have tried using to!uint
to convert the result from unpredictableSeed to a type that
will match - but that just causes more errors.
Thank you i
On Saturday, 3 April 2021 at 22:04:33 UTC, Bastiaan Veelo wrote:
On Saturday, 3 April 2021 at 19:02:34 UTC, Brad wrote:
I just do not know enough about the D libraries to figure out
what is wrong. I know it is a case of type mismatch. The
example appears on the Mir-Random page as listed under
On Saturday, 3 April 2021 at 19:02:34 UTC, Brad wrote:
I just do not know enough about the D libraries to figure out
what is wrong. I know it is a case of type mismatch. The
example appears on the Mir-Random page as listed under DUB:
https://code.dlang.org/packages/mir-random
[...]
I think
On Saturday, 3 April 2021 at 19:02:34 UTC, Brad wrote:
Obviously it is a type mismatch - I have tried using to!uint to
convert the result from unpredictableSeed to a type that will
match - but that just causes more errors.
Thank you in advance.
I was able to compile the sample without any is
I just do not know enough about the D libraries to figure out
what is wrong. I know it is a case of type mismatch. The
example appears on the Mir-Random page as listed under DUB:
https://code.dlang.org/packages/mir-random
The code looks like this:
```d
void main()
{
import mir.random;
On Saturday, 3 April 2021 at 13:50:27 UTC, ag0aep6g wrote:
On 03.04.21 15:34, DLearner wrote:
The following produces the expected result.
However, changing extern(C) to extern(D) causes linker
failures.
To me, that is bizarre.
Testmain:
extern(C) int xvar;
[...]
Testmod:
extern extern(C) in
On 04/04/2021 2:48 AM, DLearner wrote:
On Saturday, 3 April 2021 at 13:38:25 UTC, rikki cattermole wrote:
On 04/04/2021 2:34 AM, DLearner wrote:
However, changing extern(C) to extern(D) causes linker failures.
To me, that is bizarre.
extern(D) sets the ABI AND mangling.
D mangling incorpo
On 03.04.21 15:34, DLearner wrote:
The following produces the expected result.
However, changing extern(C) to extern(D) causes linker failures.
To me, that is bizarre.
Testmain:
extern(C) int xvar;
[...]
Testmod:
extern extern(C) int xvar;
With `extern (C)`, those two `xvar`s refer to the sa
On Saturday, 3 April 2021 at 13:38:25 UTC, rikki cattermole wrote:
On 04/04/2021 2:34 AM, DLearner wrote:
However, changing extern(C) to extern(D) causes linker
failures.
To me, that is bizarre.
extern(D) sets the ABI AND mangling.
D mangling incorporates things like the module name.
I'm
Why does this code
```d
import std.stdio,std.typecons;
struct EC {
Exception [] ex;
auto opAssign (X: void) (lazy X f)
{
writeln (__PRETTY_FUNCTION__);
try return f (); catch (Exception e) ex ~= e;
}
}
class E : Exception { this (string s) { super (s); } }
void bar (int
On 04/04/2021 2:34 AM, DLearner wrote:
However, changing extern(C) to extern(D) causes linker failures.
To me, that is bizarre.
extern(D) sets the ABI AND mangling.
D mangling incorporates things like the module name.
The __gshared is irrelevant to it working between modules, but
it is relevant if you want C compatibility between threads
(NOTE: extern(C) sets mangling, otherwise the module would be
encoded in its name).
Solved:
The following produces the expected result.
However, changing extern(C) to extern
--- main.d
module main;
extern(C) __gshared int foo;
import std;
void main()
{
import foo : func;
func;
writeln(foo);
}
--- foo.d
module foo;
extern extern(C) __gshared int foo;
void func() {
foo++;
}
The __gshared is irrelevant to it working between modules, but it is
rel
https://dlang.org/spec/attribute.html#gshared
However, you should be using the module system for accessing
globals, rather than redeclaring them.
If the module system is dumped, and evrything put into one file,
works perfectly.
With or without __gshared in from of 'int xvar'.
int xvar;
void
extern(L) extern otherQualifiersIfAny variableType
variableName; //appears to be a variable declared outside of
the module, so at link time a .obj file will have to declare a
variable with this symbol name or else the linker will error
out.
```
It seems that case 4 is what you desired but i do
Tried the following, same result (1,0,2,1):
testmain:
__gshared int xvar;
import testmod;
void main() {
import std.stdio;
writeln("Entering: main");
xvar = 1;
writeln("xvar=", xvar);
testsub();
writeln("xvar=", xvar);
writeln("Leaving: main");
}
testmod:
void testsub() {
On Saturday, 3 April 2021 at 10:17:14 UTC, DLearner wrote:
Does this mean D has no equivalent of C globals?
What is the D way of doing this?
With __gshared.
If the global is defined from within another language, apparently
you'd have to do [extern(C) extern __gshared
*name*](https://dlang.org
On 03/04/2021 11:17 PM, DLearner wrote:
On Saturday, 3 April 2021 at 10:05:45 UTC, rikki cattermole wrote:
On 03/04/2021 11:01 PM, DLearner wrote:
[...]
TLS variable with D mangling, not a c global.
[...]
That is a regular variable.
Setting the calling convention/mangling like that doe
On Saturday, 3 April 2021 at 10:03:09 UTC, rikki cattermole wrote:
On 03/04/2021 10:58 PM, rikki cattermole wrote:
Nullable has an alias this which has been deprecated.
It is due for removal (the alias this).
You can remove it manually from your copy of phobos source.
Otherwise you'll just h
On Saturday, 3 April 2021 at 10:05:45 UTC, rikki cattermole wrote:
On 03/04/2021 11:01 PM, DLearner wrote:
[...]
TLS variable with D mangling, not a c global.
[...]
That is a regular variable.
Setting the calling convention/mangling like that doesn't make
any sense and shouldn't be allow
On 03/04/2021 11:01 PM, DLearner wrote:
'Testmain' imports module 'testmod'.
Both are shown below.
I expected 1,1,2,2.
I got 1,0,2,1 - which speaks to scope/extern misunderstanding
Any ideas?
Best regards
Testmain:
int xvar;
TLS variable with D mangling, not a c global.
import testmod;
voi
'Testmain' imports module 'testmod'.
Both are shown below.
I expected 1,1,2,2.
I got 1,0,2,1 - which speaks to scope/extern misunderstanding
Any ideas?
Best regards
Testmain:
int xvar;
import testmod;
void main() {
import std.stdio;
writeln("Entering: main");
xvar = 1;
writeln("xva
On 03/04/2021 10:58 PM, rikki cattermole wrote:
Nullable has an alias this which has been deprecated.
It is due for removal (the alias this).
You can remove it manually from your copy of phobos source.
Otherwise you'll just have to wait until it is removed upstream.
(deprecation are not err
Nullable has an alias this which has been deprecated.
It is due for removal (the alias this).
You can remove it manually from your copy of phobos source.
Otherwise you'll just have to wait until it is removed upstream.
(deprecation are not errors, so you can ignore them).
I am using the OpenMPI binding and, in recent times, I have been
getting a deprecation message when compiling. It seems to be
related to assigning Nullable!int entries to an associative
array. The following program shows the same message three times
but it does run as I expect.
import std.
26 matches
Mail list logo
