Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Programming Language to Replace C++

Name: Anonymous 2010-08-11 21:49

I think we can all agree that C++ is a terrible language. So why is it still around?

When talking to most C++ users (game developers, systems programmers), I've found that most seem to recognize C++'s faults, but they don't really care. They aren't even the slightest bit interested in a new language that might solve its problems, even one that gives them all the power of C++ with none of the downsides. You can't even get them to look at something new.

Why is that? Why does everyone just 'live with it' without wanting to improve the situation?

Name: Anonymous 2010-08-13 10:55

>>43
My only argument is that some allocations would require refactoring to deal with outside of GC, which is able to handle runtime non-deterministic de/allocations which outlive their creation context.
Correct. This is not most allocations however. I don't think it's even close to most. But of course I have no data to back up this claim, since this hypothetical language does not exist.

Anything that can be solved simply by annotating could probably be handled by the compiler, couldn't it?
No. Manually freeing memory inherently creates unsafe code. You have to figure out what the lifetime of your object needs to be in order to ensure that it is not accessed through old references after it has been freed. It is impossible for a compiler to solve this in the general case; the ol' halting problem and all that. That's why GCs are so ubiquitous in modern languages: they allow you to statically prove that memory is never accessed after it is freed.

I would go the other way and say that 99% of the automatically inserted checks, barring this kind of optimization, are provably unnecessary.
The compile does not automatically insert any checks whatsoever. That is not what a static type system and static analysis system does. The compiler only forces YOU to MANUALLY add checks in places where you need to verify that a pointer isn't null.

These should be few and far between. I think you have misunderstood my 99%: I meant you would be adding it anyway in 99% of places where the compiler would force you to do it; of course not 99% of places where you dereference a pointer!

Your point about a program analyser is not relevant. No whole-program analyser is needed for this. Each function can be compiled individually, in a vacuum, separate from all the others; it only needs to be properly typed based on whether it accepts null. Nice is a variant of Java which does this: if a function argument might be null, you just prepend a question mark on the type of the variable. If you do this, the function needs to check that it is not null before dereferencing it. If you do not, then the responsibility falls on the caller, so you don't need any checks; the compiler will prove for you that it will not be null. This is a syntactically convenient special case of tagged unions from more powerful languages.

Honestly it's pretty mind boggling to me that you are defending null pointers. It's the famed "billion dollar mistake". I can't help but feel that you aren't properly understanding the issue. Maybe I'm the one who isn't understanding the issue.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List