Date: Tue, 27 Apr 2021 17:48:36 -0400
I would like to +1 on the correctness argument.
I've needed to fix way more native resource leaks in Java and C# than
C++... including one this month where a Java web service goofed and
didn't always close database resources.
It wouldn't have been a problem if the database resources were a value
type with a destructor... but neither Java, C#, nor C provide this
mechanism.
On 4/27/2021 2:40 PM, Ville Voutilainen via Std-Discussion 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?
I've needed to fix way more native resource leaks in Java and C# than
C++... including one this month where a Java web service goofed and
didn't always close database resources.
It wouldn't have been a problem if the database resources were a value
type with a destructor... but neither Java, C#, nor C provide this
mechanism.
On 4/27/2021 2:40 PM, Ville Voutilainen via Std-Discussion 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?
Received on 2021-04-27 16:48:40