On Wednesday 24 July 2024 09:47:40 GMT-7 zxuiji wrote:
> What about simply defining something new in the language, like maybe "alias"
> which would have similar behaviour to a class but expects the ABI to be
> rather specific. For example the alias could just be something like this at
> minimum under the hood:
I don't think the C++ community is interested.

This ended up in the spam for some reason, maybe because you sent to me directly, having said that I now notice I did the same and sent this directly to you instead of via the mailing list so for the benefit of those who did not see my message here's what it was in reply to and then the message itself:

Considering the MS ABI is not publicly documented, the vendors may not want to
do that (by that I mean GCC, because Clang already does). The correct thing
would be to get MS to implement the portable ABI that everyone except them
use.

Good luck convincing them of any of that.

Now my response that peops missed:

What about simply defining something new in the language, like maybe "alias" which would have similar behaviour to a class but expects the ABI to be rather specific. For example the alias could just be something like this at minimum under the hood:

struct alias_<name>_vtable
{
   int32_t alias_<name>_vtablevacall( void *this, int32_t func_enum, char const *argsfmt, va_list va );
  ...
};

struct alias_<name>
{
   struct alias_<name>_vtable *vtable;
  ...
};

It would ensure all children can get the same behaviour as the parent, enable C to call C++ functions without the C++ semantics and still keep all the benefits of a class.
 
Finally my response to the 1st quoted message at the top is this. Do you really think the c++ community wants to keep dealing with operating systems directly all the time? Of course not and that's what the standard library is supposed to solve but it only does that at the API level. If it were to also do it at the ABI level it is feasible to converge on a single binary standard, I believe windows now supports *.elf and their respective *.so binaries now (can't remember where I read that) so that would be a suitable app and library extension pair to mandate. If it doesn't then maybe define a pair that can be strictly associated as "pure c/c++" like say *.sce (std c/c++ executable) and *.scl (std c/c++ library) where there's no more need for the poxy __declspec(dllexport)/__declspec(dllimport) for example, instead doing it the standard unix/linux way of exported by default and extern for importing. I want to put an end to the *.app vs *.exe vs *.AppImage vs etc madness and just have ONE standard to work with, not hundreds (probably, didn't do the multiplications but OS * ARCH * DATA_MODEL * ENDIAN does strike me as resulting in hundreds).

On Wed, 24 Jul 2024 at 17:47, zxuiji <gb2985@gmail.com> wrote:
What about simply defining something new in the language, like maybe "alias" which would have similar behaviour to a class but expects the ABI to be rather specific. For example the alias could just be something like this at minimum under the hood:

struct alias_<name>_vtable
{
   int32_t alias_<name>_vtablevacall( void *this, int32_t func_enum, char const *argsfmt, va_list va );
  ...
};

struct alias_<name>
{
   struct alias_<name>_vtable *vtable;
  ...
};

It would ensure all children can get the same behaviour as the parent, enable C to call C++ functions without the C++ semantics and still keep all the benefits of a class.

On Wed, 24 Jul 2024 at 05:18, Thiago Macieira <thiago@macieira.org> wrote:
On Tuesday 23 July 2024 20:33:38 GMT-7 zxuiji wrote:
> There *cannot* be any out-of-
> line member functions. So to achieve this, we'd need to force the standard
> library implementors to start their own forum on how to describe the common
> ABI that the C++ Standard would mandate
>
>  Very simple solution that doesn't require a lot of umming and uhhing from
> that commitee, or even their involvment at all. Just get compilers to
> implement an extension like "__attribute__((abi(msc))". Where ever there's
> a difference in ABI implementation the attribute would tell the compiler to
> forgo it's usual implementation and use the specified compiler's
> implementation. This would resolve that __thiscall thing mentioned earlier
> in classes as a simple "__attribute__((abi(msc)) class stdabi::ns::ver {
> ... }"

Considering the MS ABI is not publicly documented, the vendors may not want to
do that (by that I mean GCC, because Clang already does). The correct thing
would be to get MS to implement the portable ABI that everyone except them
use.

Good luck convincing them of any of that.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering