Re: How ptr arithmitic works??? It doesn't make any sense....
On Sunday, 4 December 2022 at 17:27:39 UTC, Nick Treleaven wrote:
On Sunday, 4 December 2022 at 16:33:35 UTC, rempas wrote:
(MemoryBlock.sizeof is 16 on my 64-bit system).
The above adds 16 bytes to ptr.
The above adds 16 * MemoryBlock.sizeof bytes (16 * 16) to ptr,
because ptr is cast first. Should be `+ 1` to be equivalent.
https://dlang.org/spec/expression.html#pointer_arithmetic
"the resulting value is the pointer plus (or minus) the second
operand **multiplied by the size of the type pointed to by the
first operand**."
Thanks! This explains it. And I have tried and I can only use "+"
or "-" with a pointer so it explains it.
char* return_address_wrong() {
MemoryBlock* local_ptr = cast(MemoryBlock*)ptr;
return cast(char*)(local_ptr + MemoryBlock.sizeof); //
Casted the whole expression. BUT GOT THE WRONG VALUE Why???
}
Because you are adding to a pointer that points to a 16-byte
block, rather than a void* which points to a single byte.
char* return_address_right() {
MemoryBlock* local_ptr = cast(MemoryBlock*)ptr;
return cast(char*)local_ptr + MemoryBlock.sizeof; // Now I
first casted the `local_ptr` variable and then added the
number but this time this gave me the right value
}
The casted pointer points to a single byte.
I think I get it! The first part about the arithmetic explains it
all well. I was also able to fix my program. They way I see it,
you return from a function by first casting the first operand and
when you want to get a variable (or pass one to a function), you
cast the whole expression. At least that's how it worked with my
program.
Re: How ptr arithmitic works??? It doesn't make any sense....
On Sunday, 4 December 2022 at 16:40:17 UTC, ag0aep6g wrote: Not quite. Adding 10 to a T* means adding 10 * T.sizeof. Oh! I thought it was addition. Is there a specific reasoning for that if you are aware of?
Re: Confused about something in the D book relating to precision
I have to agree. Nobody really knows these by heart. Once you know what's available, you just come back and pick what you need for that occasion. Ali Thanks for your effort :-) It helped clear things up.
Enum Default Initializer?
Hi All, are these results normal?
The results have nothing to do with extern(c). I just wanted to
see the simplest results.
```d
extern (C) void main()
{
enum SAYI : char { bir = 49, iki }
enum NUMS : SAYI {
one = SAYI.bir,
two = SAYI.iki
}
import core.stdc.stdio;
printf("%c\n", SAYI.bir); // okay, ASCII: 1
printf("%c\n", NUMS.iki); // okay, ASCII: 2
printf("%c\n", NUMS.one.iki); // opps: ASCII: 2
printf("%c\n", NUMS.two.iki); // opps: ASCII: 2
// printf("%c\n", NUMS.three); // okay: ERROR
printf("%c\n", NUMS.iki); // opps: ASCII: 2
printf("%c\n", NUMS.iki.iki); // opps: ASCII: 2
enum Bar : SAYI { one }
printf("[%c]\n", Bar.one);// okay, ASCII: []
assert(Bar.one == '\0');
/* other error; Comparison between different enumeration types
`Foo` and `SAYI`; If this behavior is intended consider using
`std.conv.asOriginalType`
enum Foo : SAYI { one, two }
with (SAYI) enum Zoo : SAYI
{
one = bir, two
}
//*/
with(SAYI)
{
enum Zoo : SAYI
{
one = bir,
two = iki,
three = cast(SAYI)'3'
}
printf("%c\n", Zoo.three); // okay, ASCII: 3
}
}
```
[v2.099.0 Specification on the
subject:](https://docarchives.dlang.io/v2.099.0/spec/enum.html)
7. If there is no AssignExpression and it is not the first
EnumMember, it is given the value of the previous EnumMember+1.
If the value of the previous EnumMember is EnumBaseType.max, it
is an error. If the value of the previous EnumMember+1 is the
same as the value of the previous EnumMember, it is an error.
(This can happen with floating point types.)
8. All EnumMembers are in scope for the AssignExpressions.
```d
enum C
{
A = B, // A = 4
B = D, // B = 4
C = 3, // C = 3
D // D = 4
}
enum E : C
{
E1 = C.D,
E2 // error, C.D is C.max
}
```
SDB@79
Re: Confused about something in the D book relating to precision
On 12/4/22 18:57, thebluepandabear wrote: > I am not understanding why Ali said there is a decimal mark if precision > is nonzero? > > How can a number have zero precision? That "precision" is referring to how many digits are printed after the decimal mark in the formatted output. > "the required digits after the decimal mark, the number of which is > determined > by precision (default precision is 6)" So, if we print with %e, we get 6 digits: enum f = 1.23456789; writefln!"%e"(f); Prints 1.234568e+00 There are 6 digits after the decimal point. Now 3 digits of precision: writefln!"%.3e"(f); Prints 1.235e+00 Now 0 precision, where the decimal point will disappear: writefln!"%.0e"(f); Prints 1e+00 > Well double has a precision of 15 Different meanings for the same word... > I feel like this section was explained poorly and it's confusing. I have to agree. Nobody really knows these by heart. Once you know what's available, you just come back and pick what you need for that occasion. Ali
Confused about something in the D book relating to precision
Hello guys,
(Noob question.)
I would appreciate some help.
I am reading Ali's book on D language, and I am up to page 127 --
talking about format specifiers.
He says the following about the '%e' (exponent) specifier:
"e: A floating point argument is printed according to the
following rules.
- a single digit before the decimal mark
- a decimal mark if precision is nonzero"
I am not understanding why Ali said there is a decimal mark if
precision is nonzero?
How can a number have zero precision? I thought all numbers have
a precision of greater than 0. I am confused what this means :/
Then he says:
"the required digits after the decimal mark, the number of which
is determined
by precision (default precision is 6)"
Well double has a precision of 15, and when I print the following
there aren't 15 digits after the decimal mark:
```D
double value = 123.456789;
writeln("precision: ", double.dig);
writefln("with e: %e", value);
```
Output:
```
precision: 15
with e: 1.234568e+02
```
I feel like this section was explained poorly and it's confusing.
Help would be appreciated.
Re: raylib-d Gamepad Detection Fails
On Friday, 2 December 2022 at 01:03:47 UTC, Steven Schveighoffer wrote: It's important to remember that raylib-d doesn't do any special things with the raylib functions -- they are just straight calls into the library. -Steve Indeed, I plugged a different gamepad into the same system running the same code, and it worked. My gamepad must not have been on the list of [gamepad input mappings](https://github.com/gabomdq/SDL_GameControllerDB/blob/master/gamecontrollerdb.txt) used by SDL2 --> GLFW --> Raylib --> raylib-d.
Re: Idiomatic D using GC as a library writer
On 12/4/22 15:25, Adam D Ruppe wrote: > which would trigger the write barrier. The thread isn't > allowed to complete this operation until the GC is done. According to my limited understanding of write barriers, the thread moving to 800 could continue because order of memory operations may have been satisfied. What I don't see is, what would the GC thread be waiting for about the write to 800? Would the GC be leaving behind writes to every page it scans, which have barriers around so that the other thread can't continue? But then the GC's write would finish and the other thread's write would finish. Ok, here is the question: Is there a very long standing partial write that the GC can perform like: "I write to 0x42, but I will finish it 2 seconds later. So, all other writes should wait?" > The GC finishes its work and releases the barriers. So, it really is explicit acquisition and releasing of these barriers... I think this is provided by the CPU, not the OS. How many explicit write barriers are there? Ali
Re: Idiomatic D using GC as a library writer
On Sunday, 4 December 2022 at 22:46:52 UTC, Ali Çehreli wrote: That's way beyond my pay grade. Explain please. :) The reason that the GC stops threads right now is to ensure that something doesn't change in the middle of its analysis. Consider for example, the GC scans address 0 - 1000 and finds nothing. Then a running thread moves a reference from memory address 2200 down to address 800 while the GC is scanning 1000-2000. Then the GC scans 2000-3000, where the object used to be, but it isn't there anymore... and the GC has no clue it needs to scan address 800 again. It, never having seen the object, thinks the object is just dead and frees it. Then the thread tries to use the object, leading to a crash. The current implementation prevents this by stopping all threads. If nothing is running, nothing can move objects around while the GC is trying to find them. But, actually stopping everything requires 1) the GC knows which threads are there and has a way to stop them and 2) is overkill! All it really needs to do is prevent certain operations that might change the GC's analysis while it is running, like what happened in the example. It isn't important to stop numeric work, that won't change the GC. It isn't important to stop pointer reads (well not in D's gc anyway, there's some that do need to stop this) so it doesn't need to stop them either. Since what the GC cares about are pointer locations, it is possible to hook that specifically, which we call write barriers; they either block pointer writes or at least notify the GC about them. (And btw not all pointer writes need to be blocked either, just ones that would point to a different memory block. So things like slice iterations can also be allowed to continue. More on my blog http://dpldocs.info/this-week-in-d/Blog.Posted_2022_10_31.html#thoughts-on-pointer-barriers ) So what happens then: GC scans address 0 - 1000 and finds nothing. Then a running thread moves a reference from memory address 2200 down to address 800... which would trigger the write barrier. The thread isn't allowed to complete this operation until the GC is done. Notice that the GC didn't have to know about this thread ahead of time, since the running thread is responsible for communicating its intentions to the GC as it happens. (Essentially, the GC holds a mutex and all pointer writes in generated D code are synchronized on it, but there's various implementations.) Then the GC scans 2000-3000, and the object is still there since the write is paused! It doesn't free it. The GC finishes its work and releases the barriers. The thread now resumes and finishes the move, with the object still alive and well. No crash. This would be a concurrent GC, not stopping threads that are doing self-contained work, but it would also be more compatible with external threads, since no matter what the thread, it'd use that gc mutex barrier.
Re: Idiomatic D using GC as a library writer
ALl it means is certain memory patterns (such as writes), will tell the GC about it. Its required for pretty much all advanced GC designs, as a result we are pretty much maxing out what we can do. Worth reading: https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795
Re: Idiomatic D using GC as a library writer
On 12/4/22 12:17, Adam D Ruppe wrote: On Sunday, 4 December 2022 at 17:53:00 UTC, Adam D Ruppe wrote: Interesting... you know, maybe D's GC should formally expose a mutex that you can synchronize on for when it is running. .. or compile in write barriers. then it doesn't matter if the thread is unregistered, the write barrier will protect it as-needed! That's way beyond my pay grade. Explain please. :) Ali
Re: Idiomatic D using GC as a library writer
On Sunday, 4 December 2022 at 21:55:52 UTC, Siarhei Siamashka wrote: Do you mean the top of the https://code.dlang.org/?sort=score=library list? Well, I was referring to the five that appear on the homepage, which shows silly instead of emsi containers. How do you know that they embrace GC? I looked at the projects. Except for that arsd-official thing, that's a big mystery to me, the code is completely unreadable. But vibe and dub use it pretty broadly. Unit-threaded and silly are test runners, which isn't even really a library (I find it weird that they are consistently at the top of the list), so much of them don't need the GC anyway, but you can still see that they use it without worry when they do want it like when building the test list with ~=. emsi-containers is built on the allocators thing so it works with or without gc (it works better without though as you learn if you try to use them.) Is it possible to filter packages in this list by @nogc or @safe compatibility? No. I do have an idea for it, searching for @nogc attributes or attached @nogc unittests, but I haven't gotten around to trying it.
Re: Idiomatic D using GC as a library writer
On Sunday, 4 December 2022 at 12:37:08 UTC, Adam D Ruppe wrote: All of the top 5 most popular libraries on code.dlang.org embrace the GC. Do you mean the top of the https://code.dlang.org/?sort=score=library list? How do you know that they embrace GC? Is it possible to filter packages in this list by @nogc or @safe compatibility?
Re: Idiomatic D using GC as a library writer
On Sunday, 4 December 2022 at 17:53:00 UTC, Adam D Ruppe wrote: Interesting... you know, maybe D's GC should formally expose a mutex that you can synchronize on for when it is running. .. or compile in write barriers. then it doesn't matter if the thread is unregistered, the write barrier will protect it as-needed!
Re: How ptr arithmitic works??? It doesn't make any sense....
On Sun, Dec 04, 2022 at 04:33:35PM +, rempas via Digitalmars-d-learn wrote: > First a little bit of theory. A pointer just points to a memory > address which is a number. So when I add "10" to this pointer, it will > point ten bytes after the place it was pointing to, right? This is true only if you're talking about pointers in the sense of pointers in assembly language. Languages like C and D add another layer of abstraction over this. > Another thing with pointers is that it doesn't have "types". This is where you went wrong. In assembly language, yes, a pointer value is just a number, and there's no type associated with it. However, experience has shown that manipulating pointers at this raw, untyped level is extremely error-prone. Therefore, in languages like C or D, a pointer *does* have a type. It's a way of preventing the programmer from making silly mistakes, by associating a type (at compile-time only, of course) to the pointer value. It's a way of keeping track that address 1234 points to a short, and not to a float, for example. At the assembly level, of course, this type information is erased, and the pointers are just integer addresses. However, at compile-type, this type exists to prevent, or at least warn, the programmer from treating the value at the pointed-to address as the wrong type. This is not only because of data sizes, but the interpretation of data. A 32-bit value interpreted as an int is completely different from a 32-bit value interpreted as a float, for example. You wouldn't want to perform integer arithmetic on something that's supposed to be a float; the result would be garbage. In addition, although in theory memory is byte-addressable, many architectures impose alignment restrictions on values larger than a byte. For example, the CPU may require that 32-bit values (ints or floats) must be aligned to an address that's a multiple of 4 bytes. If you add 1 to an int* address and try to access the result, it may cause performance issues (the CPU may have to load 2 32-bit values and reassemble parts of them to form the misaligned 32-bit value) or a fault (the CPU may refuse to load a non-aligned address), which could be a silent failure or may cause your program to be forcefully terminated. Therefore, typed pointers like short* and int* may not be entirely an artifact that only exists in the compiler; it may not actually be legal to add a non-aligned value to an int*, depending on the hardware you're running on. Because of this, C and D implement pointer arithmetic in terms of the underlying value type. I.e., adding 1 to a char* will add 1 to the underlying address, but adding 1 to an int* will add int.sizeof to the underlying address instead of 1. I.e.: int[2] x; int* p = [0]; // let's say this is address 1234 p++;// p is now 1238, *not* 1235 (int.sizeof == 4) As a consequence, when you cast a raw pointer value to a typed pointer, you are responsible to respect any underlying alignment requirements that the machine may have. Casting a non-aligned address like 1235 to a possibly-aligned pointer like int* may cause problems if you're not careful. Also, the value type of the pointer *does* matter; you will get different results depending on the size of the type and any alignment requirements it may have. Pointer arithmetic involving T* operate in units of T.sizeof, *not* in terms of the raw pointer value. T -- Change is inevitable, except from a vending machine.
Re: Idiomatic D using GC as a library writer
On Sunday, 4 December 2022 at 16:02:28 UTC, Ali Çehreli wrote: D's GC needed to stop the world, which meant it would have to know what threads were running. You can never be sure whether your D library function is being called from a thread you've known or whether the Java runtime (or other user code) just decided to start another thread. Interesting... you know, maybe D's GC should formally expose a mutex that you can synchronize on for when it is running. So you can cooperatively do this in the jni bridge or something. Might be worth considering. I've heard stories about similar things happening with C#.
Re: Idiomatic D using GC as a library writer
On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote: Dear dlang community. I am unsure about what idiomatic D is. Some of the Dconf talks tells people just to use the GC, until you can't afford it. If there are documents that describes what idiomatic D is then I would appreciate it. So my questions are: What are your thoughts about using GC as a library writer? If you wan't to include a library into your project aren't you more inclined to use a library which is gc free? If that is true, then idiomatic D doesn't apply for library writers. Since to get most exposure as a D library writer you kinda need to make it gc free right? Cheers. D gives you the choice But the most important thing is your usecase, what kind of library are you making? Once you answer this question, you can then ask what your memory strategy should be, and then it is based on performance concerns D scale from microcontrollers to servers, drivers, games, desktop apps Your audience will determine what you should provide For a desktop app, a GC is an advantage For a driver or a game, it's not
Re: How ptr arithmitic works??? It doesn't make any sense....
On Sunday, 4 December 2022 at 16:33:35 UTC, rempas wrote:
struct MemoryBlock {
char* ptr;
ulong length;
}
(MemoryBlock.sizeof is 16 on my 64-bit system).
void* ptr = cast(void*)0x7a7;
void* right() {
return cast(MemoryBlock*)(ptr + MemoryBlock.sizeof); // Cast
the whole expression between paranthesis. Got the right value!
}
The above adds 16 bytes to ptr.
void* wrong() {
return cast(MemoryBlock*)ptr + MemoryBlock.sizeof; // First
cast the `ptr` variable and then add the number. Got a wronge
value...
}
The above adds 16 * MemoryBlock.sizeof bytes (16 * 16) to ptr,
because ptr is cast first. Should be `+ 1` to be equivalent.
https://dlang.org/spec/expression.html#pointer_arithmetic
"the resulting value is the pointer plus (or minus) the second
operand **multiplied by the size of the type pointed to by the
first operand**."
char* return_address_wrong() {
MemoryBlock* local_ptr = cast(MemoryBlock*)ptr;
return cast(char*)(local_ptr + MemoryBlock.sizeof); // Casted
the whole expression. BUT GOT THE WRONG VALUE Why???
}
Because you are adding to a pointer that points to a 16-byte
block, rather than a void* which points to a single byte.
char* return_address_right() {
MemoryBlock* local_ptr = cast(MemoryBlock*)ptr;
return cast(char*)local_ptr + MemoryBlock.sizeof; // Now I
first casted the `local_ptr` variable and then added the number
but this time this gave me the right value
}
The casted pointer points to a single byte.
Re: How ptr arithmitic works??? It doesn't make any sense....
On Sunday, 4 December 2022 at 16:33:35 UTC, rempas wrote: First a little bit of theory. A pointer just points to a memory address which is a number. So when I add "10" to this pointer, it will point ten bytes after the place it was pointing to, right? Not quite. Adding 10 to a T* means adding 10 * T.sizeof.
Re: Idiomatic D using GC as a library writer
On Sunday, 4 December 2022 at 15:57:26 UTC, Ali Çehreli wrote: On 12/4/22 05:58, vushu wrote: > I was worried if my library should be GC free May I humbly recommend you question where that thinking comes from? Ali P.S. I used to be certain that the idea of GC was wrong and the creators of runtimes with GC were simpletons. In contrast, people like me, people who could understand C++, were enlightened. Then I learned. I also come from C++ and as you know it, the community over there isn't quite fond of GC. So I just logical think that by excluding the GC you actually widen the range of usage. But if I only want to cater to the d ecosystem then using GC is the recommended way.
How ptr arithmitic works??? It doesn't make any sense....
First a little bit of theory. A pointer just points to a memory
address which is a number. So when I add "10" to this pointer, it
will point ten bytes after the place it was pointing to, right?
Another thing with pointers is that it doesn't have "types". A
pointer always just points to a location so types are created for
the compiler so we can catch bugs when pointing to places and
trying to manipulate the bytes to a size we probably wouldn't
want to. For example: if you have allocated 4 bytes and then you
try to point to it with a type of "short" for example, then you
could only manipulate 2 of these 4 bytes but you probably
wouldn't and you did something wrong so we do have types and the
compiler requires explicit pointer type casting (in contrast to
C) so it can protect you from these bugs.
This type-casting brings some problem however. So, I played
around it and I figured it out than to get the right location you
expect when returning from a function, you need to do the math
and then cast the whole expression (so the result) and return
that. If you only cast the first value (that is of the different
type) an then do that addition (or whatever expression you want),
it will return a wrong address. But WAIT!!! This doesn't work in
a different example. And I'm braking my head to understand why
and I thought about asking if anyone can help and explain to me
why. Btw, all the testing was made with `ldc` in the `BetterC`
"mode". Code:
```d
import core.stdc.stdio;
import core.stdc.stdlib;
struct MemoryBlock {
char* ptr;
ulong length;
}
void* ptr = cast(void*)0x7a7;
void* right() {
return cast(MemoryBlock*)(ptr + MemoryBlock.sizeof); // Cast
the whole expression between paranthesis. Got the right value!
}
void* wrong() {
return cast(MemoryBlock*)ptr + MemoryBlock.sizeof; // First
cast the `ptr` variable and then add the number. Got a wronge
value...
}
char* return_address_wrong() {
MemoryBlock* local_ptr = cast(MemoryBlock*)ptr;
return cast(char*)(local_ptr + MemoryBlock.sizeof); // Casted
the whole expression. BUT GOT THE WRONG VALUE Why???
}
char* return_address_right() {
MemoryBlock* local_ptr = cast(MemoryBlock*)ptr;
return cast(char*)local_ptr + MemoryBlock.sizeof; // Now I
first casted the `local_ptr` variable and then added the number
but this time this gave me the right value
}
extern (C) void main() {
printf("EXPECTED LOCATION: %p\n", ptr + MemoryBlock.sizeof);
printf("RIGHT LOCATION: %p\n", right());
printf("WRONG LOCATION: %p\n", wrong());
printf("RETURNED ADDRESS (wrong): %p\n",
return_address_wrong());
printf("RETURNED ADDRESS (right): %p\n",
return_address_right());
}
```
Re: Idiomatic D using GC as a library writer
On 12/4/22 06:27, Sergey wrote: > if it will be possible to write > library in D and use it from > C/++/Python/R/JVM(JNI)/Erlang(NIF)/nameYourChoice smoothly it will be a > win. Years ago we tried to call D from Java. I realized that it was very tricky to introduce the calling thread to D's GC. D's GC needed to stop the world, which meant it would have to know what threads were running. You can never be sure whether your D library function is being called from a thread you've known or whether the Java runtime (or other user code) just decided to start another thread. We failed and D was replaced with C++. Ali
Re: Idiomatic D using GC as a library writer
On 12/4/22 05:58, vushu wrote: > I was worried if my library should be GC free May I humbly recommend you question where that thinking comes from? Ali P.S. I used to be certain that the idea of GC was wrong and the creators of runtimes with GC were simpletons. In contrast, people like me, people who could understand C++, were enlightened. Then I learned.
Re: Idiomatic D using GC as a library writer
On Sunday, 4 December 2022 at 12:37:08 UTC, Adam D Ruppe wrote: All of the top 5 most popular libraries on code.dlang.org embrace the GC. Interesting. It seems that most of the community suppose that “library” should be used from D :-) But in my opinion - “foreign library experience” is much more important. The usage of D is not that wide… but if it will be possible to write library in D and use it from C/++/Python/R/JVM(JNI)/Erlang(NIF)/nameYourChoice smoothly it will be a win. Run fast (it could be Rust, Zig) extension/library from more high level/less safe/slower dynamic languages. And not only run but also write fast(here is D and Nim could be chosen). Many languages do not have GC inside.. and others have their own. And if your library is going to manipulate objects from other languages with different memory management approach - it could be tricky to do that with GC. You need to make that both GC become friends
Re: Idiomatic D using GC as a library writer
On Sunday, 4 December 2022 at 13:03:07 UTC, Hipreme wrote: On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote: Dear dlang community. I am unsure about what idiomatic D is. Some of the Dconf talks tells people just to use the GC, until you can't afford it. If there are documents that describes what idiomatic D is then I would appreciate it. So my questions are: What are your thoughts about using GC as a library writer? If you wan't to include a library into your project aren't you more inclined to use a library which is gc free? If that is true, then idiomatic D doesn't apply for library writers. Since to get most exposure as a D library writer you kinda need to make it gc free right? Cheers. "Until you can't afford", is something really extreme. There is a bunch of ways to deal with GC memory, what I would say that can't afford is when you're constantly allocating memory and because of that, making the program more prone to execute a collection. I haven't had any problem with the GC yet. If you think your program is slow, pass it on a profiler and you'll know the real problem. Don't think too much about that or else you're gonna lose a heck lot of productivity and end up creating needlessly unsafe code. True that makes sense, I also tried using nogc in code, but it complicates things. The code is much easier to write when I don't work against the GC. If you're still gonna be hard headed against the GC, at least use slices when allocating from malloc, makes your code safe, readable and less variables to think about. Don't use raw pointers unnecessarily, and right now, the only reason pointers have been used in my code base was not for allocated memory, but for being able to modify a variable from another place when you need to store a variable reference. If you're only gonna modify it inside the function, use `ref` instead. Thanks for the tips :)
Re: Idiomatic D using GC as a library writer
On Sunday, 4 December 2022 at 12:37:08 UTC, Adam D Ruppe wrote: On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote: What are your thoughts about using GC as a library writer? Do it. It is lots of gain for very little loss. If you wan't to include a library into your project aren't you more inclined to use a library which is gc free? No, GC free means the library is necessarily more complicated to use and will likely result in a buggier program. Since to get most exposure as a D library writer you kinda need to make it gc free right? All of the top 5 most popular libraries on code.dlang.org embrace the GC. That's great to hear thanks! I was worried if my library should be GC free or not and how it will affect the adoption of it. Seems like there is no concern.
Re: Idiomatic D using GC as a library writer
On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote: Dear dlang community. I am unsure about what idiomatic D is. Idiomatic D code produces the correct result, it's readable, and it's easy for others to use. Some of the Dconf talks tells people just to use the GC, until you can't afford it. "can't afford it" in what sense? Pauses for garbage collection are one thing, overall runtime performance is something completely different. Avoiding the GC won't magically make your program faster. If there are documents that describes what idiomatic D is then I would appreciate it. So my questions are: What are your thoughts about using GC as a library writer? Depends on the library, but most of the time it's best to use it. D's main problem at this point is a lack of high-quality, easy-to-use libraries - not libraries that use the GC. If you wan't to include a library into your project aren't you more inclined to use a library which is gc free? The moment I have to think about memory management, I start looking for a different library. I suppose there's nothing wrong if a library avoids the GC internally (since that won't affect me). The GC has never caused problems for me. It has made my life easier.
Re: Idiomatic D using GC as a library writer
On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote: Dear dlang community. I am unsure about what idiomatic D is. Some of the Dconf talks tells people just to use the GC, until you can't afford it. If there are documents that describes what idiomatic D is then I would appreciate it. So my questions are: What are your thoughts about using GC as a library writer? If you wan't to include a library into your project aren't you more inclined to use a library which is gc free? If that is true, then idiomatic D doesn't apply for library writers. Since to get most exposure as a D library writer you kinda need to make it gc free right? Cheers. "Until you can't afford", is something really extreme. There is a bunch of ways to deal with GC memory, what I would say that can't afford is when you're constantly allocating memory and because of that, making the program more prone to execute a collection. I haven't had any problem with the GC yet. If you think your program is slow, pass it on a profiler and you'll know the real problem. Don't think too much about that or else you're gonna lose a heck lot of productivity and end up creating needlessly unsafe code. If you're still gonna be hard headed against the GC, at least use slices when allocating from malloc, makes your code safe, readable and less variables to think about. Don't use raw pointers unnecessarily, and right now, the only reason pointers have been used in my code base was not for allocated memory, but for being able to modify a variable from another place when you need to store a variable reference. If you're only gonna modify it inside the function, use `ref` instead.
Re: Idiomatic D using GC as a library writer
On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote: What are your thoughts about using GC as a library writer? Do it. It is lots of gain for very little loss. If you wan't to include a library into your project aren't you more inclined to use a library which is gc free? No, GC free means the library is necessarily more complicated to use and will likely result in a buggier program. Since to get most exposure as a D library writer you kinda need to make it gc free right? All of the top 5 most popular libraries on code.dlang.org embrace the GC.
Idiomatic D using GC as a library writer
Dear dlang community. I am unsure about what idiomatic D is. Some of the Dconf talks tells people just to use the GC, until you can't afford it. If there are documents that describes what idiomatic D is then I would appreciate it. So my questions are: What are your thoughts about using GC as a library writer? If you wan't to include a library into your project aren't you more inclined to use a library which is gc free? If that is true, then idiomatic D doesn't apply for library writers. Since to get most exposure as a D library writer you kinda need to make it gc free right? Cheers.
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Wednesday, 30 November 2022 at 03:04:47 UTC, Basile B. wrote:
I have implemented that in
[styx](https://gitlab.com/styx-lang/styx).
1. You have the type for dynamic arrays, called TypeRcArray,
syntax is `Type[+]`
2. You have the type for slices (what you describe as a
window), syntax is `Type[]`
but it is mostly obtained using expressions, e.g `mySlice =
myRcArray[lo .. hi]` or
`myStaticArray[lo .. hi]` or `myPointer[lo .. hi]`.
This sounded like a good idea but it [has appeared very
quickly](https://styx-lang.gitlab.io/styx/type.html#noteonlifetime) that slices are not so useful...
Recently DIP1044 was published about enum and although we can use
`with()` instead we waste time unnecessarily...
I've never tried it, but the feature shown below is not available
in D! Why not such good things?
```d
enum Foo
{
a0 = 1,
a1
}
enum Bar: Foo
{
a2 // 3
}
```
Thanks...
SDB@79
