The code contains things that make any modern C++ or Rust developer cringe: naked pointers, unsafe type casts, raw loops, using malloc/free to manually allocate memory for buffers, and calls to unsafe free functions like strcat. So much slow boilerplate is required to do things like handling memory allocation. The increased source code size for even the simplest things becomes harder to maintain. Danger is waiting ar…
A simple C implementation to stream H.264 to browser using WebRTC
61–70 of 128 posts
Re: A simple C implementation to stream H.264 to browser using WebRTC
#62The code contains things that make any modern C++ or Rust developer cringe: naked pointers, unsafe type casts, raw loops, using malloc/free to manually allocate memory for buffers, and calls to unsafe free functions like strcat. So much slow boilerplate is required to do things like handling memory allocation. The increased source code size for even the simplest things becomes harder to maintain. Danger is waiting ar…
Perhaps you'd like to point out an actual bug you've found...? This sort of dogmatic cargo-culting paranoia-rant is exactly why people are getting sick of hearing about the "modern" BS.
Re: A simple C implementation to stream H.264 to browser using WebRTC
#63The code contains things that make any modern C++ or Rust developer cringe: naked pointers, unsafe type casts, raw loops, using malloc/free to manually allocate memory for buffers, and calls to unsafe free functions like strcat. So much slow boilerplate is required to do things like handling memory allocation. The increased source code size for even the simplest things becomes harder to maintain. Danger is waiting ar…
Perhaps you'd like to point out an actual bug you've found...? This sort of dogmatic cargo-culting paranoia-rant is exactly why people are getting sick of hearing about the "modern" BS.
Re: A simple C implementation to stream H.264 to browser using WebRTC
#64The code contains things that make any modern C++ or Rust developer cringe: naked pointers, unsafe type casts, raw loops, using malloc/free to manually allocate memory for buffers, and calls to unsafe free functions like strcat. So much slow boilerplate is required to do things like handling memory allocation. The increased source code size for even the simplest things becomes harder to maintain. Danger is waiting ar…
Re: A simple C implementation to stream H.264 to browser using WebRTC
#65Earlier quoted context omitted.
You'd also need a TURN server if both peers are behind NAT without UPnP, which is very common. STUN alone wouldn't be enough.
That is partially incorrect, STUN can punch a hole through even when both sides uses NAT in many cases. That is what I would classify as STUN’s main feature.
Re: A simple C implementation to stream H.264 to browser using WebRTC
#66The code contains things that make any modern C++ or Rust developer cringe: naked pointers, unsafe type casts, raw loops, using malloc/free to manually allocate memory for buffers, and calls to unsafe free functions like strcat. So much slow boilerplate is required to do things like handling memory allocation. The increased source code size for even the simplest things becomes harder to maintain. Danger is waiting ar…
Oh man, wait till you see the Linux source code...
Re: A simple C implementation to stream H.264 to browser using WebRTC
#67Earlier quoted context omitted.
Perhaps you'd like to point out an actual bug you've found...? This sort of dogmatic cargo-culting paranoia-rant is exactly why people are getting sick of hearing about the "modern" BS.
I already have to debug C/legacy C++ code (“C with classes”) on a daily basis for my day job, so I sure certainly am not going to waste my free time doing it. The best I can do is be an evangelist for better practices, a fly on the ass of people who still pump C into the garbage stream of the internet.
Hey, as long as people keeps writing C and C with classes, you'll have a day job.
Re: A simple C implementation to stream H.264 to browser using WebRTC
#68The code contains things that make any modern C++ or Rust developer cringe: naked pointers, unsafe type casts, raw loops, using malloc/free to manually allocate memory for buffers, and calls to unsafe free functions like strcat. So much slow boilerplate is required to do things like handling memory allocation. The increased source code size for even the simplest things becomes harder to maintain. Danger is waiting ar…
Sorry to be crude, but can you people take this self-righteous bs elsewhere? Not every thread needs to be about the superiority of Rust or your gripes with C.
This cancer is ruining every thread on HN now.
Re: A simple C implementation to stream H.264 to browser using WebRTC
#69Earlier quoted context omitted.
C with Asan or Valgrind is faster to write and just as performant (usually better) as Rust or C++. There's a reason the world runs on C, and only part of it is historical.
I just can’t recommend using it for new code in light of the sexy new alternatives that can compile down to the same binary with source code that’s way more intuitive and readable. I do have nostalgia for C since it was my first language, and I think a lot of people are in the same boat, which is a problem. That’s why I think we need to stop teaching C. Kate Gregory has a good cppcon talk on the topic: https://youtu.…
"C" is glorified assembly and learning assembly is *fundamental* to understand how computers work. "C" *should* be the first language programmers learn when they get serious (ex: first year computer science classes).
When I write "C" I know exactly what is going on with each of my CPU cycles and where my variables are being allocated. The compiler is a dead simple translator who doesn't play funny tricks behind my back.
"C" is the perfect language to learn and have fun with the underlying architecture.
"C" is very easy to learn and not that hard to master. It is fast to compile, fast to run and available everywhere.
I don't like "C++". All code bases maintained by more than one single developer (no matter the language it is written in) become rotten with time but, from my experience, the larger the amount of features a language has, the worst this becomes. All big "C++" projects I have worked on (except for one) were horrendous. This also happens in "C", but in "C" I can just "grep" the keyword and immediately know where it comes from.
I don't like "Rust". I've tried to learn it twice and failed. There are too many places where I lose track what the compiler is doing, the (formal?) specification is big and complex and keeps growing (approaching "C++" absurdity levels). There is never an "obvious" way to do one thing. I get "Rust" is a test bench for language designers, but they are creating an over-engineered monster that is not easy to use (think "low gravity ink injection pen" vs "pencil")
So... "C" is perfect for me (and many others). It's simple, fast and as powerful as it gets, which means it is also fun. As others have mentioned on this thread, together with "cppcheck", "valgrind", "electric-fence" and friends it is also as secure as any other.
"C" is here to stay.
Re: A simple C implementation to stream H.264 to browser using WebRTC
#70Earlier quoted context omitted.
I already have to debug C/legacy C++ code (“C with classes”) on a daily basis for my day job, so I sure certainly am not going to waste my free time doing it. The best I can do is be an evangelist for better practices, a fly on the ass of people who still pump C into the garbage stream of the internet.
Since the text in your parent post is more or less the same of your last comment from 10 hours ago, I agree you are in a sort of "keyword oriented" evangelization crusade against good'ol C. The question would be, why caring so much? Hey, as long as people keeps writing C and C with classes, you'll have a day job.