On Mar 3, 2014, at 8:44 PM, Nathan Myers <n...@cantrip.org> wrote:
> On 03/03/2014 07:46 PM, comex wrote:
>> On Mon, Mar 3, 2014 at 10:17 PM, Nathan Myers <n...@cantrip.org> wrote:
>>> It's clear that we need someone fully competent in C++ to
>>> code any comparisons. In C++, one is only ever motivated to
>>> ("unsafely") extract the raw pointer from a smart pointer when
>>> only a raw pointer will do. This is exactly as likely to happen
>>> in Rust as in C++, and in exactly the same places. Where it is
>>> needed, Rust offers no safer alternative.
>>
>> This is simply wrong.
>
> I assume you take issue not with the leading sentence above,
> but with those following.
>
> > Most C++ code I've seen frequently uses raw
>> pointers in order to pass around temporary references to objects that
>> are not reference counted (or even objects that are reference counted,
>> to avoid the overhead for simple copies). ...
>
> For temporary references in C++ code, I prefer to use references. But
> we do need actual raw pointers to managed (sub)objects as arguments to
> foreign C functions. There, C++ and Rust coders are in the same boat.
> Both depend on the C function not to keep a copy of the unsafely-issued
> borrowed pointer. C++ does allow a reference to last longer than the
> referent, and that's worth calling attention to.
>
>> In Rust, many of the situations where C++ uses raw pointers allow use
>> of borrowed pointers, which are safe and have no overhead.
>
> There are certainly cases in either language where nothing but a
> pointer will do. The problem here is to present examples that are
> simple enough for presentation, not contrived, and where Rust has
> the clear advantage in safety and (ideally) clarity. For such examples
> I'm going to insist on a competent C++ coder if we are not to drive
> away our best potential converts.You seem to be arguing that C++ written correctly by a highly-skilled C++ coder is just as good as Rust code, and therefore the inherent safety of Rust does not give it an advantage over C++. And that's ridiculous. Yes, it's certainly possible to write safe C++ code, and properly sticking to things like shared_ptr and unique_ptr make that easier. But it still relies on you doing the right thing 100% of the time, and never making a mistake and never trying to take a shortcut. Recently I've had the pleasure of dealing with a relatively new C++ codebase (that unfortunately is stuck in C++98 due to Windows support), written by competent C++ programmers. And it has memory bugs. Not only have I already identified multiple memory leaks caused by unclear ownership semantics, but even now there's a subtle memory corruption bug that causes my app to crash on launch once every few days. I have no idea what it is, and I don't think it's going to get sorted out until someone takes valgrind to the code. But what I am sure is that, in the absence of `unsafe`, Rust would have prevented the crash and prevented the memory leaks that I've identified. And if we allow for using `unsafe`, that dramatically cuts down on the amount of code that needs to be vetted for safety. So yes, it's possible to write C++ code that's just as safe as Rust, but it's significantly harder, and errors are much harder to catch. -Kevin
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
