The beauty and simplicity of the good old C-style void* in C++

# How to Declare a C++ Function that Takes a Blob of Memory? Source: [https://giodicanio.com/2026/06/05/how-to-declare-a-c-plus-plus-function-that-takes-a-blob-of-memory/](https://giodicanio.com/2026/06/05/how-to-declare-a-c-plus-plus-function-that-takes-a-blob-of-memory/) Discussing several options, starting from the good old C\-style void\* pointer\. 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](https://learn.microsoft.com/en-us/cpp/code-quality/using-sal-annotations-to-reduce-c-cpp-code-defects?view=msvc-170)\.