Date: Sat, 26 Aug 2023 14:52:10 -0700
On Saturday, 26 August 2023 11:31:30 PDT Sebastian Wittmeier via Std-Proposals
wrote:
> Are IABCComHandler and IXYZComHandler compatible? Do they have the same
> layout, the same class invariants? Or at least for the usage (member
> function calls) of this modified pointer?
And if they are in fact exactly the same, then why are there two classes?
I remember a comment at my previous job, when someone complained that when
"code organisation starts to resemble corporate organisation, it's time to get
out".
I agree with Frederick's premise, that we work in the real world and have to
fix real-world problems sometimes with unconventional means. I have done that.
In fact, I have pending code to submit to Qt that actually does something very
similar, working around a limitation of GCC.
static_assert(sizeof(QTypedArrayData) == sizeof(QArrayData));
auto d = reinterpret_cast<QArrayData **>(td);
The problem is that it's hard to standardise real-world problems. We can only
standardise common problems, not real corner-cases or one-offs. We have to
think of the majority, the greatest benefit per unit of work in the standards
team and the compiler developers, still leaving the language teachable ("the
needs of the many"). We also all want to have fast code, but may turn on
everyone else the minute it breaks our precious optimisations and prevents us
from doing the work we want to do.
The fact that the example he gave in no way supports the proposed solution
(wouldn't be solved by it!) doesn't help his case.
wrote:
> Are IABCComHandler and IXYZComHandler compatible? Do they have the same
> layout, the same class invariants? Or at least for the usage (member
> function calls) of this modified pointer?
And if they are in fact exactly the same, then why are there two classes?
I remember a comment at my previous job, when someone complained that when
"code organisation starts to resemble corporate organisation, it's time to get
out".
I agree with Frederick's premise, that we work in the real world and have to
fix real-world problems sometimes with unconventional means. I have done that.
In fact, I have pending code to submit to Qt that actually does something very
similar, working around a limitation of GCC.
static_assert(sizeof(QTypedArrayData) == sizeof(QArrayData));
auto d = reinterpret_cast<QArrayData **>(td);
The problem is that it's hard to standardise real-world problems. We can only
standardise common problems, not real corner-cases or one-offs. We have to
think of the majority, the greatest benefit per unit of work in the standards
team and the compiler developers, still leaving the language teachable ("the
needs of the many"). We also all want to have fast code, but may turn on
everyone else the minute it breaks our precious optimisations and prevents us
from doing the work we want to do.
The fact that the example he gave in no way supports the proposed solution
(wouldn't be solved by it!) doesn't help his case.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-08-26 21:52:12