* Perfection
* Targetability
* Superiority
* Dignity
C
Base....SIGSEGV
the -> operator is pointless, the thing would work the same with dot
>baby's first pointer
kek
* should be a postfix operator also
>* Perfection
wrong
>* Targetability
wrong
>* Superiority
wrong
>* Dignity
wrong
>PTSD
I see what you did there
> -> is pointless.
The rust language itself offers nothing new and is poorly implemented. So what's left besides marketing wank and the community full of shills who harass everyone.
>angry grandpa notices developing language trying new shit
>new shit is not as mature as old shit
>progress is being made
*300baud screeching*
The problem is not c itself, but that it takes longer to write the damn makefile than the actual program.
C with a proper build manager would blow all languages out of the water
What is CMake?
C is still an awful legacy language only worth writing if there are no other options.
>wrong
wrong
>* Perfection
Not really
>* Targetability
hahaha no
>* Superiority
In obsolence? maybe
>* Dignity
Yes
>Superiority
Yeah, try writing a complex multithreaded program without wanting to hang yourself.
CFLAGS = -Wall -W -pedantic -std=c11
progname: $(patsubst %.c,%.o,$(wildcard *.c))
clean:
rm -f progname *.o
I've had people vigorously defend posix threads as some high watermark of concurrency and parallelism. All while they spent days tracking down a single race condition in their thread spaghetti.
kek this is a short pasta
>What is CMake?
Shit.
Meson is the new hotness.
Use that.
Freertos
needs -Wextra
>GNU extension
ok, but rather call it gmake
>improper dependency handling
This way every .o file only depends on it's correcponding .c file. This is wrong. It also depends on every header file recursively, standard library and relevant variables inside the build script itself. (Or even worse - environment variables.)
The only proper way to get the list of dependencies (outside make variables) is to let the compiler tell you $ gcc -MM -MG but this plays terribly with make.
Solving the variables can be done via moving things into multiple script files, but this is so fucking terrible in make.
>building inside source directory
This is bad practice, but make makes it hard to maintain separate obj/ and build/. If you manage to achieve this, it's no longer elegant Makefile.
Clean is the only about deleting those directories.
also non-atomic builds
>perfection
I like C, but no.
You forgot 2 pluses.
> portability.
>* Perfection
no
no
* Segmentation fault: Core dumped
>Meson
using premake, it is so comfy
Well, x->y is a pointless way to write (*x).y, no?
there is no scenario where automatic dereferencing would stay in a way and you could use x.y and x->y at the same time
Pointless, user. Pointless. Point, dot, period...
Is it like those random generated album arts from /mu/?