Date: Mon, 26 Apr 2021 18:20:02 +0300
On Mon, 26 Apr 2021 at 17:56, will wray via Liaison
<liaison_at_[hidden]> wrote:
>> I'm not sure why that matters. C++ array-ish types are very different
>> from C arrays, leaving C arrays the odd and irregular corner case.
> How are they "very different"? Should they be?
They compare and copy like normal objects do, and there's no decay in them.
Their declarations do not require understanding a "spiral rule".
> As Jens M. said
>> So far, C++ has shied away from adding more power and beauty
>> to C-style built-in arrays
> Why leave C array irregular, forever odd?
For backwards compatibility reasons.
> It is easy to make array more regular (c.f. P1997).
That proposal doesn't make them regular in the sense that they'd just work
without surprises in e.g. declarations. And it doesn't do anything to
array decay.
> That's the better use of committee time.
Happy to disagree on that, that's a far worse use of committee time, to spend
energy at fixing decades-old problems with serious compatibility constraints,
without being able to properly fix them, like the declaration problems.
> C array is a rough cut gem with sharp edges that cut.
> Let's polish a beautiful, pure, elemental aggregate.
C++ already has that, as std::array.
> It matters because C array matters, and not just to C.
> And not just to the 'numerical matrix' few who need multi-index.
> Lack of safe buffer handling causes continued pain and damage,
> to the detriment of C and C++ reputation.
C++ has safe buffer handling, as std::vector.
You're more than welcome to try improving C arrays to be usable
without all of their problems.
It'll take two decades for that work to bear fruit in the world of C++
programmers, when they
have first learned to never use C arrays; you first need to make the
improvements, and then slowly
get rid of all of the legacy problems. Once you've done that, the
adoption of C arrays into
C++ programs can begin anew.
As you suggest on other matters, there are better uses for committee
time. Improving C arrays
is not fixing a problem that C++ and its users suffer from.
<liaison_at_[hidden]> wrote:
>> I'm not sure why that matters. C++ array-ish types are very different
>> from C arrays, leaving C arrays the odd and irregular corner case.
> How are they "very different"? Should they be?
They compare and copy like normal objects do, and there's no decay in them.
Their declarations do not require understanding a "spiral rule".
> As Jens M. said
>> So far, C++ has shied away from adding more power and beauty
>> to C-style built-in arrays
> Why leave C array irregular, forever odd?
For backwards compatibility reasons.
> It is easy to make array more regular (c.f. P1997).
That proposal doesn't make them regular in the sense that they'd just work
without surprises in e.g. declarations. And it doesn't do anything to
array decay.
> That's the better use of committee time.
Happy to disagree on that, that's a far worse use of committee time, to spend
energy at fixing decades-old problems with serious compatibility constraints,
without being able to properly fix them, like the declaration problems.
> C array is a rough cut gem with sharp edges that cut.
> Let's polish a beautiful, pure, elemental aggregate.
C++ already has that, as std::array.
> It matters because C array matters, and not just to C.
> And not just to the 'numerical matrix' few who need multi-index.
> Lack of safe buffer handling causes continued pain and damage,
> to the detriment of C and C++ reputation.
C++ has safe buffer handling, as std::vector.
You're more than welcome to try improving C arrays to be usable
without all of their problems.
It'll take two decades for that work to bear fruit in the world of C++
programmers, when they
have first learned to never use C arrays; you first need to make the
improvements, and then slowly
get rid of all of the legacy problems. Once you've done that, the
adoption of C arrays into
C++ programs can begin anew.
As you suggest on other matters, there are better uses for committee
time. Improving C arrays
is not fixing a problem that C++ and its users suffer from.
Received on 2021-04-26 10:20:18