Am Montag, den 26.04.2021, 23:45 +0300 schrieb Ville Voutilainen:
> On Mon, 26 Apr 2021 at 22:32, Uecker, Martin
> <Martin.Uecker_at_[hidden]> wrote:
> > > > Which could also be a macro:
> > > Oh come on.
> > Why not? If the syntax is really so much of a problem,
> > then a macro would solve this in C as well
> > as the std::function or std::array templates do
> > in C++.
>
> I really wouldn't want to digress into why macros are bad, but
> 1) they don't scale
> 2) they don't obey scope
> 3) having two different programmers manage to not have incompatible
> macro clashes is a miracle
>
> So, the suggestion to paper over problems in declarations with a macro
> is a waste of both of our time. ;)

I think in this case, they would be just fine.

> > Of course, in C++ you could also use a template
> > instead of a macro:
> >
> > c_array<int, 3> x; // same type as int[3]
>
> Yeah, funny how we already have std::array that looks like that, and
> it just solves this problem, more in the next.

Except one is compatible with everything else in the
world and one is a different one C++ introduced in addition
to makes things... simpler?

In my opinion, this is an interoperablity problem.

> > > At the cost of requiring trailing return types to be used. That seems
> > > like a draconian requirement,
> > > when in general
> > > T foo(U);
> > > will just work.
> >
> > I assume you meant:
> >
> > std::array<T, N> foo(U);
>
> No. :) I meant that in general, any C++ declaration for an idiomatic
> (this part is important) C++ function can be written like
> that,
> T foo(U);
> No trailing return types. No macros, no aliases, no tricks. Write the
> return type first, then the name, then the
> parameter list. It doesn't matter what those types are. You don't need
> the spiral rule. You don't need aliases,
> typedefs, or macros to work around the need for the spiral rule.
>
> That's regular.

Only if you close your eyes and ignore the types for which this
currently does not work (because C++ inherited them from C and
still uses C's declarator syntax and which it still needs for
compatibility with the rest of the world).

Changing the declarator syntax would make it truly work for
all types. *That* would be regular.

> > > > > That's not what I'd call regular.
> > > > I agree it is strange syntax and I agree it should
> > > > be improved (and a simple macro is completely
> > > > sufficient to get regular syntax if necessary).
> > > > But all this has not much to do with the type as such.
> > >
> > > Well, it has everything to do with the type; how to use the type, specifically.
> >
> > Then we should change the declarator syntax and not
> > reinvent the type.
>
> Well, with a reinvented type, the declarator syntax works fine, and we
> don't need to invent
> new declarator syntaxes. So I'd step very cautiously before agreeing
> with that conclusion
> of yours about what we should do.

In this way C++ created a parallel universe of new types but
will probably still not be able to get rif of the C arrays
any time soon. And by ignoring them you make them even more
the irregular corner case instead of a proper part of the
type system. This is then a self-fulfilling prophecy.


> > > > void transpose(int A, int B, double o[B][A], const double i[A][B]);
> > > >
> > > > How do you write this in C++ (23?) ?
> > >
> > > std::mdspan<int, std::extents<2, std::dynamic_extent>>
> > > transpose(const std::mdspan<int, std::extents<2, std::dynamic_extent>>& input);
> > >
> > > Sure, fine, maybe we would like to entertain standardizing an extent
> > > type for 2d-dynamic. :P
> >
> > Thanks, I will stick to C.
>
> Right, and I'm likewise happy to have left it mostly behind. It's
> happily invincible (for the time being)
> in its strongest domains of device drivers and kernels, but has no
> business being used for any application
> code.

Well, I disagree. I find C perfectly fine for writing
highlevel code. I fact, I switched from C++ to C and found
this to be quite relieving. To me, it turned out that
most of C++'s features were simply an unnecessary distraction.

> There are approximately three people on the planet who are
> meticulous enough to use it for application
> code, and even those people write said applications in C++.

When I check what applications I personally use,
many of them are written in C.

> I'm always happy to exchange anecdotes, preferences, and fireside
> stories. I would like to point out, though, that having tried (and not
> just tried,
> I had to succeed, with whatever amounts of pain inflicted on me) to
> use both of these languages to solve
> the same problems in anger, I have much more than just preference
> anecdotes to report. :P

I guess I could share similar anectodes... would be fun!

> > (This is also strictly inferior than the C version because the
> > information about how the size of the arrays relate has been lost.)
>
> That's a separate problem. The C version's information of how the
> sizes relate is a vague suggestion
> that something might do the run-time check that verifies them to
> relate in the way suggested, but that
> run-time check doesn't actually exist. So adding that check is that
> separate problem, and when it's
> added, the information comes "back" for C++ as well.

Oh, some of the checks do exist and compilers are becoming better.
In the following example, you can get a run-time check with
both GCC and clang:


void foo(int N, double (*a)[N])
{
  (*a)[N] = 1; // traps!
}

Best,
Martin