Am Samstag, den 12.02.2022, 10:50 +0100 schrieb Jens Maurer:
> On 12/02/2022 10.22, Uecker, Martin via Liaison wrote:
> > Am Freitag, den 11.02.2022, 17:52 -0500 schrieb Robert Seacord via Liaison:
> > > I agree with the direction of this discussion so far. Does this
> > > initialization problem only affect thread_local or does it affect other
> > > storage classes as well?
> >
> > I don't think there are other major issues.
> >
> > In general, as someone suffering from C <-> C++
> > interoperability issues myself, I think it would be
> > far better for the users if extern "C" evolved
> > into a proper foreign language interface similar
> > to what other programming languages have.
> >
> > For example, it could directly support complex types
> > or atomics and rewrite it into corresponding C++ types,
> > and it could ignore the restrict qualifier.
> > If we really wanted to make this good, we could
> > even rewrite VM-types transparently convert into
> > mdspa
> > n on the C++ side. All this could be done
> > without the risk that pure C++ code is affected
> > in any way,
> > and at the same time the C used in
> > these interfaces would not need to be so constrained
> > so much.
>
> So far, "extern C" imposes only additional restrictions
> on the contained stuff (namespaces are ignored when
> determining naming conflicts; thread_local supports only
> types with trivial construction and destruction).
> This seems plausible to me.
>
> Changing syntax inside "extern C" is going one step too far
> for me.

Yes, this is a position I kindly suggest that
we should reconsider. Because, - despite both
languages making sacrifices - the compatiblity
story between C and C++ is not great.

> Whether C++ wants to support "_Complex T" as an
> alias for std::complex<T> should be a global feature, to be
> decided on its own merits.

Complex exists for two decades in C and the
compatibility story is still poor.

> For atomics, my understanding is that the compatibility
> story is already quite good, because you can write _Atomic(T)
> in both languages.

I would say the compatibility story for atomic is
even worse because we even have ABI divergence
between C++ compilers, a compromised design in C
which that prevents the use of atomics in some
applications, and even in the simply case where
you can write _Atomic(T) I think this macro
was only added very recently to C++ (and then
it still requires inclusion of a header).


> For multi-dimensional VM-types, I'm not sure those can be
> represented with an mdspan at all.

It can not be represented, but it could be
automatically converted.

But yes, this would require approaching this
problem from a different perspective:

"How can we design a good interface for the user?"

instead of

"How can we support C interfaces with minimal
effort by constraining the common subset?"


Martin


> Jens