6 ms·

> full definition of a class Pointers and virtual class, why do you need the definition to use the interface? Could you provide more details? > The basic prob

> full definition of a class Pointers and virtual class, why do you need the definition to use the interface? Could you provide more details? > The basic problem with C++ is that it has heavy encapsulation without memory safety. It's pretty simple to write memory safe code in c++, and encapsulation is a feature that not mandated in c++ code.

adrianN 9y ago
Pointers and virtual classes have runtime overhead. It's not simple to write memory safe code in C++, otherwise we would have a lot fewer vulnerabilities in C++ codebases.
- pjmlp 9y ago
  It is quite simple to write safe C++, when people don't treat the language as if it was a nicer C.
  - adrianN 9y ago
    If it were simple why is approximately nobody managing to do it? Do you think that they don't care?
    - pjmlp 9y ago
      Yep, they just don't care and keep throwing pointers instead references or std::vector/array, #define instead of const, char* instead of std::string and so on. I have been preaching how to write proper C++ code vs "nicer C" since the late 90's, but without much success, specially to enterprise developers. Many of the so called modern C++ features were already possible with C++98. As a good example, MFC 1.0 could have been like Turbo Vision, OWL, VCL, Qt and so on, but the test group from Microsoft found Afx too high level and wanted just a thin layer over Win16 thus it was reborn as MFC.
      - seanwilson 9y ago
        > Yep, they just don't care and keep throwing pointers instead references or std::vector/array, #define instead of const, char* instead of std::string and so on. > I have been preaching how to write proper C++ code vs "nicer C" since the late 90's, but without much success, specially to enterprise developers. In no practical sense is it easy then. Even if you find it easy to write perfect code, you still have to work with other people that don't and use libraries which have problems. C++ has so many ways to shoot yourself in the foot I literally cannot think of a mainstream language that is actually more difficult to master. Would you say it was easy compared to Python, Java or JavaScript to write safe code in? Those languages have no undefined behaviour and they all have automatic memory management compared to C++.
        pjmlp 9y ago
        It is harder yes, and actually nowadays I spend most of my time on Java/.NET, just diving into C++ for system stuff. However, the mechanisms for safer code are there, if one cares to use them in first place. The usual set warnings as errors, CI build with static analyzers that break on failure, unit tests with sanitizers that break on failure. But many companies don't care to set this workflow. They also don't care for doing that for Python, Java or JavaScript as well. JavaScript might have automatic memory management, but it has its own collection of WTF moments and implementation issues across browsers. Java is way better, yet there is a reason why Java Puzzles are so entertaining. While a tracing GC is much more productive than RAII/smart pointers, sometimes you also need to track down those references that prevent the collector to do its job. Android developers have lots of "fun" doing that regarding context and activities. One should not forget that safe languages only get us free from memory corruption, regarding safe code. There is still the whole spectrum of logical errors, specially bad in dynamic languages. In any case, until we finally get a mainstream OS written in Swift, .NET Native, Rust or D, we need to make the best use of our tooling for low level system coding activities and in this regard C++ is so much better than C.
        seanwilson 9y ago
        I agree tools and workflows exist to make it easier to write good C++ code but it's still an order of magnitude harder to do this compared to other languages. I'd only use C++ if there was no other practical choice. It's simply far too much effort to make your code robust.
- _pmf_ 9y ago
  > It's not simple to write memory safe code in C++, otherwise we would have a lot fewer vulnerabilities in C++ codebases. Using the STL after using Java collections or Qt collections is a shock. I think there really needs to be a "Safe STL" in addition to "Performant STL" that performs range checks. You simply cannot recommend using the STL for safe code.
  - signa11 9y ago
    > I think there really needs to be a "Safe STL" in addition to "Performant STL" that performs range checks. indeed. for gcc, you can compile stuff with '-D_GLIBCXX_DEBUG' to enable random-iterator bound checks. moreover, random-access-iterators do have the 'at(...)' stuff available for bounds checked access to the containers. but, yeah, a standardized way would be very useful.
    - pjmlp 9y ago
      Visual C++ on debug mode also enables iterator validation and bounds checking for arrays and strings. It is also possible to explicitly enable them in release code. https://blogs.msdn.microsoft.com/vcblog/2017/06/28/security-features-in-microsoft-visual-c/ https://blogs.msdn.microsoft.com/vcblog/2017/06/28/security-...
  - duneroadrunner 9y ago
    > I think there really needs to be a "Safe STL" in addition to "Performant STL" that performs range checks. SaferCPlusPlus[1] provides compatible, memory-safe versions of the most commonly used STL containers. (The compiler switches mentioned by others add range checking, but do not, for example, catch use-after-free bugs.) > > It's not simple to write memory safe code in C++, otherwise we would have a lot fewer vulnerabilities in C++ codebases. Using SaferCPlusPlus, it now is simple to write memory-safe code in C++. And it's not much different from writing traditional (unsafe) C++ code. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
  - nicwilson 9y ago
    You can't do that with C++'s "3-legged" algorithms. the begin - end - begin triplet is missing the second end.
