>>109404678
who's going to rewrite all those mountains of c code? you?

C is pretty kino, ngl. It is simple, damn fast and explosive. It is attractive & interesting like a violent convict.

>>109404678
Anon, the problem is not just C but all the languages based on C. Rust is juts C with a borrow checker, Zig is just a modern C, Odin is C, all languages are C.

>>109404752
Shut up moron.

>>109404760
I'll take C but with modules and without UB.

>>109404760
Anon, the problem is not just languages based on C but languages based on Algol. C is just algol with pointers, ... etc. Anyway C and UNIX obliterated lisp jews. So bite it, anon.

>>109404829
>the problem is not just languages based on C but languages based on Algol
Yeah, I can accept that. In fact I would say the problem is the lack of semantic clarity, there's not practical way of declaring meaning and usage so programs still being mostly imperative and resources are handled manually.

>>109404678
why are people afraid of C?

>>109405004
Can't into pointers or manage memory.

>>109405004
99% of people cant handle the responsibility

>>109404727
Just use Fil-C retard. Big daddy Filip did the hard work of sewing a straight jacket so cniles won't hurt themselves.

>>109404678
Its either that or bloated cpp and rust… i will take my chances with c

>>109404678
it filters out the trannies and the sub100IQ retards.
it takes a genius to appreciate simplicity

>>109404752
Some of the decisions in C are very old and stupid. It could be much better with very little changes.

>>109405382
so, Hare?

>>109404678
this guy is a proto-tranny you just know hes gonna troon out at some point

>>109405382
yes, this. i am surprised they dont clean up the warts on the stdlib a bit.
and bind * to the type instead of to the variable name.

>>109404678
log in aout

>>109405429
>t. troon

>>109405026
>the responsibility
it's more like free(your shit) scares them, the word free frightens them that they might be dominated by freedom and freedom is bad ok?

>>109405474
how people use free() is my second filter for c programmers that apply to my department.

>>109405004
They are easily psyoped retards. C has the advantage of 40 years of hindsight, so if you're working on your own project you can use tons of libraries and learn from others as to what the best practices are. Compare that to Rust where a lot of the pain points are still being discovered. For example how you can easily fuck yourself with ?'s and .unwrap() (ie not properly handling errors) and its really easy to write yourself into a corner and require anyhow::Result<Option<Arc<Mutex<Vec<Box<dyn Something<'a>>>>>>>> for every function.

Just learn C. It'll help you understand everything else better and its problems are overblown. If nothing else it'll make you appreciate other languages more.

>proclaim c strings are terrible
>c doesn't actually have a string data type

>>109407368
t. brainlet

>>109405004
No containers

>>109404678
They're retarded and think shilling the hard language makes them look smart.

>>109404727
LLMs.

>>109404678
idk. why not just use c++?

>>109407537
lol
lmao even

>>109404678
Because C seems simple in the same way that buying a $100 lathe off AliExpress seems inexpensive. In the end you get what you pay for. Just as a Chinesium lathe is a worthless sink of money, C's one-time learning of it's simple design make you pay every time you go to use it for anything.

>>109407726
skill issue

>you can code anything in C
you can also code anything in Brainfuck. why the fuck would you is the real question, and it has no sane answer.

>>109405495
you should never use free more than a single time, in your attribute cleanup definition
from that point on, it just werks

>>109407727
interestingly: any time a retard says "skill issue" it's in fact not a skill issue

>>109404752
The results are portional to how massive my cock gets over using C, which is big

>>109405495
I don't use free. I use RAII because I am not a retard.

>>109407742
filtered.

>>109407731
C is a modern Turing tarpit

>>109407746
I know you were.

>>109407752
yeah? well your mother is so fat that when she hauls ass, it takes two trips.

>>109407396
I would be a contrarian wiener and say write your own but the truth is you’re right and it’s the main reason I usually opt for C++ or Zig for any non-MCU project.

>>109407863
write them with void* or write a script that writes your container code that fills in the type name everywhere

>>109404678
for its simplicity and speed

>>109407742
I use

Arena->Top = 0;

for 90% of my memory management because RAII is dogshit

>>109404678
>Why do people still insist on using C?
Because it lets you do whatever you want.

It's fun.

>>109404678
Nobody codes manually anymore

>>109407537
ahahahahahahahahahahahah

>Free
Imagine using malloc when you can use byte[]

>>109404678
Preparing for infrastructure collapse, you also need to learn Forth and how to solder your PS2 chip

>>109408253
what happens when you need to allocate something bigger than 4kb?

>>109407368
>>c is a typed language
>uses char* for literally everything

