Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C and C++ Aren't Future Proof

blog.regehr.org

Post reply on HN
Print view View original

91–100 of 108 posts

Re: C and C++ Aren't Future Proof

#91

Post by sp332 »

pkaler wrote: post #5

> This propensity for today’s working programs to be broken tomorrow is what I mean when I say these languages are not future proof. It doesn't matter. This is not how programming works in the real world. In the real world, you write the most correct program you can under time pressure. A new compiler, operating system, or platform arrives that exposes a bug. You fix it and you move on. It doesn't matter if the langu…

In the real world, you write the most correct program you can under time pressure. A new compiler, operating system, or platform arrives that exposes a bug. You fix it and you move on. It doesn't matter if the language is future proof or not.

A new compiler, OS or platform will require much less rewriting of a Python program than a C program. Under time pressure, it is much more likely that you will incidentally write future-proof code if you write in Python instead of C.

Re: C and C++ Aren't Future Proof

#92

Post by X4 »

It will exist as long as there are people porting C to other architectures!

C is there since 1972, it is one of the most widely used programming languages of all time and there are very few computer architectures for which a C compiler does not exist. Many later languages have borrowed directly or indirectly from C, including C#, D, Go, Java, JavaScript, Limbo, LPC, Perl, PHP, Python, and Unix's C shell.

Re: C and C++ Aren't Future Proof

#93

Post by zxcdw »

roel_v wrote: post #77
pcwalton wrote: post #63

Earlier quoted context omitted.

Iterators don't protect against iterator invalidation due to e.g. emptying a vector while you iterate over it. Accessing elements through an invalidated iterator is undefined behavior and can lead to exploitable security vulnerabilities. Even modern C++ has very unsafe parts.

You're arguing a straw man here. bcoates is saying, and I agree, that the usual examples being given on how horrible C++ is, are not idiomatic C++ and are used only by people who don't have any experience using C++. Of course it's easy to come up with examples of when things might go wrong. C++ is a powerful language, and with great power comes great responsibility, pardon the pompousness of that phrasing. C++ isn't…

Many times it's the human error which causes the bug/vulnerability to happen rather than sheer ignorance/lack of experience. In such cases a tool which prevents this from happening in the first place is superior to one which doesn't have such a safety feature in it.

For the same reason we can't ever completely prevent traffic accidents by requiring higher skilled drivers. We can prevent traffic accidents by building cars, lanes, junctions and roads in such way which minimizes the damage caused by a human error.

I'll rather use a hammer which refuses to strike to my finger even if I try to make it to, rather than one which I can smash my fingers with by accident. I am sure you would too.

Re: C and C++ Aren't Future Proof

#94

Post by wfox »

PommeDeTerre wrote: post #57
betterunix wrote: post #27

Earlier quoted context omitted.

If people treated C++ as a maintenance-only language and used it only for legacy code -- like COBOL -- the world would be a better place. The world would also save billions of dollars. This is not a matter of RAII or "smart" pointers (which are not even smart enough to deal with cyclic references unless the programmer explicitly breaks the cycle). It is a matter of a language whose high-level features are constrained…

You're ignoring the cost of actually running the applications in question. The benefits of reduced development costs can quickly be negated if performance starts to suffer. We see this a lot with Ruby on Rails web apps, for instance. Perhaps they're quicker to develop in many cases, and maybe they're slightly less vulnerable to certain problems than C or C++ apps are, but they are much less efficient at runtime. This…

Why are you ignoring HotSpot?

Re: C and C++ Aren't Future Proof

#95

Post by kibwen »

zxcdw wrote: post #67
kibwen wrote: post #44

Earlier quoted context omitted.

Can you give some specific examples? I myself have been known to bikeshed with the Rust devs on occasion. :P

Not exactly related to syntax, but one of the issues I've found with following the tutorials is that there is only a handful working programs which actually show the feature in question in use. While I understand that (as the tutorial explicitly mentions) the tutorial is very terse and quick glance at the language features, I feel it could be improved tremendously if there was even one a few line fully compilable pro…

That's a good idea, but it's going to require a bit of thought to implement. It might make sense to have an "advanced examples" external page for every section in the tutorial, which would sort of transform the current tutorial into an annotated table of contents. Which could be really neat! But perhaps it should wait until Rust has some analogue to play.golang.org available.

Re: C and C++ Aren't Future Proof

#96

Post by kibwen »

MBlume wrote: post #69
pcwalton wrote: post #62

Earlier quoted context omitted.

