5 ms·

> 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

> 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.

pjmlp 11y ago
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.
- JoeAltmaier 11y 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.
  - pjmlp 11y 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.
deleted 11y ago
[deleted]
steveklabnik 11y ago
> So like C++ with unique_ptr, shared_ptr, and RAII? It is like that, but with stronger guarantees and less overhead.
- pmelendez 11y 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?
  - bbatha 11y 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.
    - steveklabnik 11y ago
      Arc<T> vs Rc<T> compared to shared_ptr was what I was going to say for overhead, as well as things like the lack of move constructors, which (should) make Vec<T> faster than std::vec. For stronger guarantees, I was going to point out that if you std::move a uniq_ptr, it becomes null, but Rust prevents using a Box<T> that's been moved at compile time. Your example is good here too.
      - pmelendez 11y ago
        > the lack of move constructors, which (should) make Vec<T> faster than std::vec. So you are saying that the lack of move constructors (hence copying the structure) will make Vec<T> faster than std::vector? I don't follow that logic, wouldn't it actually be slower? > I was going to point out that if you std::move a uniq_ptr, it becomes null The original becames null because the semantic is actually tranfering ownership which might be desirable depending on the case. Also you need it in case you are using custom deleters. http://stackoverflow.com/questions/13860219/what-are-the-differences-between-stdmove-and-unique-ptrreset http://stackoverflow.com/questions/13860219/what-are-the-dif...

pjmlp 11y ago

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.

JoeAltmaier 11y 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.
- pjmlp 11y 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.

deleted 11y ago

[deleted]

steveklabnik 11y ago

> So like C++ with unique_ptr, shared_ptr, and RAII? It is like that, but with stronger guarantees and less overhead.

pmelendez 11y 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?
- bbatha 11y 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.
  - steveklabnik 11y ago
    Arc<T> vs Rc<T> compared to shared_ptr was what I was going to say for overhead, as well as things like the lack of move constructors, which (should) make Vec<T> faster than std::vec. For stronger guarantees, I was going to point out that if you std::move a uniq_ptr, it becomes null, but Rust prevents using a Box<T> that's been moved at compile time. Your example is good here too.
    - pmelendez 11y ago
      > the lack of move constructors, which (should) make Vec<T> faster than std::vec. So you are saying that the lack of move constructors (hence copying the structure) will make Vec<T> faster than std::vector? I don't follow that logic, wouldn't it actually be slower? > I was going to point out that if you std::move a uniq_ptr, it becomes null The original becames null because the semantic is actually tranfering ownership which might be desirable depending on the case. Also you need it in case you are using custom deleters. http://stackoverflow.com/questions/13860219/what-are-the-differences-between-stdmove-and-unique-ptrreset http://stackoverflow.com/questions/13860219/what-are-the-dif...