[ub] new revision of p0593

Tony V E tvaneerd at gmail.com
Sat Feb 10 00:34:16 CET 2018


On Fri, Feb 9, 2018 at 5:50 PM, David Vandevoorde <daveed at edg.com> wrote:

>
>
> On Feb 9, 2018, at 5:46 PM, Richard Smith <richardsmith at googlers.com>
> wrote:
>
> On Fri, 9 Feb 2018 at 14:25, David Vandevoorde <daveed at edg.com> wrote:
>
>> On Feb 9, 2018, at 4:57 PM, Richard Smith <richardsmith at googlers.com>
>> wrote:
>>
>> On Fri, 9 Feb 2018 at 13:08, Myria <myriachan at gmail.com> wrote:
>>
>>> Is it worth mentioning that an implementation may have other
>>> mechanisms that create storage in the manner of malloc?  For example,
>>> it'd make sense for VirtualAlloc or mmap to create implicit objects
>>> just like the standard malloc functions.
>>>
>>
>> Sounds like a good change to me.
>>
>>
>>
>> It would be nice if we could indicate that in a portable way.  The
>> default is wrong for attributes, unfortunately, but otherwise something
>> like:
>>
>> [[blessed_storage]] void* my_memory_map(…);
>>
>> would have been useful.
>>
>
> Yes, it's annoying that attributes don't work out here. I think we won't
> need any annotations at all in the actual source code for most such
> functions in practice, because these functions result in syscalls that are
> opaque to the optimizer anyway (for all it knows, the kernel might have
> created objects in the storage...). But there are likely exceptions that
> have a C++ implementation that might get combined with the program source
> code via link-time optimization, and we do need to avoid bad things
> happening in that case.
>
>
> Although in those cases the C++ implementation can have a barrier “bless”
> call on the inside, right?
>
>
>
>
>> Incidentally, I’m not too fond of the name “bless”.  Maybe
>> “implicit_lifetime”?
>>
>
> Maybe I should just call it `bikeshed` until this gets to LEWG :)
>
>
> Hopefully nobody will bless bikeshed :-P
>


Didn't LEWG already call it byte_cast?  I mean bit_cast?
How is this different?
Or does bit_cast need to call bless/bikeshed?


> Daveed
>
>
>
>
> _______________________________________________
> ub mailing list
> ub at isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/ub
>
>


-- 
Be seeing you,
Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/ub/attachments/20180209/aed79a80/attachment.html 


More information about the ub mailing list