The abhorrent 🔥 rites of C

[sockpuppet7]

@NeighborhoodButcher said in The abhorrent 🔥 rites of C:

We, sane programmers

[sockpuppet7]

@asdf said in The abhorrent 🔥 rites of C:

The whole reason this method exists is that, apparently, the pointer needs to be passed through an API that expects a URI.

that's enough internet for me today

[remi]

@dkf Necroing an 8 years old thread to quote one of your own posts (and deep in the middle of the original thread), and to mention "Especially" a "hidden pitfall" of C++.

Come on, we all know you're dying to tell us a good story about bool in C++. Stop teasing us!

[dkf]

@remi An example... if you have a function that takes a std::string formal argument, you can use it with a string constant actual argument, and things are good and convenient. Unless, that is, if you are overloading with a function that takes a bool because the actual type(s) of string constants would much rather convert to that than std::string...

[LaoC]

@dkf said in The abhorrent 🔥 rites of C:

@remi An example... if you have a function that takes a std::string formal argument, you can use it with a string constant actual argument, and things are good and convenient. Unless, that is, if you are overloading with a function that takes a bool because the actual type(s) of string constants would much rather convert to that than std::string...

There's a case to be made fo our beloved ternary booleans

[dkf]

@dkf

[remi]

: Why?? But why?!?
: Because the C++ Standard, paragraph 42.6.7, says so, that's why.

---

Filed under: whose law is it that every thread will end up discussing the C++ Standard?

[topspin]

@dkf so there’s this long-ass thread about how C is basically horrible. A bunch of guys come in to argue it’s not just “good” for systems programming, it’s the best. And definitely better than C++, while showing a complete lack of understanding of how that actually works, or how to do things in a non-C way even in C++98, let alone anything current in 2016. (“What do you mean ‘owning pointer’?” And an astounding lack of understanding about the subtopic that Foo* might need a special deallocation function instead of free.)
Then there’s the usual madman who declares nobody can get memory management correct, not even in GC languages, but still argues against automatic resource cleanup in favor of writing it manually every single time, because of some completely made up “overhead” that is literally non-existent. No compiler can optimize a zero-overhead abstraction, even after it’s been proven to him with links to compiler outputs that literally every compiler does. (Nevermind that the overhead would be completely dwarfed by anything his preferred alternative compiles too, even if this overhead existed in the real world.)

And then you necro the thread with a complaint that is literally a backwards compatibility with C issue? Oh the irony.
Yes, C has weak type safety. Yes, C strings suck and always have. You get the exact same implicit cast in C because literals decay to pointer. I think it’s summed up well like this:

@ronin said in The abhorrent 🔥 rites of C:

C has useful abstractions.

[dkf]

@topspin said in The abhorrent 🔥 rites of C:

And then you necro the thread with a complaint that is literally a backwards compatibility with C issue? Oh the irony.

I necro'd because someone upvoted a post that I thought was missing a point (that caused me pain a few months after I wrote that message). You were free to not reply.

[topspin]

@dkf said in The abhorrent 🔥 rites of C:

You were free to not reply.

I had to endure . I need pain relief now.

Filed under: you may be entitled to compensation.

[Bulb]

@topspin said in The abhorrent 🔥 rites of C:

@dkf so there’s this long-ass thread about how C is basically horrible. A bunch of guys come in to argue it’s not just “good” for systems programming, it’s the best.

Note that situation has changed significantly in the intervening 8 years. 8 years ago, there were cases where C was the only viable option, so it was best for them by virtue of having no alternative. Since then Rust has matured and Zig and Nim have stabilized, providing such alternative.

And definitely better than C++, while showing a complete lack of understanding of how that actually works, or how to do things in a non-C way even in C++98, let alone anything current in 2016. (“What do you mean ‘owning pointer’?”

That doesn't really differ between C and C++, or Pascal or Ada or any other language with explicit memory management for that matter. In all of them you must distinguish between pointer to something you own, and thus have to free, and something you don't own, and thus must be aware until when it is expected to be available.

C++ adds smart pointers that take care of remembering to free things for you.

( reading through the old posts to see who said what)

And an astounding lack of understanding about the subtopic that Foo* might need a special deallocation function instead of free.)

Approximately all custom types manipulated by pointer I've seen in any C library ever came with their own allocation and deallocation functions. Including standard library types like FILE * (freed by fclose) and DIR * (freed by closedir).

@ronin said in The abhorrent 🔥 rites of C:

C has useful abstractions.

C does have useful abstractions. It's just that most other languages have more of them and they are even more useful.

[dkf]

@Bulb said in The abhorrent 🔥 rites of C:

C++ adds smart pointers

The Internet of AIGPT threads are

[Bulb]

@dkf They've been called that … even before phones started to be called “smart”.

[izzion]

@remi said in The abhorrent 🔥 rites of C:

: Why?? But why?!?
: Because the C++ Standard, paragraph 42.6.7, says so, that's why.

---

Filed under: whose law is it that every thread will end up discussing the C++ Standard?

Does the C++ Standard come from a major town in the New England, USA area?

[TwelveBaud]

@remi said in The abhorrent 🔥 rites of C:

Because the C++ Standard, paragraph 12.4.3.2.2.1, says so, that's why.

[over.ics.rank]

[topspin]

@Bulb said in The abhorrent 🔥 rites of C:

@topspin said in The abhorrent 🔥 rites of C:

@dkf so there’s this long-ass thread about how C is basically horrible. A bunch of guys come in to argue it’s not just “good” for systems programming, it’s the best.

Note that situation has changed significantly in the intervening 8 years. 8 years ago, there were cases where C was the only viable option, so it was best for them by virtue of having no alternative.

