Date: Sat, 30 Nov 2024 17:39:39 +0000
On Sat, 30 Nov 2024 at 17:30, James via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Well, I can't say anything about being implementation defined or not. What
> I can say is it's currently impossible, so for this to work either standard
> needs to expand or make it implementation defined.
> std::bit_cast creates copies which is not the same thing.
> My main issue with the current state of the language is, you can do these
> things at runtime.
>
What things? You haven't actually given an example of what you're doing at
runtime and want to do at compile-time. Most type punning is not actually
valid C++, although it depends exactly what you mean by type punning.
> I have various constructs that make use of type punning, but I can't use
> any of them at compile time. I need to have an alternative that solves the
> same problem to be able to do it in compile time. Even then behaviour isn't
> exactly the same.
>
> Regarding UB, compilers have all the information about literally anything
> when it's executed at compile time. Compilers are smart, they can handle it.
>
> On Sat, Nov 30, 2024 at 1:45 PM Sebastian Wittmeier via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> The current typeless memory is either
>>
>> - std::byte, char, unsigned char
>>
>>
>>
>> As compile-time evaluation tries to avoid UB nearly completely and also
>> tries to not use any implementation-defined features, there is less room
>> for low-level inspection or modification.
>>
>>
>>
>> There is also constexpr std::bit_cast
>>
>>
>>
>> What usage examples do you have for the typeless_memory, which are not
>> implementation-defined, allow the compiler to check and avoid UB (which
>> e.g. entails an understanding of object lifetimes, types and memory
>> locations) and which cannot be solved with the current tools in the
>> standard library?
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> *Von:* James via Std-Proposals <std-proposals_at_[hidden]>
>> *Gesendet:* Sa 30.11.2024 10:56
>> *Betreff:* [std-proposals] std::typeless_memory (type punning)
>> *An:* std-proposals_at_[hidden];
>> *CC:* James <james.business.84_at_[hidden]>;
>> Currently you can do whatever you want at runtime when it comes to type
>> punning. Sure, all of them might not be safe, but you have some ways to do
>> it safely. However in compile time (as far as I know) there is no way to
>> achieve type punning.
>>
>> So I'd like to see this type, in standard library
>> https://godbolt.org/z/1dEjYW1hW
>>
>> It's only purpose is to allow treating some underlying memory as whatever
>> type you want in compile time without using extra memory. It would also
>> provide a shortcut for runtime usage
>> Currently you can't achieve that due to placement new and
>> reinterpret_cast not being usable in compile time context
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
std-proposals_at_[hidden]> wrote:
> Well, I can't say anything about being implementation defined or not. What
> I can say is it's currently impossible, so for this to work either standard
> needs to expand or make it implementation defined.
> std::bit_cast creates copies which is not the same thing.
> My main issue with the current state of the language is, you can do these
> things at runtime.
>
What things? You haven't actually given an example of what you're doing at
runtime and want to do at compile-time. Most type punning is not actually
valid C++, although it depends exactly what you mean by type punning.
> I have various constructs that make use of type punning, but I can't use
> any of them at compile time. I need to have an alternative that solves the
> same problem to be able to do it in compile time. Even then behaviour isn't
> exactly the same.
>
> Regarding UB, compilers have all the information about literally anything
> when it's executed at compile time. Compilers are smart, they can handle it.
>
> On Sat, Nov 30, 2024 at 1:45 PM Sebastian Wittmeier via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> The current typeless memory is either
>>
>> - std::byte, char, unsigned char
>>
>>
>>
>> As compile-time evaluation tries to avoid UB nearly completely and also
>> tries to not use any implementation-defined features, there is less room
>> for low-level inspection or modification.
>>
>>
>>
>> There is also constexpr std::bit_cast
>>
>>
>>
>> What usage examples do you have for the typeless_memory, which are not
>> implementation-defined, allow the compiler to check and avoid UB (which
>> e.g. entails an understanding of object lifetimes, types and memory
>> locations) and which cannot be solved with the current tools in the
>> standard library?
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> *Von:* James via Std-Proposals <std-proposals_at_[hidden]>
>> *Gesendet:* Sa 30.11.2024 10:56
>> *Betreff:* [std-proposals] std::typeless_memory (type punning)
>> *An:* std-proposals_at_[hidden];
>> *CC:* James <james.business.84_at_[hidden]>;
>> Currently you can do whatever you want at runtime when it comes to type
>> punning. Sure, all of them might not be safe, but you have some ways to do
>> it safely. However in compile time (as far as I know) there is no way to
>> achieve type punning.
>>
>> So I'd like to see this type, in standard library
>> https://godbolt.org/z/1dEjYW1hW
>>
>> It's only purpose is to allow treating some underlying memory as whatever
>> type you want in compile time without using extra memory. It would also
>> provide a shortcut for runtime usage
>> Currently you can't achieve that due to placement new and
>> reinterpret_cast not being usable in compile time context
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2024-11-30 17:40:56