--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/afbaf79e-305d-4408-98ab-5b35cfb11f27%40isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya_VWQUMYGGd9tYy_cJWiwvsyUF2joMuCMPsPy%3DT6e15XA%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/14dc989b-7a2f-478b-b16e-b9297fb1782f%40isocpp.org.
On 28 Nov 2016 22:50, "Peet Nick" <peet...@gmail.com> wrote:
>
> Ah, I understand. Although I understand this now, I am not entirely sure how it will be actually implemented. How would someone implement bit_cast as a constexpr without having std::memcpy constexpr?
They'd have to use a compiler intrinsic; according to [1] llvm already has a suitable opcode, so the other compilers would have to do the same, if they don't have an appropriate intrinsic available already.
Remember, it's fine for library functions to need compiler magic to implement; part of the job of the standard library is to provide standardized interfaces to such magic.
1. http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0476r0.html
>> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/14dc989b-7a2f-478b-b16e-b9297fb1782f%40isocpp.org.
>
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/6tkocdbwVGU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJwqTS_OGEOUiUE6rSRrREV6Yx9%2B4Sj5gA8CDHeYgXnPwErW6Q%40mail.gmail.com.
On 28 Nov 2016 22:50, "Peet Nick" <peet...@gmail.com> wrote:
>
> Ah, I understand. Although I understand this now, I am not entirely sure how it will be actually implemented. How would someone implement bit_cast as a constexpr without having std::memcpy constexpr?They'd have to use a compiler intrinsic; according to [1] llvm already has a suitable opcode,
>> To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
>>
>> To post to this group, send email to std-pr...@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/14dc989b-7a2f-478b-b16e-b9297fb1782f%40isocpp.org.
>
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/6tkocdbwVGU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJwqTS_OGEOUiUE6rSRrREV6Yx9%2B4Sj5gA8CDHeYgXnPwErW6Q%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaJRPtdnHPX0%3DL89Pip2GC90aXrEYtJdUYxaHw1vwNJ%3Dw%40mail.gmail.com.
On 28 November 2016 at 15:00, 'Edward Catmur' via ISO C++ Standard - Future Proposals <std-pr...@isocpp.org> wrote:On 28 Nov 2016 22:50, "Peet Nick" <peet...@gmail.com> wrote:
>
> Ah, I understand. Although I understand this now, I am not entirely sure how it will be actually implemented. How would someone implement bit_cast as a constexpr without having std::memcpy constexpr?They'd have to use a compiler intrinsic; according to [1] llvm already has a suitable opcode,
That doesn't help at all. Constant expression evaluation happens at a completely different layer from LLVM.memcpy is fundamentally not possible to support in general within constant expression evaluation; consider:int n;constexpr int *p = &n; // okconstexpr intptr_t q = bit_cast<intptr_t>(p); // ok?static_assert(q > 0x1234567); // ok?!
Clearly this example must be ill-formed. But either that means you can't do the bit_cast in a constant expression or that you can evaluate an integer as part of a constant expression that you then can't do basic integer operations on.
This is precisely why `bit_cast` is a good thing. Because it's a function which knows both the source and destination types, we would be able to say that it is `constexpr` when doing certain conversions and not `constexpr` when doing others. For example, any conversion of a pointer to anything other than a pointer would not be `constexpr`. This would include within various types, so you couldn't have a `struct{int *p};` that you `bit_cast` to a `struct{intptr_t q};`.
The OP asked specifically about converting integers to their bit-representation to do hashing and so forth. `bit_cast` could be `constexpr` for such operations.
So there's no problem.