Um… No, this is not true. One important detail about language-level initialization is that it is not guaranteed to do anything to padding bytes and padding bits that might (and typically will) be present in the target datatype. All these initialization methods leave padding bytes in indeterminate state.

This is OK for purely abstract language-level development, since values of padding bits/bytes are typically invisible at that level.

However, the moment we drop to the level of binary byte-wise reinterpretation of our data, the padding suddenly begins to matter a lot. For example, if you send your object to a binary stream (a network protocol, a zipped file, a simple binary file) this padding begins to affect things in rather drastic and unpredictable ways. This is when you have to remember to keep you padding clean. And that’s where there’s no real alternative to `std::memset`.

What are you talking about? Yes, you CAN “reset” an object by assigning a {} to it, assuming the object supports {} initializer.

foo f{};

// change f

//…

//f = {} // compile fails

fillmem(f);

BTW, I don’t like the default value argument, I would prefer a zero_init function.

I’ve a zero_initializer type that can be used as follows in C++98 for POD structs

foo f = zero_initializer();

This will perform a memset to 0 while doing the conversion from the zero_initializer to the type foo.

#pragma GCC poison seems to work unmodified with clang.

Trying to get a user friendly portable way gets a bit more involved because of macro expanding pragmas and string literals, but at least clang seems to support GCC poison directly, so this worked for me™:

#define PPSTRINGIFY2(X) #X
#define PPSTRINGIFY(X) PPSTRINGIFY2(X)

#if defined(__GNUC__) || defined(__clang__)
#define PRAGMA_POISON(x) _Pragma(PPSTRINGIFY(GCC poison x))
#elif _MSC_VER
#define PRAGMA_POISON(x) __pragma (deprecated(#x))
#endif

PRAGMA_POISON(malloc)

It’s supposed to give a warning instead of error, but treating warnings as errors is pretty good policy anyway. Alternatively you can turn it into an error with #pragma warning(error: 4995)
Or… at least it’s supposed to be a warning, but in my quick test with newest MSVC it apparently throws an error by default.

#include
using namespace std;

int main()
{
const size_t sz = 7;

char str[sz];

memset(str, 2, sz); // This is OK

#define memset()

memset(str, 3, sz); // This fails to compile with too many arguments error because of macro definition

#undef memset

memset(str, 3, sz); // This is OK as macro definition now removed
}

using #define to redefine a name as a macro you want to stop being used so that you get a compiler error

1>c:developvctest12test12test12.cpp(16): warning C4002: too many arguments for function-like macro invocation ‘memset’

In some ways this is better than gcc poison as you can define/undefine the macro as needed in the code whereas as stated above, once poisoned there is no antidote!