On 9/22/21 11:47 AM, eugene wrote:

In terms of any kind of memory management, whether it be ARC, manual, GC, or anything else, there will always be pitfalls. It's just that you have to get used to the pitfalls and how to avoid them.

I could see a person used to GC complaining that C requires you to free every pointer exactly once. I mean, how can that be acceptable? ;)

And for the most part, you do not. It's just when you travel outside the language, you must obey certain constraints. Those constraints are laid out, and unfortunately not exactly correct (we need to amend the spec/library for this), but given correct constraints, the rules are not super-difficult to follow.

You are welcome!

I'm right there with you (been writing code for about 25 years, maybe 26, depending on when I switched majors to CS in college).

But realize that C has it's share of "shocks" as well, you are just more used to them (or maybe you have been lucky so far?)

Your experience is not typical though (clearly, as many of us long-time D users had no idea why it was happening). But for sure if this turns you off, I can understand how it can be too frustrating to learn the new rules. I personally would probably never write C code again if I can help it, despite having decades of experience in C/C++. I did recently have to port a C plugin library from PHP 5 to PHP 7, and it wasn't pleasant.

I find it interesting how you blame yourself for C's idiosyncrasies, but not for D's ;) I would say C has far more pitfalls than D. Check out the undefined behaviors for C.

-Steve

On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven Schveighoffer wrote:

Oh, yeah - I have special trait of bumping against
various low probability things :)

Show me these rules!
Always use an object at the end of a function?
Make a second reference to an object somewhere on the heap?
The 'problem' here is that there is no clear rule.
Any reasonable 'hack' will do.

On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven Schveighoffer wrote:

100% agree.

C (at compiler level) does not require this.
You can do it free()ly. ,)
With a subsequent... yes, 'shock' after you see 'double free or corruption' message.

Tell that imaginary person this: if (p) {free(p); p = NULL}, that's all.

On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven Schveighoffer wrote:

Any language is just an instrument,
most of the 'shocks' come not from
languages themselves, but from the
'enviromment', so to say.

An example that came to mind...
Did you know that sending data via write()/send()
to a socket, that is in CLOSE_WAIT state,
results in sending data to nowhere and
write() indicates no error?

By the way, GC is a sort of 'environment' (not the language itself),
it acts behind the scenes (unless you are using it directly)

Once I've been very 'lucky' with unaligned pointer dereference on ARM...

On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven Schveighoffer wrote:

Me? Blaming myself for C 'idiosyncrasies'? :) Where?

I've been learning D for about 3 months only.

No doubt - and I've never said C is "better" than D.
I was going to try betterC subset
(say, try to implement dynamic arrays),
but did not have much free time yet.

Nothing interesting...
Most of UB in C are just programmer's sloppiness.
C requires a programmer to be careful/punctual,
much more careful, than ... a python, for ex.

On 9/23/21 3:27 AM, eugene wrote:

They are here: https://dlang.org/spec/interfaceToC.html#storage_allocation

With the caveat, of course, that the recommendation to "leave a pointer on the stack" is not as easy to follow as one might think with the optimizer fighting against that. We need to add a better way to do that (similar to C# KeepAlive). I made an attempt, but I think it's not guaranteed to work, I've already found ways to prove it fails.

-Steve

On 9/23/21 8:10 AM, eugene wrote:

"When my C program crashes, I'm 100% sure I made something stupid"

One might argue that C's approach to memory management is a contributor to people writing code that fails.

Your assertion that programming in GC languages may be harder than manual memory languages is what I was addressing.

My point is that C has a lot more memory management pitfalls than D, not addressing any "better than" arguments.

UB in C leaves traps for the programmer, similar to this trap you have found in the GC. Where code doesn't do what you are expecting it to do.

-Steve

On Thursday, 23 September 2021 at 12:53:14 UTC, Steven Schveighoffer wrote:

Yes, as you explained me, the root of the
problem in my examples were dead store elimination.

Do you mean some function attribute?..

On Thursday, 23 September 2021 at 13:05:07 UTC, Steven Schveighoffer wrote:

There is a difference, though.
As I've already said,
GC is a sort of 'environment',
the code of GC exits by it's own.

In C, no such code is 'inserted' by compiler
into code written by a programmer.

So, in C it is MY (potentially wrong) code.
In D, it is NOT MY code, it is GC.
From this point of view debugging
may be harder (especially by beginners, like me)

On Thursday, 23 September 2021 at 12:53:14 UTC, Steven Schveighoffer wrote:

For the moment I am personally quite happy
with any reasonable workaround
(use an object in the end of the main function,
put the reference to an object into some AA, whatever),
because now I firmly understand,
that the source of strange GC behavior
is DSE optimization (in this case).