>>109408339
why would you do that?

>>109405004
low IQ and small balls

>>109408349
char* is indeed a type

>>109408407
the only one you'll ever need, apparently

C is the only language which doesn't complain about pointer types.
unlike C++ which forces one to cast every pointer because a retard might make that mistake, can't turn it off even.
not to mention retarded designated initializers in C++ compared to C99.
all in all, much less restrictive to write mini DSLs compared to C++.

>t. -Wno-pointer-sign -Wno-int-conversion -Wno-incompatible-pointer-types -Wno-format chad

>>109408410
Wrong, you need to cast the content of your char* buffers to arithmetic types to do calculations. You can cast it back to char* when you're done.

File: 1737058757986910.jpg (142 KB, 960x720)

142 KB JPG

>>109405382
every single criticism i've had of C (save for a very minor few, e.g. bitwise operator precedence, lack of nested block comments) have melted away when i learned more of the design decisions made. every. single. one.
if you think the design of C is stupid, the problem can be seen in your bathroom the mirror.

>>109407909
arenas are a massive cope

>>109404678
my father wrote c;
i write c;
God willing my children will write c

the tooling is good and the language is simple
>but i need more!
use a modern standard like c23
>more!
use gnu c extensions

>>109404678
Because there still are white programmers.

>>109408453
whatever, enjoy your pointer rats nest I guess. the computer still has to deal with your retarded bullshit. it doesn't magically go away just because you swept it under the rug

File: coughingbaby.jpg (28 KB, 612x408)

28 KB JPG

>>109408632
if i can't see it, then it doesn't exist

>>109408498
there is no C but ANSI C

>>109404678
when dealing with low-ish level stuff, the alternatives are utter niggertrash

c is just the least shit proposition, and, actually, it pretty good in places

>>109408449
c is too strict, actually
huehue, i bet you never heard this one
but yeah. i sometimes butt my head against design decisions that disallow stuff that could be allowed, but isnt because of ideological reasons.
like not being able to access static variables out of scope

i mean, sure, they shouldnt be accessible by name out of scope, but they should be accessible by pointer
>b-but muh safetu
fuck your safety while i make you watch
if i cared about your "safety" i wouldnt be using c

>>109408449
the preprocessor is stupid, and header files are just offloading work onto the programmer because the compiler just HAD to be single pass. maybe at the time the understanding of compilers and the limitations of hardware made it a necessary concession but to never iterate on a solution after all these years is crazy. it's the same story with undefined behavior. it's a matter of being lazy in your design and not fully solving the problem so that you can do the most niggerlicious optimizations imaginable. also integer promotion sucks

I would still rather use C than anything else but it has some really stupid problems

>>109409039
>headers bad
i kinda disagree, theyre like a table of contents for your code, no?

File: manul-pallas-cat.gif (2.16 MB, 281x498)

2.16 MB GIF

>>109404752
>simple, damn fast and explosive
Like diarrhea.

>>109409066
they're useless busywork, something that at best if it should exist at all, it should be generated automatically, not written by hand

>>109409039
Wirthian languages are strictly more powerful than C and don't need headers in general, despite being single-pass. Bad meme.

>>109405382
Even older languages do not have C's stupid flaws and in fact, even modern languages emulate poorly the capabilities of these languages. It's not about age.

>>109409091
>it should be generated automatically, not written by hand
ah. this i agree with
i just like having all the function definitions, and all the object definitions in one-ish place
i open the relevant header on a second screen and it is something i can avoid having to keep in my mental-scape, i just look relevant information up

mechanically, i think it hasnt been done because of the way compilation,linking works

you can link with already compiled code without recompiling it.
and your can link your code selectively
as in:
you have foo.o, bar.o, and if youre using only foo, you dont need to link with bar
so now both need to have the information contained within the header, duplicating the thing

it can be solved graciously but at the cost of complexity and/or object size, so it has been left to the programmer's discretion, i reckon

but like you said, it can be automated. nothing prevents you from writing a script just for that yourself
its a disadvantage that you should do something like that
but by the same token c's simplicity is an advantage to do so, and not everything can be standardized, so it sometimes comes in handy

i dont have much of it burt right now i use a non standard mechanism to assist make for when it compiles my code, to prevent it from recompiling all my libs
long story short: c being simple, archaic even, makes it much easier to write utilities that deal with the language

>>109409148
>but like you said, it can be automated. nothing prevents you from writing a script just for that yourself
>its a disadvantage that you should do something like that
I already do. My point is that I shouldn't have to.

>>109409155
yeah? no?
it depends on the context you give to "should".