- zvrba 9y ago
  > otherwise we would have a lot fewer vulnerabilities in C++ codebases. Are you sure you're not referring to _C_ codebases?
  - adrianN 9y ago
    Yes. All the popular browsers are mostly C++ for example.
- sideshowb 9y ago
  > Pointers and virtual classes have runtime overhead. Most popular languages don't allow putting objects on the stack and thus have at least comparable overhead anyway.
- justicezyx 9y ago
  > Pointers and virtual classes have runtime overhead. If you are sensitive to these overhead, you pretty much already only have C++ as your only choice. Or maybe Rust, but I do not know rust well to comment if Rust does not have such overhead. > It's not simple to write memory safe code in C++ No, in C++11 or newer, memory safe code is the default. That's the design goal of the newer standards of C++. IMHO, memory safety is no longer a central issue for C++. > a lot fewer vulnerabilities in C++ codebases. This only applies to legacy code.
  - steveklabnik 9y ago
    Rust doesn't have classes, and therefore doesn't have virtual classes. So it ends up being different. Dynamic dispatch is used pretty rarely in Rust. If you want dynamic dispatch, you don't use a virtual class, you use a "trait object". Basically it's a double pointer: a (pointer to vtable, pointer to data). Technically the C++ standard (as far as I know) doesn't define the exact implementation of this stuff, but in my understanding the vtable pointer is stored with the data. There are pros and cons to each approach.
    - justicezyx 9y ago
      > If you want dynamic dispatch, you don't use a virtual class, you use a "trait object". Is this referring to Rust? Then it sounds like it will have similar overhead as C++'s virtual functions.
      - steveklabnik 9y ago
        Yes, it is, and yes, it does. There are small differences due to the stuff I said above, but it's similar.

adrianN 9y ago

Pointers and virtual classes have runtime overhead. It's not simple to write memory safe code in C++, otherwise we would have a lot fewer vulnerabilities in C++ codebases.

pjmlp 9y ago
It is quite simple to write safe C++, when people don't treat the language as if it was a nicer C.
- adrianN 9y ago
  If it were simple why is approximately nobody managing to do it? Do you think that they don't care?
  - pjmlp 9y ago
    Yep, they just don't care and keep throwing pointers instead references or std::vector/array, #define instead of const, char* instead of std::string and so on. I have been preaching how to write proper C++ code vs "nicer C" since the late 90's, but without much success, specially to enterprise developers. Many of the so called modern C++ features were already possible with C++98. As a good example, MFC 1.0 could have been like Turbo Vision, OWL, VCL, Qt and so on, but the test group from Microsoft found Afx too high level and wanted just a thin layer over Win16 thus it was reborn as MFC.
    - seanwilson 9y ago
      > Yep, they just don't care and keep throwing pointers instead references or std::vector/array, #define instead of const, char* instead of std::string and so on. > I have been preaching how to write proper C++ code vs "nicer C" since the late 90's, but without much success, specially to enterprise developers. In no practical sense is it easy then. Even if you find it easy to write perfect code, you still have to work with other people that don't and use libraries which have problems. C++ has so many ways to shoot yourself in the foot I literally cannot think of a mainstream language that is actually more difficult to master. Would you say it was easy compared to Python, Java or JavaScript to write safe code in? Those languages have no undefined behaviour and they all have automatic memory management compared to C++.
      - pjmlp 9y ago
        It is harder yes, and actually nowadays I spend most of my time on Java/.NET, just diving into C++ for system stuff. However, the mechanisms for safer code are there, if one cares to use them in first place. The usual set warnings as errors, CI build with static analyzers that break on failure, unit tests with sanitizers that break on failure. But many companies don't care to set this workflow. They also don't care for doing that for Python, Java or JavaScript as well. JavaScript might have automatic memory management, but it has its own collection of WTF moments and implementation issues across browsers. Java is way better, yet there is a reason why Java Puzzles are so entertaining. While a tracing GC is much more productive than RAII/smart pointers, sometimes you also need to track down those references that prevent the collector to do its job. Android developers have lots of "fun" doing that regarding context and activities. One should not forget that safe languages only get us free from memory corruption, regarding safe code. There is still the whole spectrum of logical errors, specially bad in dynamic languages. In any case, until we finally get a mainstream OS written in Swift, .NET Native, Rust or D, we need to make the best use of our tooling for low level system coding activities and in this regard C++ is so much better than C.
        seanwilson 9y ago
        I agree tools and workflows exist to make it easier to write good C++ code but it's still an order of magnitude harder to do this compared to other languages. I'd only use C++ if there was no other practical choice. It's simply far too much effort to make your code robust.