C++ has been better than C. (Don’t tell me you don’t want exceptions, just don’t use them.)

Not good. Never good. Better than C.

Since then Rust has matured and Zig and Nim have stabilized, providing such alternative.

The “C sucks” side of the thread had already discussed some of the potential benefits of Rust, the other side didn’t think there’s use for any it.

And definitely better than C++, while showing a complete lack of understanding of how that actually works, or how to do things in a non-C way even in C++98, let alone anything current in 2016. (“What do you mean ‘owning pointer’?”

That doesn't really differ between C and C++, or Pascal or Ada or any other language with explicit memory management for that matter. In all of them you must distinguish between pointer to something you own, and thus have to free, and something you don't own, and thus must be aware until when it is expected to be available.

Yes, of course.
Smart pointers both automate the when and encode the how of releasing a resource. And require explicitly specifying the ownership model you should have thought about anyway.

C++ adds smart pointers that take care of remembering to free things for you.

( reading through the old posts to see who said what)

And an astounding lack of understanding about the subtopic that Foo* might need a special deallocation function instead of free.)

Approximately all custom types manipulated by pointer I've seen in any C library ever came with their own allocation and deallocation functions. Including standard library types like FILE * (freed by fclose) and DIR * (freed by closedir).

Exactly.
One side of the discussion in the first half of the thread had completely failed to grasp what the point is of having the compiler do that automatically for you, of having the how encoded into the type, and didn’t see a problem that the compiler cannot even warn you when you pass it to the wrong function, because they’re all pointers and calling free on them is syntactically valid.

“Nobody ever calls free on a FILE*.” Maybe. But people forget to free, double-free, and yes, also call the wrong deallocation function for other types all the time.

[cvi]

@topspin said in The abhorrent 🔥 rites of C:

“Nobody ever calls free on a FILE*.”

You can't tell me what to do!

[error]

@TwelveBaud said in The abhorrent 🔥 rites of C:

@remi said in The abhorrent 🔥 rites of C:

Because the C++ Standard, paragraph 12.4.3.2.2.1, says so, that's why.

[over.ics.rank]

https://meta.m.wikimedia.org/wiki/Cunningham's_Law

[error]

@topspin said in The abhorrent 🔥 rites of C:

Smart pointers both automate the when and encode the how of releasing a resource

I remember asking SO how to do try...finally in C++ and instead getting a lecture about how finally is bad and RAII is superior in every way.

But it was really reading The Design and Evolution of C++ that convinced me it was a terrible language.

[dkf]

@error said in The abhorrent 🔥 rites of C:

RAII is superior in every way.

Especially in how it induces nonsense crashes in programs on exit, when every sensible language just leaves the memory cleanup to the OS.

[PleegWat]

@dkf Freeing everything does make it easier to use valgrind(1).

[Bulb]

@topspin said in The abhorrent 🔥 rites of C:

Smart pointers both automate the when and encode the how of releasing a resource.

Apropos, the other day (a couple of years ago already) I needed to check how exactly something behaves in systemd, so I looked in the source code. And I noticed that gcc now supports smart pointers in C—there is an attribute that tells the compiler to call given function when a variable goes out of scope.

@error said in The abhorrent 🔥 rites of C:

RAII is superior in every way

RAII is superior, but before closures, if you had a type that was not designed for it, adding it ad-hoc was quite a lot of typing.

@error said in The abhorrent 🔥 rites of C:

But it was really reading The Design and Evolution of C++ that convinced me it was a terrible language.

It was the first mainstream attempt with many of the features, so before people learned how to use them for good, they learned how to abuse them horribly and that means there is a lot of horrible C++ code out there. And some of the features turned out not to be designed all that well (in particular inheriting the idea that everything is copyable from C turned out to be a big mistake – whereas in C most programmers don't even know everything is copyable, because in practice most things will break horribly if you copy them).

[dkf]

@PleegWat said in The abhorrent 🔥 rites of C:

@dkf Freeing everything does make it easier to use valgrind(1).

Yes... but sorting out the tangle that exists around the destruction of global objects is typically not worth it. The program's going away right now anyway, damnit!

Anything that absolutely needs to do something special at that point should use an exit handler. Apart from I/O buffer flushing, that typically isn't much.

[PleegWat]

@dkf And valgrind won't report stuff in globals as leaks. If it's only held on the stack though it will be reported.

Apart from that I prefer freeing anything I support on the fly reinitialisation for, since I want to know about leaks there.

[dkf]

@PleegWat said in The abhorrent 🔥 rites of C:

Apart from that I prefer freeing anything I support on the fly reinitialisation for, since I want to know about leaks there.

Finalisation makes sense for some libraries. It does not make sense for full consumer-facing applications.

[cvi]

@dkf said in The abhorrent 🔥 rites of C:

it induces nonsense crashes in programs on exit

If there are crashes (nonsense or not), that's pretty much on you doing it wrong.

If you don't want destructors to run on program exit (because you don't need them), you can opt to do so with quick_exit. If you're consistent about it, you can register handlers for quick_exit (e.g., you do want something to be flushed). Running destructors is a safe default, though.

[dkf]

@cvi said in The abhorrent 🔥 rites of C:

@dkf said in The abhorrent 🔥 rites of C:

it induces nonsense crashes in programs on exit

If there are crashes (nonsense or not), that's pretty much on you doing it wrong.

Then a great many application developers (especially game devs) are doing it wrong.

[cvi]

@dkf They are. A recent triple-A game that only crashes on exit? Their QA person (singular, probably) deserves a raise.

[ixvedeusi]

@dkf said in The abhorrent 🔥 rites of C:

a great many application developers (especially game devs) are doing it wrong.