[PATCH] D20719: Remove use of is_trivially_constructible.

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Thu May 26 22:52:07 PDT 2016


On Thu, May 26, 2016 at 10:29 PM, Zachary Turner <zturner at google.com> wrote:

> Essentially this code was trying to check "is it safe to reinterpret_cast
> sizeof(T) bytes to a T*".
>
> Is there a better way to check that?
>

Nope, not that I can think of. (& presumably you want to check alignment
too)


>
> On Thu, May 26, 2016 at 10:00 PM David Blaikie <dblaikie at gmail.com> wrote:
>
>> On Thu, May 26, 2016 at 7:53 PM, Rui Ueyama via llvm-commits <
>> llvm-commits at lists.llvm.org> wrote:
>>
>>> ruiu added inline comments.
>>>
>>> ================
>>> Comment at: include/llvm/DebugInfo/CodeView/StreamArray.h:114-115
>>> @@ -113,4 +113,2 @@
>>>    friend class FixedStreamArrayIterator<T>;
>>> -  static_assert(std::is_trivially_constructible<T>::value,
>>> -                "FixedStreamArray must be used with trivial types");
>>>
>>> ----------------
>>> majnemer wrote:
>>> > You could go with `std::is_standard_layout<T>::value &&
>>> std::is_trivial<T>::value` to get more or less the same thing.
>>> This seems a bit too tricky to me. It would just fail if you pass
>>> non-trivially-constructible class to this one, so I'm okay without this
>>> assertion.
>>>
>>
>> what/how would it fail? Testing for is_trivially_constructible to me
>> would indicate that this code is using memory that's perhaps zero'd out
>> without invoking the ctor for the type. If the type isn't trivially
>> constructible that sort of thing's going to result in subtle behavior,
>> quite often not an outright failure.
>>
>>
>>>
>>>
>>> http://reviews.llvm.org/D20719
>>>
>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160526/c2ece91b/attachment.html>


More information about the llvm-commits mailing list