it like using a passport. we're already face-scanned, why should we be still using passports anywhere?
welp, legacy systems and the complexity of completely doing without.
from one perspective its a "should", but from the perspective of designing a system it can turn into a "shall"

>>109409091
Fucking zoomer retard take

>>109409066
it should be an interface you implement instead. current implemention of headers is just pointless busywork

>>109409039
wow. literally everything you say is wrong

>>109409328
>it should be an interface you implement instead.
what do you think headers are for?

>>109409328
yeah, youre maybe right
when said like that, this *does sound trivial to implement
the other way around- reconstructing a header could be done with a grep

it doesnt solve for the fact that each translation unit would need at least a portion of the header included into it though
bc you got two stages to compilation- compiling proper and then linking
with some of it happenning during runtime

it just kinda makes sense to have a header file in a text format

so yeah, i can see the merit and feasibility of auto generating a header
but i dont think going header-less is worth the complexity

>>109409363
i think he meant
"change c's syntactical conventions ever so slightly, maybe add a couple keywords to make makefile generation truly trivial"
i think he used "interface" in the larger sense, how you interact with the language as a whole

>>109409393
>makefile generation
*header generation

>>109409401
the last thing i want is for the most important things to develop against to be autogenerated

>>109409383
consider the following
https://github.com/nothings/stb

>>109409427
i think theres a balance to be found:
because with more auto-generation theres more infrastructure to build
and it becomes more complex, with its elements interacting with eachother
and thats more code surface to verify
plus, now, if theres an error, or a vulnerability, its hidden from the programmer

i think theres a point where automation gives diminishing returns, and an idealized point where it starts giving negative returns (sometimes real, i think: php, when all things considered. but its just a hunch, i wont be dying on that hill)

>>109409468
>https://github.com/nothings/stb
>code in header
i saw this a couple times
but yeah, it has its limitations:
>Because stb_image is a header-file library that compiles in only one source file, there's no approved way to build both an SSE-enabled and a non-SSE-enabled variation.
and thats directly because of the way c handles compilation.

i reason that the canonical way is to work with the compilation unit as primitive, so various compilation options cannot be applied at the scale of code block, or line
and afaik compilation unit == .c file in source. or .h in this case
in result:
> theres no approved way to deal with that

>>109409468
>>109409514
aactually
i think the workaround would be to trust the user to decide which instruction sets they want enabled
since its gcc specifically were talking about there can be an "__attribute__((constructor))", which is made to run before main, that checks the runtime-recovered instruction sets and exits gracefully if an error is detected

the architecture-specific code sitting behind an ifdef

apparently there may be a way of recovering the flags the code gets compiled with as available variables in compilation, but ive never done that and am too lazy to actually look it up
its sounds like something the good compiler people would have thought about though

aaaaand theres also self modifying code
but thats black magic, one shouldnt use things of this sort unless all other options have been exhausted
actually, since thats a public lib i think security concerns just remove that option from the table from the get go

>>109409564
-frecord-gcc-switches

>>109409594
noice. the good compiler people always think of everything

>>109404678
they're mentally ill retards.

>>109407746
only free()cels are filtered because they have to rely on their allocator to tag metadata to their pointers.
free() should have required 2 parameters, but C is a shit language and now we all suffer for it.

>>109409638
>im not filtered, you are filtered
i think you should defenestrate yourself repreatedly and vigorously

>>109409661
if you think free(void*) is good, you're filtered by your low IQ.

>>109409666
its not only good, its also sexually attractive
you must be gay. i blame porn over-use

>>109409638
it was fine at the time. we are talking about something from the 1970s.
and lest we throw stones, java had the addition overflow bug in binary search until 2006.
the "oh itll never be a problem, 2^32-1 is a huge number" sweeping shit under the rug philosophy that a lot of the old languages were designed with wasnt a problem for a long time. now there are a bunch of opportunities for bugs, e.g., malloc needs to be malloc(count, size_per_item) because theres an overflow that can happen there. i think it was a firefox exploit a few years back.

>>109409719
free gives you exact control over the lifetime of your memory objects while abstracting all the machinery away
it also gives more freedom to the os to its side of the magic
plus it lessens the complexity of the compiler
plus plus it just looks nice
sometimes i malloc things with 0 just so that i can place a few redundant frees later on uwu

>>109409719
>it was fine at the time
ya, and now it's 2026 and it's no longer appropriate. most alt-allocators all suffer because of the brain damage.

>>109409736
>alt allocators... like rust's
yeah fanks no fanks
free() still ruling champion, undefeated
plus youre just hiding the dog's shit under the carpet
because underneath your runtime is still downstream of the os memory-wise, as long as youre not coding on bare metal

