Any hopes that MSVC will add C23 support before 2040?
Will windows be relevant by 2040? I personally don’t think so.
Depends on how much Valve manages to get rid of Proton.
Giving C a superpower: custom header file (safe_c.h)
21–30 of 277 posts
Re: Giving C a superpower: custom header file (safe_c.h)
#22I don't understand this passion for turning C into what it's not... Just don't use C for sending astronauts in space. Simple. C wasn't designed to be safe, it was designed so you don't have to write in assembly. Just a quick look through this and it just shows one thing: someone else's walled garden of hell.
Some C devs will make all kinds of crazy efforts only not to use C++.
Re: Giving C a superpower: custom header file (safe_c.h)
#23> C23 gave us [[cleanup]] attributes
C23 didn't introduce it, it's still a GCC extension that needs to be spelled as [[gnu::cleanup()]] https://godbolt.org/z/Gsz9hs7TE
Re: Giving C a superpower: custom header file (safe_c.h)
#24Earlier quoted context omitted.
Yeah, kids like to waste time to make C more safe or bring C++ features. If you need them, use C++ or different language. Those examples make code look ugly and you are right, the corner cases. If you need to cleanup stuff on early return paths, use goto.. Its nothing wrong with it, jump to end when you do all the cleanup and return. Temporary buffers? if they arent big, dont be afraid to use static char buf[64]; No…
God forbid we should make it easier to maintain the existing enormous C code base we’re saddled with, or give devs new optional ways to avoid specific footguns.
Goofy platform specific cleanup and smart pointer macros published in a brand new library would almost certainly not fly in almost any "existing enormous C code base". Also the industry has had a "new optional ways to avoid specific footguns" for decades, it's called using a memory safe language with a C ffi.
Re: Giving C a superpower: custom header file (safe_c.h)
#25I checked Fil-C out and it looks great. How is this different from Fil-C? Apart from the obvious LLVM stuff
Re: Giving C a superpower: custom header file (safe_c.h)
#26A recent superpower was added by Fil aka the pizlonator who made C more Fil-C with FUGC, a garbage collector with minimal adjustments to existing code, turning it into a memory safe implementation of the C and C++ programming languages you already know and love. https://news.ycombinator.com/item?id=45133938 https://fil-c.org/
[deleted]
Re: Giving C a superpower: custom header file (safe_c.h)
#27C++: "look at what others must do to mimic a fraction of my power" This is cute, but also I'm baffled as to why you would want to use macros to emulate c++. Nothing is stopping you from writing c-like c++ if that's what you like style wise.
> I'm baffled as to why you would want to use macros to emulate c++.
I like the power of destructors (auto cleanup) and templates (generic containers). But I also want a language that I can parse. Like, at all.
C is pretty easy to parse. Quite a few annoying corner cases, some context sensitive stuff, but still pretty workable. C++ on the other hand? It’s mostly pick a frontend or the highway.
Re: Giving C a superpower: custom header file (safe_c.h)
#28I don't understand this passion for turning C into what it's not... Just don't use C for sending astronauts in space. Simple. C wasn't designed to be safe, it was designed so you don't have to write in assembly. Just a quick look through this and it just shows one thing: someone else's walled garden of hell.
> Just don't use C for sending astronauts in space. Simple.
Last time I checked, even SpaceX uses C to send astronauts to space...
Re: Giving C a superpower: custom header file (safe_c.h)
#29I don't understand this passion for turning C into what it's not... Just don't use C for sending astronauts in space. Simple. C wasn't designed to be safe, it was designed so you don't have to write in assembly. Just a quick look through this and it just shows one thing: someone else's walled garden of hell.
Actually C performs quite good in exactly that area. https://ntrs.nasa.gov/citations/19950022400