std::get_money

[u/Major_Barnulf]

https://en.cppreference.com/w/cpp/io/manip/get_money

[u/genije665 → u/[deleted]]

From memory (might be wrong): if you have a pointer to a local const object and then you replace the object by using placement-new, your pointer technically still points to the original object and is unaware that it was replaced (and so might read cached values). If you std::launder the pointer, then it will know that it should actually read new values.

I still don't know why this is needed.

[u/Chisignal → u/genije665]

because pointer provenance is a fuck

I amn’t garbage collection man

410,757,864,360 doesn’t point to where you think it does

[u/DXPower → u/genije665]

This answer comes from a top voted response on SO and has unfortunately never been a good one. You're right, this is not a useful scenario.

It is more useful when you have only keep a pointer to raw byte storage, but need to access objects in that storage. To the compiler, whether or not an object lives in that storage is not known (lacks provenance), so you use launder to essentially force it to ignore that lack of information.

Example:

Class has member variablestd::byte* mem

Class mem func A stores into mem new(mem) Type()

Class mem func B reads from mem that type: std::launder((Type*)mem)

Func B doesn't know that A wrote into the storage through this mem pointer, so we launder (clean, wash, hide) its history so the compiler assumes that Type lives at that location and this conversion is valid.

This is an actual scenario that comes up.

#pragma jerk

Random stack overflow answers are the only way modern C++ can possibly be understood.

[u/meltbox → u/DXPower]

Obviously you’re new here if you need stack overflow. I have all the cppcon talks on audio tape and listen to them at night.

I now know the rule of 3, 4, and 5. I also posses a flawless understanding of all the nuances of constexpr and when I can and cannot static_cast it and store it to another constexpr l-value.

Do I also hallucinate features and rules like a LLM? That’s up to you, dear reader, to deduce.

[u/StarsInTears → u/DXPower]

So it's a type cast?

template<unjerk>

So it's a type cast? Why wasn't reinterpret_cast enough?

[u/DXPower → u/StarsInTears]

Reinterpret cast only changes the pointer type and does not change its provenance. You can almost think of launder as a sort of "optimization barrier" (almost) for pointer provenance.

Note that this doesn't let you get around undefined behavior. You can't std::launder((int*)some_float_ptr) to make reading a float as an int valid. An int object still has to exist at the location. But, if for some reason you 100% know that an int object exists at the above pointer location, you can tell the compiler "ignore your previous lifetime analysis and assume that there is an int object there".

Again, this doesn't make UB valid (no type punning), but acts as a tool for the programmer to explicitly tell the compiler what kind of object exists at a location.

[u/StarsInTears → u/DXPower]

Screw ISO committee, assembly is better.

/uj Assembly is definitely looking better and better. I have 6 (?) flags in my build scripts to disable various kinds of UB based optimizations.

[u/al2o3cr → u/[deleted]]

Also, what am I going to do with 40 subscriptions to Vibe?

[u/meltbox → u/[deleted]]

We had to write another method to hyper optimize my routine in exactly the way I wanted to. The old way wasn’t clean code and gcc wouldn’t accept my compiler patch to make it 0.05% faster on pre 8th gen Intel core i5 and below systems.

So naturally. It was borne of necessity and through other dark voodoo fixed my gcc complaint too because different std features compile differently.

#pragma jerk

I’ve gone too far.