Re: "chain" vs "~"
On Monday, 8 August 2022 at 18:49:26 UTC, Ali Çehreli wrote: On 8/6/22 18:22, pascal111 wrote: > [...] To add to what has already mentioned, - chain can be used on ranges that are of different element types [...] Thanks for explanation!
Re: "chain" vs "~"
On Monday, 8 August 2022 at 13:26:49 UTC, frame wrote: On Monday, 8 August 2022 at 01:05:40 UTC, pascal111 wrote: In next program, I used "insertInPlace", not "~" nor "chain", should I use "~" or it's the same as "insertInPlace"? https://github.com/pascal111-fra/D/blob/main/coco.d As you may noticed, `insertInPlace` has another purpose than just appending data. And it will create a new range (to call itself again), moves memory and places the item there, so it's rather inefficient than just appending a single item via "~". I applied "~" in next program: https://github.com/pascal111-fra/D/blob/main/proj06.d
Re: Acess variable that was set by thread
On Monday, 8 August 2022 at 20:36:34 UTC, Steven Schveighoffer
wrote:
[...]
shared gives you a sense that the language is helping you
prevent problems. Again, if C isn't playing ball, this is a lie.
The C side is playing ball, by whatever rules the C library
chooses.
`shared` (with `-preview=nosharedaccess`) prevents you from going
on the field. Can't unwittingly commit a foul. Can't hurt
yourself. You can tell the compiler with a cast that (1) you're
sure you want to play, and (2) you're going to play by the rules
of the C side (whatever they are).
`__gshared` just lets you run on the field. Don't know the rules?
The compiler doesn't care. Have fun breaking your legs.
[...]
Consider if the proper way to use such a variable is to call
`properlyUse(int *)`, it won't accept a `shared int *`. Now you
are doubly-sure to mess up using it specifically because it's
marked `shared`.
With `__gshared`:
```d
extern(C) extern __gshared int x;
void fun() { x = 42; } /* compiles, race condition */
```
I never even realize that I'm doing something dangerous, because
my first naive attempt passes compilation and seems to work fine.
With `shared` (and `-preview=nosharedaccess`):
```d
extern(C) extern shared int x;
void fun() { x = 42; } /* error */
```
If I remember to check the documentation, I might find out about
`properlyUse`. As you suggest, I come up with this:
```d
extern(C) extern shared int x;
void fun() { properlyUse(, 42); } /* still error because
`shared` */
```
I'm forced to think more about thread-safety. I figure that it's
ok to cast away `shared` in this case, because I'm calling the
thread-safe `properlyUse` function. So:
```d
extern(C) extern shared int x;
void fun() { properlyUse(cast(int*) , 42); } /* compiles, is
correct */
```
I don't believe that people are more likely to get that right
with `__gshared`. The call to `properlyUse` might look nicer
without the cast, but I'm not buying that people remember to use
the function without the compiler yelling at them.
Even if they get it right the first time, they're bound to slip
up as time progresses. When simple, incorrect code compiles, it
will surely make its way into the source files.
Thread-safety is hard to get right. We need every help we can get
from the compiler. `__gshared` provides zero help. `shared` at
least highlights the interesting spots.
Re: Supporting Arabic in GUI
On Monday, 8 August 2022 at 19:47:35 UTC, Sergey wrote: On Sunday, 7 August 2022 at 23:48:22 UTC, pascal111 wrote: [...] I think it is possible to find framework to solve the issues in D.. my guess is based on information from the project ArabiaWeather https://dlang.org/orgs-using-d.html They have a YouTube talk about D. Maybe you could find their contacts and ask your questions related to their techstack and framework. It seems formal channel or company. I don't have resources that make me able to contact with a formal company. I think Gtk is nice free solution.
Re: Acess variable that was set by thread
On 8/8/22 4:04 PM, ag0aep6g wrote: On Monday, 8 August 2022 at 19:33:14 UTC, Steven Schveighoffer wrote: There's nothing clever. If you want to access C globals, you should use `__gshared`, because that's what it is. Using `shared`, isn't going to save you at all. Yes, using `shared` does save you. C might not have a `shared` qualifier, but C programmers still have to think about thread-safety. Calling a C function or accessing a C global always comes with some (possibly implied) contract on how to do it safely from multiple threads (the contract might be: "don't"). `shared` (with `-preview=nosharedaccess`) forces you to think about what the contract is. `__gshared` doesn't. shared gives you a sense that the language is helping you prevent problems. Again, if C isn't playing ball, this is a lie. [...] Using `__gshared` to share data with C is as safe as using `-boundscheck=on` and sending the array into C which has no such restrictions. No it's not. C always being unsafe is true but irrelevant. The point is what you can/can't do on the D side. `-boundscheck=on` - Can't easily mess up on the D side. C side can still mess up. `-boundscheck=off` - Can easily mess up on the D side. `shared` - Can't easily mess up on the D side. C side can still mess up. `__gshared` - Can easily mess up on the D side. Bounds are defined the same in both C and D -- you have a pointer and a size, and you can't exceed that size. Yes, the data is conveyed differently, but this is trivial to understand and use. `shared` doesn't fix anything on the D side. All sides must use the same mechanism to synchronize data. And there is no standard for synchronizing data. Consider if the proper way to use such a variable is to call `properlyUse(int *)`, it won't accept a `shared int *`. Now you are doubly-sure to mess up using it specifically because it's marked `shared`. -Steve
Re: Acess variable that was set by thread
On Monday, 8 August 2022 at 19:33:14 UTC, Steven Schveighoffer wrote: There's nothing clever. If you want to access C globals, you should use `__gshared`, because that's what it is. Using `shared`, isn't going to save you at all. Yes, using `shared` does save you. C might not have a `shared` qualifier, but C programmers still have to think about thread-safety. Calling a C function or accessing a C global always comes with some (possibly implied) contract on how to do it safely from multiple threads (the contract might be: "don't"). `shared` (with `-preview=nosharedaccess`) forces you to think about what the contract is. `__gshared` doesn't. [...] Using `__gshared` to share data with C is as safe as using `-boundscheck=on` and sending the array into C which has no such restrictions. No it's not. C always being unsafe is true but irrelevant. The point is what you can/can't do on the D side. `-boundscheck=on` - Can't easily mess up on the D side. C side can still mess up. `-boundscheck=off` - Can easily mess up on the D side. `shared` - Can't easily mess up on the D side. C side can still mess up. `__gshared` - Can easily mess up on the D side.
Re: Supporting Arabic in GUI
On Sunday, 7 August 2022 at 23:48:22 UTC, pascal111 wrote: I have no idea about GUI or Rad programming in D; it's not its time, but I'm curious to know if D is fine supporting for Arabic language in the GUI applications or we will have some issues like I met - in my experience - in Free Pascal. This is a topic where we trying to make a custom message box supporting Arabic as what's supposed to be, but we didn't reach although that the degree we want: https://forum.lazarus.freepascal.org/index.php/topic,59765.0.html I think it is possible to find framework to solve the issues in D.. my guess is based on information from the project ArabiaWeather https://dlang.org/orgs-using-d.html They have a YouTube talk about D. Maybe you could find their contacts and ask your questions related to their techstack and framework.
Re: Acess variable that was set by thread
On 8/8/22 10:54 AM, ag0aep6g wrote: On Monday, 8 August 2022 at 14:29:43 UTC, Steven Schveighoffer wrote: C has no notion of shared, so it's not the right type. Putting `shared` on it is kind of lying, and can lead to trouble. Better to be explicit about what it is. Nonsense. Putting `shared` on a shared variable is not "lying". It doesn't matter if C makes the distinction. D does. If you have all these nice abstractions and careful locking around accessing the data, but C doesn't, how is this better? Do you feel safer because of this? I'm not saying you should use `__gshared` liberally, or for cases where you are using this only in D. But to say you should *never* use it is incorrect. If you're clever enough to identify a valid use case for `__gshared` and write correct code with it, then you're clever enough to figure out when not to listen to me. There's nothing clever. If you want to access C globals, you should use `__gshared`, because that's what it is. Using `shared`, isn't going to save you at all. `__gshared` is about as bad as `-boundscheck=off`. They're both glaring safety holes. But people want to be propper hackers (TM). And propper hackers know how to handle these foot-guns, of course. And then they shoot their feet off. Using `__gshared` to share data with C is as safe as using `-boundscheck=on` and sending the array into C which has no such restrictions. The conclusion here really should just be, don't use C. -Steve
Re: Acess variable that was set by thread
On Monday, 8 August 2022 at 17:45:03 UTC, bauss wrote: On Monday, 8 August 2022 at 13:55:02 UTC, ag0aep6g wrote: auto x = s.x; ``` Your problem is here and not because it was __gshared. You're copying the value and obviously it can be changed in the meantime, that's common sense. You shouldn't use it like that. You should access s.x directly instead. kdevel has already addressed this. And in the case of shared it can leave the same result if the reading thread locks first then it will read and process the value before it's changed. You're right that `shared` doesn't fix the race condition. Without `-preview=nosharedaccess`, there is no difference at all. So you might as well use `shared` ;) But with `-preview=nosharedaccess`, the code no longer compiles, and you're forced to think about how to access the shared data safely. Which is good. So: Never ever use `__gshared`, and always use `-preview=nosharedaccess`.
Re: "chain" vs "~"
On 8/6/22 18:22, pascal111 wrote:
> Why we use "chain" while we have "~":
>
> '''D
> int[] x=[1,2,3];
> int[] y=[4,5,6];
>
> auto z=chain(x,y);
> auto j=x~y;
> '''
To add to what has already mentioned,
- chain can be used on ranges that are of different element types
- as usual, some of the ranges may be generators
- although obscure, one may sort in-place over multiple ranges (requires
RandomAccessRange.)
This program shows the first two points:
import std; // Apologies for terseness
void main() {
auto ints = [ 10, 3, 7 ];
auto squares = iota(10).map!squared.take(5);
auto doubles = [ 1.5, -2.5 ];
auto c = chain(ints, squares, doubles);
// Different types but CommonType is 'double' here:
static assert(is(ElementType!(typeof(c)) == double));
// Prints [10, 3, 7, 0, 1, 4, 9, 16, 1.5, -2.5]
writeln(c);
}
auto squared(T)(T value) {
return value * value;
}
And this one shows how one can sort in-place multiple arrays:
import std; // Ditto
void main() {
auto a = [ 10, 3, 7 ];
auto b = [ 15, -25 ];
auto c = chain(a, b);
sort(c);
writeln(a); // Prints [-25, 3, 7]
writeln(b); // Prints [10, 15]
}
Ali
Re: Acess variable that was set by thread
On Monday, 8 August 2022 at 17:45:03 UTC, bauss wrote: On Monday, 8 August 2022 at 13:55:02 UTC, ag0aep6g wrote: auto x = s.x; [...] Your problem is here and not because it was __gshared. You're copying the value and obviously it can be changed in the meantime, that's common sense. The value of `x` changes while `x` is being read. You shouldn't use it like that. You should access s.x directly instead. ``` //auto x = s.x; assert(s.x == 0 || s.x == -1, to!string(s.x, 16)); ``` this replaces one race by three races which even prevents spotting the reason for the triggered assertion: ``` $ > ./race core.exception.AssertError@race.d(40): ``` And in the case of shared it can leave the same result if the reading thread locks first then it will read and process the value before it's changed. ???
Re: Acess variable that was set by thread
On Monday, 8 August 2022 at 13:55:02 UTC, ag0aep6g wrote: auto x = s.x; ``` Your problem is here and not because it was __gshared. You're copying the value and obviously it can be changed in the meantime, that's common sense. You shouldn't use it like that. You should access s.x directly instead. And in the case of shared it can leave the same result if the reading thread locks first then it will read and process the value before it's changed.
Re: How do I initialize a templated constructor?
Thank you all for the info! I'll try to find another way to do it as it is not possible to match the exact behavior I want! Have a great day everyone!
Re: Acess variable that was set by thread
On Monday, 8 August 2022 at 14:29:43 UTC, Steven Schveighoffer wrote: C has no notion of shared, so it's not the right type. Putting `shared` on it is kind of lying, and can lead to trouble. Better to be explicit about what it is. Nonsense. Putting `shared` on a shared variable is not "lying". It doesn't matter if C makes the distinction. D does. I'm not saying you should use `__gshared` liberally, or for cases where you are using this only in D. But to say you should *never* use it is incorrect. If you're clever enough to identify a valid use case for `__gshared` and write correct code with it, then you're clever enough to figure out when not to listen to me. Everyone else, don't ever use `__gshared` ever. `__gshared` is about as bad as `-boundscheck=off`. They're both glaring safety holes. But people want to be propper hackers (TM). And propper hackers know how to handle these foot-guns, of course. And then they shoot their feet off.
Re: Fix template parameter
On Monday, 8 August 2022 at 12:46:48 UTC, bauss wrote: On Monday, 8 August 2022 at 12:02:02 UTC, Dom Disc wrote: ```D pure @nogc @safe BigInt opAssign(T : BigInt)(T x); ``` This will only be included in the object file if used. ```D pure @nogc @safe BigInt opAssign(BigInt x); ``` This will always be in the object file. Ah, ok. But shouldn't the linker throw it out of an executable, if it is not used? I mean, even the most dump linker should be able to do this basic optimization...
Re: Acess variable that was set by thread
On 8/8/22 10:12 AM, ag0aep6g wrote: On Monday, 8 August 2022 at 13:31:04 UTC, Steven Schveighoffer wrote: On 8/8/22 6:17 AM, ag0aep6g wrote: [...] Never ever use `__gshared` ever. It's a glaring safety hole. Use `shared` instead. If you are interfacing with C, you need __gshared. But yeah, you should use shared in this case. A quick test suggests that `extern(C) extern shared` works fine. As far as I can tell, `__gshared` is only ever ok-ish when you want to access a shared C variable in a single-threaded program. And then you're still setting yourself up for failure if you later add more threads. So, never ever use `__gshared` (in multi-threaded code) ever. C has no notion of shared, so it's not the right type. Putting `shared` on it is kind of lying, and can lead to trouble. Better to be explicit about what it is. I'm not saying you should use `__gshared` liberally, or for cases where you are using this only in D. But to say you should *never* use it is incorrect. -Steve
Re: Acess variable that was set by thread
On Monday, 8 August 2022 at 13:31:04 UTC, Steven Schveighoffer wrote: On 8/8/22 6:17 AM, ag0aep6g wrote: [...] Never ever use `__gshared` ever. It's a glaring safety hole. Use `shared` instead. If you are interfacing with C, you need __gshared. But yeah, you should use shared in this case. A quick test suggests that `extern(C) extern shared` works fine. As far as I can tell, `__gshared` is only ever ok-ish when you want to access a shared C variable in a single-threaded program. And then you're still setting yourself up for failure if you later add more threads. So, never ever use `__gshared` (in multi-threaded code) ever.
Re: How do I initialize a templated constructor?
Here is another one that uses nested templates:
import std.stdio;
template TestArray(ulong element_n) {
struct TestArrayImpl(Type) {
int[element_n] elements;
this(ulong number) {
pragma(msg, "The type is: ", Type);
writeln("Constructing with ", number);
}
}
auto makeFor(string s)(ulong number) {
return TestArrayImpl!(mixin(s))(number);
}
}
void main() {
auto ta = TestArray!10.makeFor!"int"(60);
}
Ali
Re: Acess variable that was set by thread
On Monday, 8 August 2022 at 10:17:57 UTC, ag0aep6g wrote: By the way, is there some resource that recommends `__gshared` over `shared`? It seems that many newbies reach for `__gshared` first for some reason. Would be also good if the specs would tell more about those "guards": Unlike the shared attribute, __gshared provides no safe-guards against data races or other multi-threaded synchronization issues. The only thing I see is that the compiler bails about type incompatibilities but how does it help in case of synchronization/locking issues?
Re: Acess variable that was set by thread
On 8/8/22 00:14, vc wrote:
> i will like to hear thoughts even if it works
> for me
__gshared would work as well but I would consider std.concurrency first.
Just a simple example:
import std.stdio;
import std.concurrency;
import core.thread;
struct Result {
int value;
}
struct Done {
}
void run()
{
bool done = false;
while (!done) {
writeln("Derived thread running.");
receiveTimeout(1.seconds,
(Done msg) {
done = true;
});
}
// Send the result to the owner
// (I made assumptions; the thread may produce
// results inside the while loop above.)
ownerTid.send(Result(42));
}
void main()
{
auto worker = spawn();
Thread.sleep(5.seconds);
worker.send(Done());
auto result = receiveOnly!Result();
writeln("Here is the result: ", result);
}
Related, Roy Margalit's DConf 2022 presentation was based on traps
related to sequential consistency. The video will be moved to a better
place but the following link should work for now:
https://youtu.be/04gJXpJ1i8M?t=5658
Ali
Re: Acess variable that was set by thread
On Monday, 8 August 2022 at 12:45:20 UTC, bauss wrote:
On Monday, 8 August 2022 at 10:17:57 UTC, ag0aep6g wrote:
Never ever use `__gshared` ever.
[...]
To sum it up:
Single-write/Single-read?
__gshared
Single-write/Multi-read?
__gshared
Multi-write/Single-read?
shared
Multi-write/Multi-read?
shared
Nope. All of those can be race conditions.
Here's a single-write, single-read one:
```d
align(64) static struct S
{
align(1):
ubyte[60] off;
ulong x = 0;
}
__gshared S s;
void main()
{
import core.thread: Thread;
import std.conv: to;
new Thread(() {
foreach (i; 0 .. uint.max)
{
s.x = 0;
s.x = -1;
}
}).start();
foreach (i; 0 .. uint.max)
{
auto x = s.x;
assert(x == 0 || x == -1, to!string(x, 16));
}
}
```
If you know how to access the variable safely, you can do it with
`shared`.
I maintain: Never ever use `__gshared` ever.
Re: How do I initialize a templated constructor?
On 8/8/22 9:36 AM, Steven Schveighoffer wrote:
On 8/8/22 1:38 AM, rempas wrote:
In the following struct (as an example, not real code):
```
struct TestArray(ulong element_n) {
int[element_n] elements;
this(string type)(ulong number) {
pragma(msg, "The type is: " ~ typeof(type).stringof);
}
}
```
I want to create it and be able to successfully initialize the
template parameters
of the constructor but until now, I wasn't able to find a way to
successfully do
that. Is there a way you guys know? I have tried the following:
```
void main() {
// Doesn't work
auto val = TestArray!(10, "int")(60);
// Doesn't work either
auto val = TestArray!(10).TestArray!("int")(60);
// Neither this works
auto val = TestArray!(10).this!("int")(60);
}
```
As with every question I make, the solution must be "betterC"
compatible so I can use it.
Thanks a lot!
You cannot explicitly specify template parameters for constructors.
The only true solution is to use a factory function:
```d
TestArray!T testarray(string s, T)(T val) {
... // code that depends on s here
return TestArray!T(...) // call ctor here.
}
```
Just thought of another possibility:
```d
struct StringAnnotated(string s, T)
{
T val;
}
StringAnnotated!(s, T) annotate(string s, T)(T val)
{
return StringAnnotated!(s, T)(val);
}
struct TestArray(ulong element_n)
{
...
this(T)(T val) if (isInstanceOf!(StringAnnotated, T))
{
...
}
}
// use like
TestArray!10(60.annotate!"int");
```
-Steve
Re: How do I initialize a templated constructor?
On 8/8/22 1:38 AM, rempas wrote:
In the following struct (as an example, not real code):
```
struct TestArray(ulong element_n) {
int[element_n] elements;
this(string type)(ulong number) {
pragma(msg, "The type is: " ~ typeof(type).stringof);
}
}
```
I want to create it and be able to successfully initialize the template
parameters
of the constructor but until now, I wasn't able to find a way to
successfully do
that. Is there a way you guys know? I have tried the following:
```
void main() {
// Doesn't work
auto val = TestArray!(10, "int")(60);
// Doesn't work either
auto val = TestArray!(10).TestArray!("int")(60);
// Neither this works
auto val = TestArray!(10).this!("int")(60);
}
```
As with every question I make, the solution must be "betterC" compatible
so I can use it.
Thanks a lot!
You cannot explicitly specify template parameters for constructors.
The only true solution is to use a factory function:
```d
TestArray!T testarray(string s, T)(T val) {
... // code that depends on s here
return TestArray!T(...) // call ctor here.
}
```
-Steve
Re: How do I initialize a templated constructor?
On 8/7/22 22:38, rempas wrote:
> I want to create it and be able to successfully initialize the template
> parameters
> of the constructor but until now, I wasn't able to find a way to
> successfully do
> that.
The following method uses a convenience function but it's not really needed:
import std.stdio;
struct TestArray(ulong element_n, string type) {
int[element_n] elements;
mixin(type) member;
pragma(msg, "The type is: ", typeof(member));
this(ulong number) {
writeln("Constructing with ", number);
}
}
auto makeTestArray(ulong element_n, string type)(ulong number) {
return TestArray!(element_n, type)(number);
}
void main() {
auto ta = makeTestArray!(10, "int")(60);
}
Ali
Re: Fix template parameter
On 8/8/22 8:02 AM, Dom Disc wrote: Hello. I found in the documentation functions declared like this: ```D pure @nogc @safe BigInt opAssign(T : BigInt)(T x); ``` What is the difference to declaring it like: ```D pure @nogc @safe BigInt opAssign(BigInt x); ``` To me the first declaration seems to be unnecessarily bloated, so I ask myself: does it provide any kind of advantage? I can't see it. Just a guess, but there was a time in the distant past when you could not overload template functions with regular functions. Perhaps that's why? Otherwise, no there really isn't a difference in this case. -Steve
Re: Acess variable that was set by thread
On 8/8/22 6:17 AM, ag0aep6g wrote: On Monday, 8 August 2022 at 07:14:33 UTC, vc wrote: it seems change it to working is working ```d __gshared bool zeus; ``` but as I'm new in to D, i will like to hear thoughts even if it works for me Never ever use `__gshared` ever. It's a glaring safety hole. Use `shared` instead. If you are interfacing with C, you need __gshared. But yeah, you should use shared in this case. -Steve
Re: Supporting Arabic in GUI
On Monday, 8 August 2022 at 00:23:52 UTC, pascal111 wrote: On Monday, 8 August 2022 at 00:20:53 UTC, pascal111 wrote: On Monday, 8 August 2022 at 00:12:07 UTC, Emanuele Torre wrote: [...] So, the reason is the toolkit. I guessed D has specific library for GUI, and with that I judged D as whole that if it supports Arabic or not. [...] I mean "my own time" that I'm still studying D basics, so I'll study GUI programming at another time, but if there are available resources for GUI, I would like to take a look in 'em. EDIT: The last part of my previous post is lost. I'll retype it again with some changes. I mean with time "my own time" that I'm studying D basic now, but if there are resources for GUI in D, I would like to take a look in 'em. there is https://gtkdcoding.com/ if you want to use GtkD
Re: "chain" vs "~"
On Monday, 8 August 2022 at 01:05:40 UTC, pascal111 wrote: In next program, I used "insertInPlace", not "~" nor "chain", should I use "~" or it's the same as "insertInPlace"? https://github.com/pascal111-fra/D/blob/main/coco.d As you may noticed, `insertInPlace` has another purpose than just appending data. And it will create a new range (to call itself again), moves memory and places the item there, so it's rather inefficient than just appending a single item via "~".
Re: How do I initialize a templated constructor?
On Monday, 8 August 2022 at 05:38:31 UTC, rempas wrote:
In the following struct (as an example, not real code):
```
struct TestArray(ulong element_n) {
int[element_n] elements;
this(string type)(ulong number) {
pragma(msg, "The type is: " ~ typeof(type).stringof);
}
}
```
I want to create it and be able to successfully initialize the
template parameters
of the constructor but until now, I wasn't able to find a way
to successfully do
that. Is there a way you guys know? I have tried the following:
```
void main() {
// Doesn't work
auto val = TestArray!(10, "int")(60);
// Doesn't work either
auto val = TestArray!(10).TestArray!("int")(60);
// Neither this works
auto val = TestArray!(10).this!("int")(60);
}
```
As with every question I make, the solution must be "betterC"
compatible so I can use it.
Thanks a lot!
I would move the constructor out of the struct into a helper
function, either global or as a static member:
```d
TestArray!n testArray(ulong n, string type)(ulong number) {
TestArray!n ret;
pragma(msg, "The type is: " ~ typeof(type).stringof);
ret.something = something; // do your constructor logic here
return ret;
}
```
which you can then use:
```d
auto t = testArray!(10, "int")(60);
```
As the template parameter being part of the constructor would
only change the constructor (and can't change anything like types
outside the ctor) it doesn't have any limitations and if you
define it in the same module as the struct you can also access
the private members.
Re: How do I initialize a templated constructor?
On Monday, 8 August 2022 at 12:26:50 UTC, rempas wrote: On Monday, 8 August 2022 at 11:03:21 UTC, Dom Disc wrote: You should first describe what you want to do clearly.
Re: Fix template parameter
On Monday, 8 August 2022 at 12:02:02 UTC, Dom Disc wrote: ```D pure @nogc @safe BigInt opAssign(T : BigInt)(T x); ``` This will only be included in the object file if used. What is the difference to declaring it like: ```D pure @nogc @safe BigInt opAssign(BigInt x); ``` This will always be in the object file. Someone can correct me if I'm wrong, but I think it's mostly linkage optimization.
Re: Acess variable that was set by thread
On Monday, 8 August 2022 at 10:17:57 UTC, ag0aep6g wrote: Never ever use `__gshared` ever. I don't agree with this entirely, it just depends on how you use it. In general you should go with shared, but __gshared does have its places. It's only problematic when it can be changed from multiple threads, but if it's only changed from a single thread but read from many then it generally isn't a problem. To sum it up: Single-write/Single-read? __gshared Single-write/Multi-read? __gshared Multi-write/Single-read? shared Multi-write/Multi-read? shared
Re: "only" vs "[]"
On Monday, 8 August 2022 at 11:35:48 UTC, pascal111 wrote: The output of next code is the same to extent that we feel that there's no difference between "only" and "[]", so what "only" added here?: '''D [1,2,3].writeln; only(1,2,3).writeln; ''' output: [1, 2, 3] [1, 2, 3] `only(1,2,3)` doesn't use GC. `[1,2,3]` allocate GC array.
Re: How do I initialize a templated constructor?
On Monday, 8 August 2022 at 11:03:21 UTC, Dom Disc wrote:
But if you only want to know the type of the parameter, you can
do this:
```D
struct TestArray(ulong element_n) {
int[element_n] elements;
this(type)(type number)
{
pragma(msg, "The type is: " ~ type.stringof);
}
}
```
Unfortunately this will not do as well
Re: How do I initialize a templated constructor?
On Monday, 8 August 2022 at 08:27:49 UTC, bauss wrote: Yeah I think the only template argument you can have for constructors are `this` which will refer to things like the class that inherited the current class etc. not sure what else, but you can't really pass anything to it yourself unfortunately. It's fine, thanks for trying in any case! But I think if you end up with something where you need different constructors with different type arguments then you're probably designing your program in a "wrong" way to begin with. Oh, trust me! I didn't designed my program wrong in my case. At least not the way I see it!
Fix template parameter
Hello. I found in the documentation functions declared like this: ```D pure @nogc @safe BigInt opAssign(T : BigInt)(T x); ``` What is the difference to declaring it like: ```D pure @nogc @safe BigInt opAssign(BigInt x); ``` To me the first declaration seems to be unnecessarily bloated, so I ask myself: does it provide any kind of advantage? I can't see it.
"only" vs "[]"
The output of next code is the same to extent that we feel that there's no difference between "only" and "[]", so what "only" added here?: '''D [1,2,3].writeln; only(1,2,3).writeln; ''' output: [1, 2, 3] [1, 2, 3]
Re: How do I initialize a templated constructor?
And then you can instantiate it with ```D auto val = TestArray!10(ubyte(60)); // if you want type to be ubyte ```
Re: How do I initialize a templated constructor?
On Monday, 8 August 2022 at 06:58:42 UTC, bauss wrote:
On Monday, 8 August 2022 at 05:38:31 UTC, rempas wrote:
In the following struct (as an example, not real code):
```
struct TestArray(ulong element_n) {
int[element_n] elements;
this(string type)(ulong number) {
pragma(msg, "The type is: " ~ typeof(type).stringof);
}
}
```
You cannot do this.
But if you only want to know the type of the parameter, you can
do this:
```D
struct TestArray(ulong element_n) {
int[element_n] elements;
this(type)(type number)
{
pragma(msg, "The type is: " ~ type.stringof);
}
}
```
Re: Acess variable that was set by thread
On Monday, 8 August 2022 at 07:14:33 UTC, vc wrote: it seems change it to working is working ```d __gshared bool zeus; ``` but as I'm new in to D, i will like to hear thoughts even if it works for me Never ever use `__gshared` ever. It's a glaring safety hole. Use `shared` instead. If you're running into compilation errors with `shared`, that's the compiler trying to keep you from shooting your foot off. You're supposed to think hard about thread-safety and only then cast `shared` away in the right spot. With `__gshared`, the compiler just pretends that it doesn't see that the variable is shared. You're pretty much guaranteed to produce race conditions unless you think even harder than you would have with `shared`. By the way, is there some resource that recommends `__gshared` over `shared`? It seems that many newbies reach for `__gshared` first for some reason.
Re: How do I initialize a templated constructor?
On Monday, 8 August 2022 at 07:37:16 UTC, rempas wrote: Thank you for all the great info! Unfortunately, while there is no problem in this example, this will not do for my real code as I need to have the argument in the constructor. Alternative, I have to change the design of the program completely Yeah I think the only template argument you can have for constructors are `this` which will refer to things like the class that inherited the current class etc. not sure what else, but you can't really pass anything to it yourself unfortunately. But I think if you end up with something where you need different constructors with different type arguments then you're probably designing your program in a "wrong" way to begin with.
Re: How do I initialize a templated constructor?
On Monday, 8 August 2022 at 06:58:42 UTC, bauss wrote:
```
this(string type)(ulong number) {
```
You cannot do this.
Instead your type should look like this:
First let's change it up a little bit.
```
struct TestArray(ulong element_n, string type) {
int[element_n] elements;
this(ulong number) {
pragma(msg, "The type is: " ~ typeof(type).stringof);
}
}
```
Now the above will still not work because you do `typeof(type)`
which will always yield string because type is as string and
also the typeof() is not needed in this case and will actually
yield an error.
If it must be a string then you can do it like this:
```
struct TestArray(ulong element_n, string type) {
int[element_n] elements;
this(ulong number) {
mixin("alias T = " ~ type ~ ";");
pragma(msg, "The type is: " ~ T.stringof);
}
}
```
However the ideal implementation is probably this:
```
struct TestArray(ulong element_n, T) {
int[element_n] elements;
this(ulong number) {
pragma(msg, "The type is: " ~ T.stringof);
}
}
```
To instantiate it you simply do:
```
TestArray!(10, "int") val = TestArray!(10, "int")(100);
```
Or
```
TestArray!(10, int) val = TestArray!(10, int)(100);
```
I will recommend an alias to make it easier:
```
alias IntTestArray = TestArray!(10, int);
...
IntTestArray val = IntTestArray(100);
```
Thank you for all the great info! Unfortunately, while there is
no problem in this example, this will
not do for my real code as I need to have the argument in the
constructor. Alternative, I have to
change the design of the program completely
Re: Acess variable that was set by thread
On Monday, 8 August 2022 at 02:49:06 UTC, Steven Schveighoffer wrote: On 8/7/22 9:36 PM, vc wrote: Hello, i have the following code, the flora contains a boolean zeus in the DerivedThread the boolean zeus was set to true; but when i'm trying to access it outside the thread in main it returns me false; any thoughts ? is zeus declared just as: ```d bool zeus; ``` Because if so, it is in *thread local storage*. This is different *per thread*. This means, each thread gets its own copy, and writing to the copy in one thread doesn't affect any other threads. Note that Emanuele is also right that you have a race condition in any case. So you likely have 2 problems going on. -Steve yes it is declared as ```d bool zeus; ``` it seems change it to working is working ```d __gshared bool zeus; ``` but as I'm new in to D, i will like to hear thoughts even if it works for me
Re: Verbosity in D
On Monday, 8 August 2022 at 00:11:33 UTC, pascal111 wrote: I don't have specific code but it was a general notice. Take Python as in example, the same program in Python doesn't cost much code as D code, and of course by putting in accounts that that I assume that there are some special tasks D can do, while Python can't do. Yeah I don't think this is true. The only clear difference between D and Python is the vast amount of libraries that Python has and that D is a static-typed language, Python is not (by default) You generally don't write much more code. Loops, ranges etc. are all just as pleasant to work with in D as they are in Python. I'd argue it's even easier to work with classes in D than in Python, and even easier to work with metadata in D than any other language. Python has an unnecessary amount of verbosity when it comes to OOP (because it really isn't an OOP language.) I think D only looks verbose to people who don't really understand its metaprogramming capabilities, templates and/or are new to the language and perhaps come from dynamic typed languages. But I don't think D is in particular more verbose than Python, you can write very similar expressions and some code are almost 1:1 in Python and D when you only consider syntax.
Re: How do I initialize a templated constructor?
On Monday, 8 August 2022 at 05:38:31 UTC, rempas wrote:
In the following struct (as an example, not real code):
```
struct TestArray(ulong element_n) {
int[element_n] elements;
this(string type)(ulong number) {
pragma(msg, "The type is: " ~ typeof(type).stringof);
}
}
```
I want to create it and be able to successfully initialize the
template parameters
of the constructor but until now, I wasn't able to find a way
to successfully do
that. Is there a way you guys know? I have tried the following:
```
void main() {
// Doesn't work
auto val = TestArray!(10, "int")(60);
// Doesn't work either
auto val = TestArray!(10).TestArray!("int")(60);
// Neither this works
auto val = TestArray!(10).this!("int")(60);
}
```
As with every question I make, the solution must be "betterC"
compatible so I can use it.
Thanks a lot!
```
this(string type)(ulong number) {
```
You cannot do this.
Instead your type should look like this:
First let's change it up a little bit.
```
struct TestArray(ulong element_n, string type) {
int[element_n] elements;
this(ulong number) {
pragma(msg, "The type is: " ~ typeof(type).stringof);
}
}
```
Now the above will still not work because you do `typeof(type)`
which will always yield string because type is as string and also
the typeof() is not needed in this case and will actually yield
an error.
If it must be a string then you can do it like this:
```
struct TestArray(ulong element_n, string type) {
int[element_n] elements;
this(ulong number) {
mixin("alias T = " ~ type ~ ";");
pragma(msg, "The type is: " ~ T.stringof);
}
}
```
However the ideal implementation is probably this:
```
struct TestArray(ulong element_n, T) {
int[element_n] elements;
this(ulong number) {
pragma(msg, "The type is: " ~ T.stringof);
}
}
```
To instantiate it you simply do:
```
TestArray!(10, "int") val = TestArray!(10, "int")(100);
```
Or
```
TestArray!(10, int) val = TestArray!(10, int)(100);
```
I will recommend an alias to make it easier:
```
alias IntTestArray = TestArray!(10, int);
...
IntTestArray val = IntTestArray(100);
```
Re: Hacking C code vs D code
On Thursday, 4 August 2022 at 23:11:36 UTC, pascal111 wrote: One of problems faced me in C programming is hacking data with C code that some hackers do with C code which make me needs more tools to protect my C code, but I don't have good resources in my current time, while I noticed that D code is more secure than C code by mean it will be more useful to do my codes in my current time. My question is, to which extent D code is secure and helping in protect data? One of the reasons that C is considered an "unsafe" language is because of `libc`. And this is due to three reasons (at least in my view): 1. `libc` is a low level library and as every low level library, it allows you to have a lot of control but you must know what you're doing. But even when you do, humans do make mistakes and we forget things 2. `libc` doesn't have the best design so programmers can really mess up and not even know it 3. `libc` is a limited library (at least after the basic needs) so people have to write their own code. Compared to having a standard library who's open-source and anyone can use, a library that has been written by a developer only for the needs of the current program means that it will always reflect the quality of the developer himself/herself. At the other point, the standard library will be developed by a team of very experienced programmers (expect when n00bs like me design programming languages and libraries...). This is important because these people will do less mistakes and even when they do, the community will try to improve things here and there. Proper testing is another thing software written by very experienced people have. While beginners tend to avoid them like plague... The third one is probably the biggest reason. D has its own library that builds on top of `libc` and it's called `phobos` (bonus for its amazing name!). For that reason, D is mostly a safer language than C. Of course, D is as low level as C and you have the ability to use low level features and not use `phobos` but only `libc` (check about [BetterC](https://dlang.org/spec/betterc.html)). You can also, use pointers, allocate memory manually, do system calls (and write inline assembly in general) and do pretty much whatever you can do in C. If you do it, then D will be as unsafe as C. So it really comes down to the language features and the libraries that are used. Hope that solved your mysteries ;)
