Rust 1.6 released, complete with a stabilised libcore

Re: People are in Denial about C and C++

On one level, you're right. It's hard to get buffer overruns if you use the correct trchniques in C++. But it's easy to use the wrong techniques, as evidenced by the enormous number of overruns in even modern software.

C and C++ need to be put out to pasture.

Re: People are in Denial about C and C++

"it's quite difficult to get a buffer overflow or memory leaks in C++."

It's not hard to get memory leaks - just allocate things and forget to clean them up, or put convoluted ownership rules into the API. Things like shared / scoped points can help a lot, but shared pointers aren't a panacea and come with their own issues, e.g. sometimes objects have to be cleaned in a specific way rather than by the last reference.

Buffer overflows too. I had a buffer overflow occur in a piece of code which was setting a tooltip on a Windows app. The code did a strcpy into the struct without checking the length. Later, when the application was shutting down it would crash because the heap was corrupted. It took days to track down that damned bug. The problem here is that yes C++ has safer classes but it never bothers to deprecate the unsafe ones. It's also quite common for libraries to use their own abstractions so you can't just pass around STL classes.

So to me, a language which has protection built in from the bottom up is a bonus. Every compile error is a potential bug averted at runtime. My biggest fear for rust is that nobody is going to port code from C++ (they might wrap some up, but not port it) so it will have to build up a large body of useful functionality on its own and quickly. I wonder if Rust's future is actually in places that might traditionally use something like Ada.

Rather than fix this insane behaviour

For the usual reason: fixing it would break far too much extant code.

At least the ECMAScript committee acknowledges issues like the language's feeble scoping and is working on extensions to address them.

The thing is, most of the C++11/C++14 additions have simplified syntax.

Compare idomatic loops in C++ 03;

#include<vector>

#include <iostream>

std::vector<int> numbers(0,10);

std::vector<int>::const_iterator begin(numbers.begin());

for(std::vector<int>::const_iterator end(numbers.end()); begin != end; ++begin){

std::cout << " a number " << *begin << "\n";

}

Compare idomatic loops in C++ 11;

#include<vector>

#include <iostream>

std::vector<int> numbers(0,10);

for(const auto & v: numbers){

std::cout << " a number " << v << "\n";

}

Re: interesting, but...

This is just not true.

The difference between secure code and insecure code is testing and auditing, combined with people who understand the tools.

Secure code is not just code that doesn't crash, in a lot of ways a nice segv is a lot better than exposing the information your code was intended to "secure".

It's possible to make any code secure if you have enough time and money to throw at it, once you define security properly, it seems to be largely independent of language/operating system.

Re: interesting, but...

I'd go a step further. Any language where you get to play around with memory directly, rather than just declaring variables and letting the compiler do the bit that humans invariably fuck up at some point, is totally unsuitable as an application development tool.

That sort of language is for bare metal shit only.

No it's not garbage collection but it amounts to automatic resource management

Unless you are trying to solve the A-B-A problem, Garbage collection rather than automatic resource management is less useful in C++.

What is it about pointers that upsets people? Is an ArrayIndexOutOfBoundsBecauseYouCantCountExceptionalException really preferable to sigsegv ?

The C++ conventions are simple. 1) don't allocate memory for buffers, use a contiguous sequence container instead. (vector in C++ 03, vector and std::string in C++11/14).

Allocation/Deallocation/Resizing are handled for you, so you don't need GC.

struct Think {};

// Idiomatically, on the stack so no alloc/hence no free/hence no need for GC

Thing thing;

...

In C++11 it's trivial to grab a chunk of memory and make it impossible to leak.

{ // if you really must allocate this on the free store

std::unique_ptr<Thing> pthing{}; // allocates memory which I cannot leak.

...

// what ever happens here pthing will be cleaned up/.

}

// pthing has been released

You don't need garbage collection with RAII and scoped objects.

Re: IDK. Maybe tools that show programmers why there cherished code idion is dumbass?

"Actually this sort of thing exists in Clang, it will say this is a better ways to do it, and can in some cases rewrite the source code for you. "

My point was that while making it easier to write the next generation of code is good most of the grief is being caused by problems in existing code, which really needs some tools to run over it to find (and maybe fix) issues.

We've seen issues with code that's been open source for twenty years and no one spotted a bug which was likely found by the NSA sometime in the mid 90's.