Live data from Hacker News

A simple C implementation to stream H.264 to browser using WebRTC

github.com

61–70 of 128 posts

Re: A simple C implementation to stream H.264 to browser using WebRTC

#61

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…

Oh man, wait till you see the Linux source code...

Re: A simple C implementation to stream H.264 to browser using WebRTC

#62

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…

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.

Re: A simple C implementation to stream H.264 to browser using WebRTC

#63

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…

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.

The modern C++ techniques being referred are 10 years old at this point already and have stayed in consensus. No need to get salty.

Re: A simple C implementation to stream H.264 to browser using WebRTC

#64

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…

[deleted]

Re: A simple C implementation to stream H.264 to browser using WebRTC

#65

Earlier 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.

Note that parent said “ if both peers are behind NAT without UPnP”. As far as I know, there’s no way to punch holes / open ports automatically without UPnP.

Re: A simple C implementation to stream H.264 to browser using WebRTC

#66

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…

Oh man, wait till you see the Linux source code...

[deleted]

Re: A simple C implementation to stream H.264 to browser using WebRTC

#67

Earlier 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.

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.

Re: A simple C implementation to stream H.264 to browser using WebRTC

#68

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…

You literally go from thread to thread posting the same pro-Rust anti-C drivel, derailing every thread.

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

#69

Earlier 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.…

I... don't even know how to start answering this.

"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

#70
post #67

Earlier 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.

Yeah, it’s shocking that almost every day I log onto HN and see either (1) security exploits in legacy C code or, (2) new C code being introduced into the world that invites the same exploits to the untrained programmer. The same way people keep repeating the same mistakes, I will keep repeating my criticisms. We’re stuck in an infinite loop.
Post reply on HN