>
> 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_at_[hidden]> 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_at_[hidden]> 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
>>
>>
>>
>>