undefined | Better HN

0 pointscarlosrg10y ago0 comments

> But we also have to acknowledge that we as a profession are not able to write secure code in C/C++.

Wrong. You can write perfectly safe code in C++. You seem to have this ridiculous idea that pointer arithmetic is mandatory on C++. "Pointer arithmetic" is not a feature of C++. It's a feature of how computers work. C++ allows you to do it if you want. Memory pools are not a C++ feature, memory pools are part of how a modern computer and OS works. You know, memory doesn't appear magically in your program.

> Rust forces programmers to indicate ownership and lifetime of memory

So like C++ with unique_ptr, shared_ptr, and RAII?

Also I wanted to say that some of you keep mixing C and C++, calling them "C/C++". They're two different languages.

0 comments

6 comments · 2 top-level

pjmlp10y ago· 2 in thread

I like C++ and dislike its C foundation.

Always written C++ taking advantage of the language features that allow for safer code and bring it closer to Ada linage than C.

Never saw anyone else doing the same in the enterprise codebases I worked on. My team at CERN was the only exception.

JoeAltmaier10y ago

You can even write C++ without linking the runtime, to avoid all that unsafe legacy code. For drivers and such. Done it many times.

pjmlp10y ago

Yes, that is why I find it good that both Mac OS X and Windows allow for kernel code in C++ as a kind of "worse is better" improvement over plain C.

However C++ with teams that haven't drink the safety kool aid, becomes C with a C++ compiler quite fast.

Hence why nowadays I tend to only use it occasionally in side projects.

steveklabnik10y ago· 2 in thread

  > So like C++ with unique_ptr, shared_ptr, and RAII?

It is like that, but with stronger guarantees and less overhead.

pmelendez10y ago

> It is like that, but with stronger guarantees and less overhead.

Smart pointers in C++ are very slim, which overhead are you referring to? And which are the stronger guarantees?

bbatha10y ago

shared_ptr uses an atomic counter. In rust you can choose to use an atomic ref count or not. The type system is sufficiently smart to ensure that you do not use the non-atomic one in a thread unsafe context. C++ has no ability to do so, so it does not provide a thread unsafe version.

Additionally, in C++ there's nothing stopping me from wrapping a unique_ptr around a pointer that's aliased else where. This violates the guarantees of a unique_ptr and forces the user to make sure its invariants are held. In Rust the compiler ensures that your Box (Rust's unique_ptr) can never be owned more than once.

2 more replies

j / k navigate · click thread line to collapse