3 ms·
> I really like the Zig approach of improving the tooling for manual memory management rather than replacing manual memory management. The new test allocator c
by dnautics 6y ago
> I really like the Zig approach of improving the tooling for manual memory management rather than replacing manual memory management.
The new test allocator checks your code for memory leaks, use after free, and double free in a highly ergonomic fashion. I think is fantastic that zig encourages writing tests, and I think if you get full test coverage in your zig code with the test allocator, you will probably solve 99% of your memory errors.
I know this is possible in C++ (see alexandrescu's allocators talk from CppCon 2017?) But I would be surprised if anyone does it.
- fanf2 6y agoAddress Sanitizer and valgrind are widely-used standard tools for finding allocation bugs
- setpatchaddress 6y agoThey are very effective, but relatively difficult to use.
- pjmlp 6y agoOn VS 2019, literally a checkbox away and rebuild.
- chubot 6y agoThey're built into both GCC and Clang and very easy to use IMO. The only hard part is figuring out how to pass -fsanitize=address into your compiler via your complex build system! And building with symbols. That is inherent to the C/C++ toolchain and not a problem that sanitizers can address.
- samatman 6y agoSure but a language where "the only hard part" isn't a factor surely has a leg up on one where it is. A lot of the advantage which Zig has over C is exactly in not having to support a towering edifice of tools and hacks which is older than I am. This is true to a significant degree of Rust and C++ as well.
- pron 6y agoJust to be clear, Zig isn't the same as C/C++ with sanitizers. Zig has slices and it doesn't have pointer arithmetic and pervasive casts. For example, if you preallocate a buffer and then reuse it, or chunk it into multiple pieces, sanitizers won't find an issue, but Zig will (thanks to slices). C simply has no way to express, "I want to pass a pointer into an array to this subroutine but it is only allowed to use n elements," when n is dynamic.
- pjmlp 6y agoC++ has it though, https://github.com/microsoft/GSL/blob/master/include/gsl/span https://github.com/microsoft/GSL/blob/master/include/gsl/spa...
- pron 6y agoRight, but in this case it's not a matter of what you have, but what you don't. Zig has slices as the only form of moving pointers around, and it doesn't have any pointer arithmetic. I.e. every time some data is traversed, the language ensures the size is known either at compile time or runtime.
- pjmlp 6y agoFor the time being, https://github.com/ziglang/zig/issues/2018 https://github.com/ziglang/zig/issues/2018
- pron 6y agoThis isn't exactly pointer arithmetic as in C (or in unsafe Zig, as with @intToPtr, or using the "unknown size" pointer type, [*]). This is talking about preserving size information, and only when the arithmetic is compile-time-known; so it's more "array arithmetic".
- pjmlp 6y agoFair enough.
- dnautics 6y agoI guess my feeling is that the tool chain for C/C++ is now C, C++, plus the preprocessor stuff (its own language), linker, make, (plus probably automake, cmake), gdb, valgrind, asan, etc etc etc, just to get "best practices/safe coding" right. With zig, not 100% comparable (like not sure about gdb, but zig stacktraces and error traces are fantastic) it's all done in one language. Such a lowering of mental overhead and entry barrier! The only thing you have to learn is that at comptime you get access to some magic (like the ++ operator)