Initializing variables to zero doesn't buy you much in terms of safety, IMHO. The value 0 isn't necessarily any more valid than an arbitrary value. Better is Java/ML/Haskell's rule whereby variables must be explicitly initialized before use. This can be implemented with a simple compiler pass.

Java? Everything (except for built-in types) is nullable in Java...

pcwalton's point is that you must be explicit about initializing variables:

  int foo = 1;
  int bar;
  System.out.println(foo + bar);  // compile error: variable bar might not have been initialized

Re: C and C++ Aren't Future Proof

#97

Post by roel_v »

zxcdw wrote: post #93
roel_v wrote: post #77

Earlier quoted context omitted.

You're arguing a straw man here. bcoates is saying, and I agree, that the usual examples being given on how horrible C++ is, are not idiomatic C++ and are used only by people who don't have any experience using C++. Of course it's easy to come up with examples of when things might go wrong. C++ is a powerful language, and with great power comes great responsibility, pardon the pompousness of that phrasing. C++ isn't…

Many times it's the human error which causes the bug/vulnerability to happen rather than sheer ignorance/lack of experience. In such cases a tool which prevents this from happening in the first place is superior to one which doesn't have such a safety feature in it. For the same reason we can't ever completely prevent traffic accidents by requiring higher skilled drivers. We can prevent traffic accidents by building…

Sure, and that's why I e.g. prefer strong typing for bigger systems. The examples that have been used so far just aren't good examples of what is wrong with C++, which is what the point was about. At some point, there is a trade off between safety and power, and one that makes C++ quite well, IMO.

Re: C and C++ Aren't Future Proof

#98

Post by makomk »

barrkel wrote: post #89
pkaler wrote: post #12

Earlier quoted context omitted.

> His suggestion #3, that the standards should define more of the commonly used behavior and leave less of it undefined, wouldn't even require C programmers to do anything about it themselves. I've written Windows, Mac, Linux, Xbox, PlayStation, PSP, iOS, and Android code. The memory model is subtly different for each platform. I just don't think you can define certain behaviour and have that work across disparate pl…

You underestimate how much undefined behaviour is in typical C programs and how little of it is yet taken advantage of by compilers. The compilers are now starting to fairly radically rewrite the original code in ways the author would not recognize, simply because of some undefined behaviour exists within the code. You need to be increasingly language lawyerly to avoid the compiler outsmarting you, almost as if it wa…

The "hostile opponent" analogy is a good one. C was always intended as a kind of higher-level replacement for assembly, so it was reasonable to assume (for instance) that uninitialized integer variables contain some unspecified but definite value, but recently compilers have been deliberately breaking those assumptions just because they can. It's almost reached the point where C isn't useful for its original purpose of systems programming; it's very hard to write threaded code that doesn't rely on undefined behaviour, for instance.

Re: C and C++ Aren't Future Proof

#99

Post by makomk »

jacobparker wrote: post #47
scott_s wrote: post #40

Earlier quoted context omitted.

But the the author of the original piece is mostly concerned with undefined behavior that can be detected statically - otherwise, compilers would not be able to exploit it to make optimizations.

One thing he mentions is signed integer overflow. This is in the worst case equivalent to the halting problem, but even in practice very hard to test for at compile time. Another behaviour he mentions is not properly return'ing at the end of a non-void function. This is again technically equivalent to the halting problem, but it is negated by the good practice of making every code path (even potentially dead ones) ha…

It can't always be tested for at compiler time but the problem he's complaining about is when C compilers do detect signed integer overflow. What happens is that someone writes code that in practice handles signed integer overflow fine, then a while later the C compiler developers get clever, detect the integer overflow, and decide to optimize that code away because it's invoking undefined behaviour and they can do whatever they like. The code in question is frequently security-critical, so by removing it the compiler converts safe code whose behaviour is technically undefined by the standard into a security vulnerability.

Re: C and C++ Aren't Future Proof

#100

Post by wbl »

roel_v wrote: post #76
zxcdw wrote: post #15

Earlier quoted context omitted.

You should not switch your apps. You should stop creating new projects in C++ once Rust is mature enough for your liking. The fundamental "problem" we're having/facing with C and C++ is the investments we've put in. Lots of "infrastructure" in modern day computing relies on C and C++ and will do so for ages. We can't just drop the projects and switch to something else(say Rust or maybe Go), but we can stop creating n…

How many Rust libraries are there for various tasks? What IDE supports Rust? What tutorials, books and conferences exist that teach and distribute the state of the art in development techniques? What example projects have been build in it to demonstrate its feasibility for large projects? What tools support Rust (continuous integration, code formatting/checking, build tools, ...)?

I'm sure make and git work with Rust like anything else.
Post reply on HN