User: Password:
|
|
Subscribe / Log in / New account

Looks useful...

Looks useful...

Posted Mar 13, 2013 12:09 UTC (Wed) by HelloWorld (guest, #56129)
In reply to: Looks useful... by shmerl
Parent article: Jitsi 2.0 released

Using a language that isn't memory-safe for an application that will face the internet is madness. It's a good thing the Jitsi developers didn't.


(Log in to post comments)

Looks useful...

Posted Mar 13, 2013 13:54 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> Using a language that isn't memory-safe for an application that will face the internet is madness.

Oh, no! Let's rewrite the kernel then. C certainly isn't "memory-safe". At least C++ has smart pointers, but since we're starting from scratch, let's write it in Haskell.

But if that's your argument, I argue that any application written in Java probably shouldn't be network-facing these days either…

Looks useful...

Posted Mar 13, 2013 17:03 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> Oh, no! Let's rewrite the kernel then.
A good idea. Microsoft is looking in that direction (see: Singularity, Midori).

Of course, right now it's not (yet) feasible because of the sheer size and complexity of Linux.

Looks useful...

Posted Mar 16, 2013 1:10 UTC (Sat) by HelloWorld (guest, #56129) [Link]

> Oh, no! Let's rewrite the kernel then.
The kernel is a prime example of what I'm talking about. There have been so many vulnerabilities that they don't even bother to document them any longer.
And of course it's impossible to rewrite it in a safer language simply due to the amount of work that has gone into it, so we'll have to live with that. But that doesn't mean we should be making the same old mistakes again and again.

Looks useful...

Posted Mar 13, 2013 17:33 UTC (Wed) by codewiz (subscriber, #63050) [Link]

> Using a language that isn't memory-safe for an application that will > face the internet is madness.

Modern C++ programming style isn't as prone to buffer overruns as old-school C was. Containers manage their own memory and expose a relatively safe API. Over the years, C++ has become quite a safe AND efficient language, albeit very hard to learn.

With the advent of smart pointers and RAII, you rarely need to explicitly free memory or close a file. In fact, the worse resource leaks I've seen in the last few years came from dangling references and missing close() calls in dynamic languages.

Looks useful...

Posted Mar 16, 2013 0:58 UTC (Sat) by HelloWorld (guest, #56129) [Link]

> Modern C++ programming style isn't as prone to buffer overruns as old-school C was. Containers manage their own memory and expose a relatively safe API.
STL containers do *not* offer a safe API. Iterators are at the core of the STL, and they expose a completely unsafe API. If you ever use them wrong, they'll invoke undefined behaviour; contrast that with a Java-style approach where iterators throw exceptions when you fail to use them correctly. Heck, the semantics of a std::vector<T>::iterator were deliberately designed so that a typedef to T* is a valid implementation. And what's worse is that while unsafe iterator implementations are fast, it's essentially impossible to implement them safely without a major performance cost.

I'd still much rather write an application in C++ than in C, simply because it's so much more expressive. But it's not really any safer. Unless I have very high performance requirements, I'll avoid C++ if at all possible (and C even more so).


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds