Trust me I love my dark themes, but I’ve been losing power a lot lately (LA fires and high winds) and running on battery backups. When this happens I switch to a portal monitor at zero brightness and put every in low power mode. So I had to switch to light themes because the monitor brightness was too low to see dark themes correctly but it’s fine for light themes. Kind of just left it… finding that 0% brightness and light themes is not so bad 🧐.
Does Zig not have automatic local destructor call at the end of each scope? If it does then why should you need to manually call the deinit/destructor for the GPA object, if it would do so automatically at the end of the scope anyway?
That would be Fleet, the author of the Zig plugin has been making updates to the Zig integration, but I have no idea what changes / fixes are being done. Fleet plugins have no links shown so kind of in the dark on what improvements are being done. One part is the ZLS type definitions do not show current with the Fleet / Zig integration.
if I wanted to have to manage memory myself, I'd use C. At least with C, you have a fairly straightforward mapping from code to generated machine instructions. With zig you get quite literally the worst of both worlds.
I do think defer and errdefer are nice coming from C, you don't need additional logic or using goto/JMP operations. So a specific error doesn't need to know about the rest of the system at bailout.I like the ideas around memory, giving you a little more guardrails than C, but using @ptrCast, @constCast, @alignCast, then when I first learned pointer arithmetic it was interoping with C and with c-style pointers you cant just "ptr++", you had to do something like "@ptrCast(*i32, @ptrFromInt(@intFromPtr(ptr) + @sizeOf(i32)))"... Zig does have pointer arithmetic and it would be "ptr += 1", it's just you need to use Zig's pointers.
@@joseph-montanez But what is a pointer? Nothing other than an address. And this address can never be negative, which is why it is an unsigned integer. Unfortunately, for decades in C, no one thought about this and simply wrote "int", which the compiler then converted under the hood. This of course backfires, but that is why Zig does not have its own pointer system; it just has to be declared accordingly. Incidentally, this is something that often leads to errors such as buffer overflow in C, because people do not realize that the compiler does its best to correct things. This also makes it particularly difficult to find errors, because everything looks fine in the source code. And the fact that you give an example where you also convert "i32" shows me that you also don't understand that this can't be the case and that a signed integer must therefore be converted to an unsigned integer. But this can be avoided (even in C) and is not a Zig problem but a general one.
I appreciate the comments you’re leaving all over the place, yes the last cast is not needed since ptr from int already casted it as pointer, but that depends on if the receiving end it goes back it has the type information of *i32, so the cast may or may not be needed, since it’s comp time based, the type can be interfered. If I reassigned this to the variable that used the typed pointer then again not needed. And Zig absolutely has a pointer system it’s just not “maybe it’s a single item or many item”, like pointers are in C which is why is also has c style pointers too *c.
I've called the police to do a welfare check for having your IDE in light mode.
Trust me I love my dark themes, but I’ve been losing power a lot lately (LA fires and high winds) and running on battery backups. When this happens I switch to a portal monitor at zero brightness and put every in low power mode. So I had to switch to light themes because the monitor brightness was too low to see dark themes correctly but it’s fine for light themes. Kind of just left it… finding that 0% brightness and light themes is not so bad 🧐.
Does Zig not have automatic local destructor call at the end of each scope? If it does then why should you need to manually call the deinit/destructor for the GPA object, if it would do so automatically at the end of the scope anyway?
There is NOTHING automatic or implicit in Zig.
what editor are you using?
That would be Fleet, the author of the Zig plugin has been making updates to the Zig integration, but I have no idea what changes / fixes are being done. Fleet plugins have no links shown so kind of in the dark on what improvements are being done. One part is the ZLS type definitions do not show current with the Fleet / Zig integration.
if I wanted to have to manage memory myself, I'd use C. At least with C, you have a fairly straightforward mapping from code to generated machine instructions. With zig you get quite literally the worst of both worlds.
I do think defer and errdefer are nice coming from C, you don't need additional logic or using goto/JMP operations. So a specific error doesn't need to know about the rest of the system at bailout.I like the ideas around memory, giving you a little more guardrails than C, but using @ptrCast, @constCast, @alignCast, then when I first learned pointer arithmetic it was interoping with C and with c-style pointers you cant just "ptr++", you had to do something like "@ptrCast(*i32, @ptrFromInt(@intFromPtr(ptr) + @sizeOf(i32)))"... Zig does have pointer arithmetic and it would be "ptr += 1", it's just you need to use Zig's pointers.
@@joseph-montanez But what is a pointer? Nothing other than an address. And this address can never be negative, which is why it is an unsigned integer. Unfortunately, for decades in C, no one thought about this and simply wrote "int", which the compiler then converted under the hood. This of course backfires, but that is why Zig does not have its own pointer system; it just has to be declared accordingly. Incidentally, this is something that often leads to errors such as buffer overflow in C, because people do not realize that the compiler does its best to correct things. This also makes it particularly difficult to find errors, because everything looks fine in the source code. And the fact that you give an example where you also convert "i32" shows me that you also don't understand that this can't be the case and that a signed integer must therefore be converted to an unsigned integer. But this can be avoided (even in C) and is not a Zig problem but a general one.
I appreciate the comments you’re leaving all over the place, yes the last cast is not needed since ptr from int already casted it as pointer, but that depends on if the receiving end it goes back it has the type information of *i32, so the cast may or may not be needed, since it’s comp time based, the type can be interfered. If I reassigned this to the variable that used the typed pointer then again not needed. And Zig absolutely has a pointer system it’s just not “maybe it’s a single item or many item”, like pointers are in C which is why is also has c style pointers too *c.