obliterate

[Vladimir Panteleev]

On Wednesday, 13 November 2013 at 00:33:17 UTC, Andrei 
Alexandrescu wrote:
> For starters, I want to define a function that "obliterates" an 
> object, i.e. makes it almost surely unusable and not obeying 
> its own invariants. At the same time, that state should be 
> entirely reproducible and memory-safe.

What's this for? When will it be used?

How will it behave in release mode? No-op, or same as non-release?

> Here's what I'm thinking. First, obliterate calls the 
> destructor if present and then writes the fields as follows:
>
> * unsigned integers: t.max / 2
>
> * signed integers: t.min / 2
>
> * characters: ?

Why not 0xFF? (char.init, invalid UTF-8 code unit)

> * Pointers and class references: size_t.max - 65_535, i.e. 64K 
> below the upper memory limit. On all systems I know it can be 
> safely assumed that that area will cause GPF when accessed.

Make that value odd. That will also guarantee a GPF on systems 
where unaligned pointer access is forbidden.

> * Arrays: some weird length (like 17), and also starting at 
> size_t.max minus the memory occupied by the array.

I guess the non-zero length is for code which is going to check 
it? Because otherwise, leaving length as just 0 will, in debug 
mode, cause a range error. In release mode, array index access 
will not check the length anyway.

> * floating point numbers: NaN, or some ridiculous value like 
> F.max / 2?

NaNs are viral, so there's that.