Rewritten

[H. S. Teoh]

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