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.

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

> 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

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

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

> Using the STL after using Java collections or Qt collections is a shock.

Why?

I prefer having a free-standing generic find function as opposed to it being implemented in each and every container. Even better example: copy. You can use it with containers, but also with input/output streams (using stream iterators).

You mentioned safety, is iterator invalidation bothering you?

You can't do that with C++'s "3-legged" algorithms. the begin - end - begin triplet is missing the second end.

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

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

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.

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

Yes, it is, and yes, it does. There are small differences due to the stuff I said above, but it's similar.

It is quite simple to write safe C++, when people don't treat the language as if it was a nicer C.

If it were simple why is approximately nobody managing to do it? Do you think that they don't care?

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.

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

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.

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.

So what is your alternative when you need C++ like features for systems coding, C?!

Because as much as I would like to use a safer alternative like Swift, D or Rust, as an ex-Pascal/Oberon user, they aren't there yet.

There is always Ada if newer languages are not there yet for your application.

Ada is only a solution if it can fulfill the project requirements regarding the libraries, tooling, supported CPUs, OSes and IDEs.

Sure. But now you're retreating to a rather small set of applications. Ada has nice tooling and supports a pretty large number of platforms. I don't think you'll find many niches where not one of Rust, D, Swift, Ada, Java, Go, or the dozens of other memory safe(r) languages could do the job and only C or C++ are adequate.

Practical example, we use C++ as systems language for projects done in Java (Standard, Android), .NET (WPF, UWP, Xamarin), Swift/Objective-C (iOS).

There isn't much Ada tooling available for those environments, and even using GNAT would be increasing project costs regarding having to implement ourselves stuff that we get for free with the SDK tools that support C++ out of the box.

> Many of the so called modern C++ features were already possible with C++98.

exactly! C++11 only made it more pleasant to write.

> otherwise we would have a lot fewer vulnerabilities in C++ codebases.

Are you sure you're not referring to _C_ codebases?

Yes. All the popular browsers are mostly C++ for example.