On Sun, Jun 07, 2026 at 02:32:45PM +0000, Andy Valencia via Digitalmars-d-learn wrote: [...] > As an old C guy, I have deep and long experience with pointers. In D, > I almost never use them because of that knowledge! I try very hard to > use class objects, ref, and out parameters instead. I'm pretty I've > yet to do pointer arithmetic.
I'm also a C guy, I debug and write C code for a living. I also have deep and long experience with pointers, pointer bugs, and memory corruption issues. I've actually done some pointer arithmetic in D, but it's pretty rare. Most of the time you don't have to care about raw pointers in D. Just use slices and classes, otherwise pass by (const) ref if you have a *really* big struct. (But D lends itself to better code design, so you rarely end up with the code smell that your struct is too big to pass by value. Most of the time you pass by ref only because you actually need to mutate the caller's copy of the value.) > My code doesn't run as fast as it could--but I don't care. Premature optimization is an inherent part of C culture, unfortunately. The language just forces you to think in terms that unconsciously drives you want to optimize the last cycles out of your code, even when it's completely irrelevant. It took me several embarrassing experiences of thinking I knew best how to optimize something, only for the profiler to show me that I'm TOTALLY off, to cure me of this syndrome. Nowadays I still keep an eye on performance, but for the most part, I don't bother optimizing unless it's deep inside an inner loop that's actually hot. Most of the time the difference doesn't really matter THAT much. It's only when you're dealing with things like a hard deadline (e.g. 60fps, you only have 16.7ms to do all of your processing per iteration), or a compute-intensive task where performance can mean the difference between getting the answer 2 hours later vs. 2 weeks later, then I'll profile and look into optimizing my inner loops. Even then, from my experience, most D code does not require you to go to raw pointer level to maximize performance. I've seen up to 2x to 3x performance boost just by simple 1-2 line tweaks: eliminating unnecessary allocations like reusing a buffer provided by the caller instead of allocating inside a function, locating Schlemiel's hiding places in the code and replacing them with non-quadratic algorithms, etc.. In fact, I've yet to encounter a case in D where using raw pointers was necessary for performance reasons. I did wrote raw pointer code a few times, just for comparison's sake, but have yet to find a case where it provided a significant advantage. > Life is too short to be chasing SEGV's and memory corruption. Arrays, > indices, and slices for me. [...] Yeah!! After 3 decades of dealing with constant pointer bugs, off-by-1 errors, buffer overflows, dangling pointers, double-frees, enough is enough. I still do it for my day job, because, well, it's C. But outside of that? No thank you, give me GC any day. The haters will hate, but GC is a true godsend. Not only it eliminates an entire class of memory bugs (with no effort!), it also frees my brain from constant obsession about memory management issues and actually make progress in my problem domain. My APIs become cleaner, free of hairy frilly memory management paraphrenalia that sprout everywhere in C APIs, and my code becomes much cleaner and easier to follow. Less bugs, faster development times. I met D many years ago and am still in love. ;-) T -- Only boring people get bored. -- JM
