On Tue, 27 Apr 2021 at 21:52, Hyman Rosen via Std-Discussion <
std-discussion_at_[hidden]> wrote:

>
> In my model, constructors and destructors are still functions that make
> changes to the memory of the object, and are still called at the same times
> they are now. But the programmer is permitted to arrange memory in other
> ways, and if an operation of a type applied to that memory finds it
> suitably arranged, the operation succeeds.
>

You are not alone here. While I have sympathy with the desire to optimise,
and therefore require a memory model, I would also like a way to tell the
compiler to “just trust this type pun” or “respect that I know that this
memory represents an object”.



> On Tue, Apr 27, 2021, 2:40 PM Ville Voutilainen <
> ville.voutilainen_at_[hidden]> wrote:
>
>> On Tue, 27 Apr 2021 at 21:22, Ville Voutilainen
>> <ville.voutilainen_at_[hidden]> wrote:
>> >
>> > On Tue, 27 Apr 2021 at 21:12, Hyman Rosen <hyrosen_at_[hidden]> wrote:
>> > >
>> > > I respectfully believe you are giving me the courtier's reply:
>> https://en.wikipedia.org/wiki/Courtier%27s_reply
>> > >
>> > > That is, one does not need to be a tailor to proclaim that the
>> emperor is naked. Things like bit_cast and launder, the inscrutability of
>> the aliasing rules, the questions about the pointer arithmetic used to
>> implement vector, all show that something is very wrong with the object
>> model.
>> > >
>> > > There's is also zero chance that a proposal to model objects as
>> memory+type would ever be accepted, because it would do away with many of
>> the permissions the current situation gives to compiler writers to optimize
>> code (which is also permission to disregard programmer intent).
>> >
>> > So, you're playing a broken record, complaining when it's described a
>> > broken record, and plan to continue to do nothing
>> > about it but keep playing it?
>>
>> More concretely:
>> You wrote "The wrong definition used by C++ requires that objects be
>> "created", and have "lifetimes" that "begin" and "end"..."
>>
>> So you're suggesting that an object of type std::string should just
>> spring into existence the moment you try to refer to
>> any random memory location with a std::string glvalue?
>>
>> These rules are not just for optimization, no matter how many times
>> you incorrectly claim they are. They're all about
>> correctness, and optimizers can use them because they allow optimizers
>> to verify that certain optimizations are correct
>> to perform. With the "rule" you suggest, I can't know whether a string
>> object is valid, and tools can't tell me, because
>> all objects everywhere are always valid, even though they obviously
>> aren't.
>>
>> Tell me again why anyone should listen to these suggestions of yours?
>>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>

-- 
Richard Hodges
hodges.r_at_[hidden]
office: +44 2032 898 513
home: +376 861 195
mobile: +376 380 212