the zen path is to stop worrying and just use arenas compulsively.
you will understand someday.

>>109409753
free has nothing to do with the downstream OS you fucking retard.
who the fuck are you? take your schizo meds.
>arenas
>I can't track the lifetime of my allocations so I just badly replicate GNU's ptmalloc and leak memory instead
shut the fuck up, holy fucking shit.

File: 1779995583313993.jpg (180 KB, 320x1392)

180 KB JPG

>>109409753
its ok, i still love you, too-autistic-for-/g/ anon

>>109404678
Lowest common denominator. It's simple, fast, and works fucking everywhere.

>>109409761
your arena IS the lifetime, young padawan
thats how an arena becomes more than an allocator, and becomes an organizational tool
the man is an elephant who believes hes a mouse pretending to be a tiger.
once you will grow out of your anger, you will realize it was insecurity all along...

>>109409770
everything we do could be reformulated as an act of love
the only thing changing, is its object, then

>>109404678
Because C is still the lingua-franca of computing. Anything else is a second had citizen that has to communicate through a grotesque FFI. Personally, I really hate FFI and would rather just keep everything in C

>>109407582
The only good part of c++ is c

>>109408415
I finally got sick of c++'s bullshit and modified the compiler so that c++ would behave more like c. My dialect of c++ supports implicit cast from void* pointer for example.

>>109409039
I agree the single pass compiler is bad. But headers do actually solve a problem that module based languages always struggle with. That being libraries and dlls.

>>109409874
>solve a problem that module based languages always struggle with. That being libraries and dlls.
w-what?

>>109409914
headers facilitate gluing together different chunks of compiled code. Modules make this difficult because there is no separation between prototype and implementation. Modules only really work with JIT languages.

>>109410017
this is not true. there is nothing preventing compiled modules from working without "headers." You're just a fucking retard. If you mean monomorphization or templates in general, no shit? That's one of the many real world problems in the world and also why Java generics are shit too, forcing you to box everything, like primitives.

>>109410037
i would prefer to have a header and the compiler telling me "yo you called this function wrong" than blindly building function calls and hoping for the best. this kind of shit is what compilers are good at and should have zero human calories expended on it.

>>109410077
>i would prefer to have a header
why? headers are separate from implementation. there is zero reason for them if you have a properly defined module format. You're just fucking stupid and wrong. stop coping.

>>109410037
Can you give an example of any language besides c/c++ that is not a JIT language, that can do the equivalent of shipping a shared library and header file.

>>109410115
what the fuck are you even on about you stupid faggot? headers are shit. full stop. get your head of your stupid faggy ass and learn how computers work.

jesus christ this board is so shit.

>>109410083
did i not explain myself in my post? i know they are not necessary. they are nice to have.

>>109410134
And yet your meme of the day language can't into shared libraries.

>>109410145
>they are nice to have.
how? they are detached from their implementation. that by definition violates DRY.

>>109410077
>>109410083
i think the actual points are
-modularity in compilation units
-abi contracts

modularity in compilation units because you dont need to link with stuff you wont be needing, yet there are some global interfaces, like a query object, for instance.

if you dont have an external header, then you need to duplicate the definition of said query object across all your compilation units

then theres the abi contract between code two programmers, one exposing his lib's functionality, and the other using it- do
you need stable interfaces for both codebases to be able to evolve independently, which would be, in effect, a header separate from code, regardless if its included into the modules, or a separate .h file

so yeah, the fact that it sits separate is the result of the fact that both headerful and headerless solutions necessitate engineering tradeoffs.
in the case of c- the tradeoff is that its not generated automajically, to gain faster compilation times, more flexibility, and less code in the ecosystem supporting the language

>>109410162
>external header, then you need to duplicate the definition of said query object across all your compilation units
external header is a duplication, so you're already wrong.

>>109410176
its not a duplication because its guarded with ifdefs or you get compilation errors from multiple definitions

>>109410182
it's a duplication of information, retard. on top of that, there is nothing preventing you from including code in headers, making them more than just definitions.

>>109410190
nah, its the exact opposite
cf. some (many) objects are represented globally

>>109410195
>write x.c
>have to define x.h with everything I'd want linkable from x's build artifact
it's a duplication of information. it violates DRY principle and should not exist in 2026.

stop coping.

File: 1784705395843038.png (319 KB, 480x328)

319 KB PNG

>>109410155
oh no
oh sweaty

>>109410205
again
>have normalized interface object. like queries.
>now your object has to be duplicated in all your translation units. or you have to parse all your lib to find the relevant definition

de-duplication. the exact opposite of what youre positing