Category: C++ Programming

This is an interesting question, with not an easy answer.

I would say that the correct answer is: “It depends.”

Modern C++ started with C++11. I think C++11 is the most impactful version of C++ to date, as it introduced very important and convenient features like: range-for loops, lambdas, move semantics, standard smart pointers like std::unique_ptr and std::shared_ptr, etc.

C++14 was kind of a small improvement for things that didn’t make it into C++11. For example, C++11 had std::make_shared for std::shared_ptr, but it clearly lacked the corresponding std::make_unique for std::unique_ptr. Well, std::make_unique (and other small features, like supporting auto in lambda parameters) were added in C++14.

Then it came C++17. Again, no big new features here, at least not at the C++11 impact level, but some convenient stuff, like: attributes (e.g. [[nodiscard]], [[fallthrough]], or [[maybe_unused]]); static_assert with no messages (a.k.a. terse static_assert); structured bindings, which come in handy in some cases like when iterating through containers like std::map; new standard library components like std::variant, etc.

Some library features that were previously deprecated were definitively removed in C++17; so that could break some existing legacy C++ code that previously compiled just fine in your projects.

And this brings an important point when picking the C++ version for your codebase: Does using C++ version X > Y break existing code? Is it compatible with older legacy libraries that you don’t want to or cannot upgrade or fix? Does it break some binary compatibility interface (ABI)¹? Is it supported by your toolchain(s)?

For example, if you want to target Windows XP with Microsoft Visual C++ compiler, the latest toolset that has Windows XP support is v141_xp, which is a toolset from Visual Studio 2017², having full C++14 support, and partial C++17 support (for example, you can use features like terse static_assert and std::variant from C++17, but not other features like std::shared_mutex).³

In general, I would say that these days targeting C++17 is fine, and if your toolset supports C++20, and if it doesn’t break any existing library or legacy component you depend on (and you don’t want to/are unable to fix), then C++20 can be a good choice, too.

Keep in mind that today in 2026 (August 18th, 2026), Google’s C++ Style Guide still targets C++20⁴, and LLVM C++17.

Note also that targeting a given C++ version, like C++20, does not mean that you have to use all the features available in that language version!

For example, talking about the C++20 adoption by Google’s C++ Style Guide, it’s worth noting that, the main “Big Three Features” of C++20, i.e. concepts, modules, and coroutines, are used sparingly, or not used at all!

For example, on concepts:

Use concepts sparingly.

And on coroutines:

Use only coroutine libraries that have been approved for project-wide use by your project leads. Do not roll your own promise or awaitable types.

Moreover, on C++20 modules:

Do not use C++20 Modules.

Remember that, at the end of the day, the key is to write code that is clear, easy to read, understand and maintain, and not some mess of esotheric advanced features that make it impossible or very hard to understand what’s going on, or unstable features not well supported by the available toolsets.

1. See for example the C++20 [[no_unique_address]] problem with MSVC. ↩︎
2. It comes with Visual Studio 2019, too. ↩︎
3. You can read more about that in this StackOverflow answer. ↩︎
4. Despite reading: “The C++ version targeted by this guide will advance (aggressively) over time.” (emphasis mine), they are not even targeting C++23 in (at least mid August) 2026. ↩︎

An interesting question you may ask in C++ is: “How would you declare a function that takes a blob of memory as input?”

For example, think of a function that hashes some input data (using SHA-256, or whatever hash algorithm), or a function that takes some binary data and writes that to disk.

Coming from my C background, an option that came to mind would certainly be:

void DoSomething(const void* p, size_t numBytes)

You simply pass a const void* pointer to the beginning of the input memory block, and the total size of the memory block, expressed in bytes.

Then, some C++ programmer could start complaining: “Hey, why do you use the unsafe old C-style void* pointer? Use some safe explicit type like uint8_t, which clearly represents an 8-bit byte!”.

So, they propose to “step up” to the following prototype:

void DoSomething(const uint8_t* p, size_t numBytes)

Now, suppose that you want to pass to this function a custom structure, like this:

struct MyCustomData {
    ...
};

MyCustomData data;

With the original void* version, you can invoke the function simply and clearly like this:

DoSomething(&data, sizeof(data));

The code is very clear and straightforward: you pass a pointer to the custom data structure, and its size in bytes. That’s it. Simple and clear.

On the other hand, with the “safe and modern” uint8_t prototype, the function call gets more complicated, as you need to add a type cast:

// void DoSomething(const uint8_t* p, size_t numBytes)
//
// DoSomething(&data, sizeof(data));
//
// This gives a compiler error when the function expects 
// a const uint8_t* instead of const void*, something like:
//
// Error: cannot convert 'MyCustomData*' to 'const uint8_t*'
//
// You need an explicit cast in this case!
DoSomething(
    reinterpret_cast<const uint8_t*>(&data), 
    sizeof(data)
);

Why should people complexify and uglify their C++ code with the uint8_t pointer (or std::byte), when void* works just fine??

Moreover, someone could even say: “Hey, in modern C++20, we have std::span! Use it!”

Well, congratulations for rising the complexity and noise of the code even further!

In fact, std::span is a class template, and somebody would suggest to make the function that processes the generic memory blob a function template! Really? Something like this??

template <typename T>
void DoSomething(std::span<T> data)

Or maybe something even more complicated, like this?

template <typename T, std::size_t N>
void DoSomething(std::span<T, N> data)

// Or this?
template <typename T, std::size_t N>
void DoSomething(std::span<const T, N> data)

Wow. With std::span the complexity-meter bumps in the red zone and goes even higher!

Someone may suggest something like a std::span<const uint8_t>? But that’s still more complex than the initial void* signature.

Do you want a pointer to a generic memory blob? C++ has already if from C: it’s called void*! Use it and enjoy.

I really dislike this attitude of some “modern” C++ programmers, that make choices that have the effect of making the code more complex, uglier and harder to write and understand.

It seems that some people are really losing the taste for good readable code.

Some good old habit from C can still be positively used in C++, like the void* pointer and the size parameters.

BTW: As a nice addition, if you use SAL annotations, the function could be decorated a bit to help code analyzers detecting memory bugs:

void DoSomething(
  _In_reads_bytes_(numBytes) const void * p,
  _In_ size_t numBytes
);

The _In_reads_bytes_ annotation applied to the pointer parameter explicitly states that the pointer points to input read-only memory (_In_reads_), and the size of this input buffer expressed in bytes (_bytes_) is represented by the numBytes parameter.

In this way, we still keep the clarity and simplicity of the function invocation:

DoSomething(&data, sizeof(data));

while also adding pieces of information that are helpful to spot memory bugs with code analyzers and other tools.

If you want to learn more about SAL annotations, you can start reading this MSDN documentation: Using SAL Annotations to Reduce C/C++ Code Defects.