_pmf_ 9y ago
> It's not simple to write memory safe code in C++, otherwise we would have a lot fewer vulnerabilities in C++ codebases. Using the STL after using Java collections or Qt collections is a shock. I think there really needs to be a "Safe STL" in addition to "Performant STL" that performs range checks. You simply cannot recommend using the STL for safe code.
- signa11 9y ago
  > I think there really needs to be a "Safe STL" in addition to "Performant STL" that performs range checks. indeed. for gcc, you can compile stuff with '-D_GLIBCXX_DEBUG' to enable random-iterator bound checks. moreover, random-access-iterators do have the 'at(...)' stuff available for bounds checked access to the containers. but, yeah, a standardized way would be very useful.
  - pjmlp 9y ago
    Visual C++ on debug mode also enables iterator validation and bounds checking for arrays and strings. It is also possible to explicitly enable them in release code. https://blogs.msdn.microsoft.com/vcblog/2017/06/28/security-features-in-microsoft-visual-c/ https://blogs.msdn.microsoft.com/vcblog/2017/06/28/security-...
- duneroadrunner 9y ago
  > I think there really needs to be a "Safe STL" in addition to "Performant STL" that performs range checks. SaferCPlusPlus[1] provides compatible, memory-safe versions of the most commonly used STL containers. (The compiler switches mentioned by others add range checking, but do not, for example, catch use-after-free bugs.) > > It's not simple to write memory safe code in C++, otherwise we would have a lot fewer vulnerabilities in C++ codebases. Using SaferCPlusPlus, it now is simple to write memory-safe code in C++. And it's not much different from writing traditional (unsafe) C++ code. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
- nicwilson 9y ago
  You can't do that with C++'s "3-legged" algorithms. the begin - end - begin triplet is missing the second end.
zvrba 9y ago
> otherwise we would have a lot fewer vulnerabilities in C++ codebases. Are you sure you're not referring to _C_ codebases?
- adrianN 9y ago
  Yes. All the popular browsers are mostly C++ for example.
sideshowb 9y ago
> Pointers and virtual classes have runtime overhead. Most popular languages don't allow putting objects on the stack and thus have at least comparable overhead anyway.
justicezyx 9y ago
> Pointers and virtual classes have runtime overhead. If you are sensitive to these overhead, you pretty much already only have C++ as your only choice. Or maybe Rust, but I do not know rust well to comment if Rust does not have such overhead. > It's not simple to write memory safe code in C++ No, in C++11 or newer, memory safe code is the default. That's the design goal of the newer standards of C++. IMHO, memory safety is no longer a central issue for C++. > a lot fewer vulnerabilities in C++ codebases. This only applies to legacy code.
- steveklabnik 9y ago
  Rust doesn't have classes, and therefore doesn't have virtual classes. So it ends up being different. Dynamic dispatch is used pretty rarely in Rust. If you want dynamic dispatch, you don't use a virtual class, you use a "trait object". Basically it's a double pointer: a (pointer to vtable, pointer to data). Technically the C++ standard (as far as I know) doesn't define the exact implementation of this stuff, but in my understanding the vtable pointer is stored with the data. There are pros and cons to each approach.
  - justicezyx 9y ago
    > If you want dynamic dispatch, you don't use a virtual class, you use a "trait object". Is this referring to Rust? Then it sounds like it will have similar overhead as C++'s virtual functions.
    - steveklabnik 9y ago
      Yes, it is, and yes, it does. There are small differences due to the stuff I said above, but it's similar.