Date: Thu, 7 Nov 2024 15:59:40 +0100
Nonono, this is not a good idea. Even if you could figure out that
something is wrong with the ABI, what would you do? C++ has not
standardized the ABI and for good reasons. The proper way to do this is by
owning the ABI yourself (i.e. use that C++ is ABI-compatibility with C such
as struct layouts, parameter layout and calling conventions). That is,
anything that crosses the boundary between the libraries/application must
be ABI-owned by you. If you pass a vector, span or essentially anything STL
(with a few rare exceptions) you are bound to run into trouble unless you
always use compilers+standard libraries that themselves guarantee ABI
stability.
What worse, this type of construct may falsely make users think that they
can use such a construct to "query" whether a library is ABI compatible
with the current context or not. Which, as others here have already pointed
out, would not reliable.
// Robin
On Thu, Nov 7, 2024, 12:08 Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Thu, Nov 7, 2024 at 10:35 AM Giuseppe D'Angelo wrote:
> >
> > > (2) It's possible for two classes to have identical layout but to
> > > still have differing and incompatible implementations.
> >
> > Bingo. Say that your magic function tells you that vector<int> is made
> > up of 3 pointer-sized fields. What are they?
> >
> > * begin, end, capacity
> > * begin, end, pointer to physical end
> > * begin, size, capacity
> > * begin, size, pointer to metadata/bookkeeping
> > ...
> >
> >
> > And even if they match, who tells you they're used in a consistent way?
> >
> > You need something *beyond* C++ to deal with ABI incompatibilities and
> > with the unsafety of plugin loading in general.
>
>
> Maybe I'm going off into fairytale land with it here, but we could
> compute a hash sum for all of the members, so for example let's say
> the class is:
>
> class Monkey {
> int n;
> char *p;
> void DoSomething(void);
> };
>
> Then you would take the names of all of the members, i.e. n + p +
> DoSomething, and you concatenate them to give the string:
>
> "npDoSomething"
>
> and then you feed that into a hash algorithm such as sha256 to give a
> 256-Bit digest. So then you compare the two digests to see if you're
> dealing with the same implementations.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
something is wrong with the ABI, what would you do? C++ has not
standardized the ABI and for good reasons. The proper way to do this is by
owning the ABI yourself (i.e. use that C++ is ABI-compatibility with C such
as struct layouts, parameter layout and calling conventions). That is,
anything that crosses the boundary between the libraries/application must
be ABI-owned by you. If you pass a vector, span or essentially anything STL
(with a few rare exceptions) you are bound to run into trouble unless you
always use compilers+standard libraries that themselves guarantee ABI
stability.
What worse, this type of construct may falsely make users think that they
can use such a construct to "query" whether a library is ABI compatible
with the current context or not. Which, as others here have already pointed
out, would not reliable.
// Robin
On Thu, Nov 7, 2024, 12:08 Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Thu, Nov 7, 2024 at 10:35 AM Giuseppe D'Angelo wrote:
> >
> > > (2) It's possible for two classes to have identical layout but to
> > > still have differing and incompatible implementations.
> >
> > Bingo. Say that your magic function tells you that vector<int> is made
> > up of 3 pointer-sized fields. What are they?
> >
> > * begin, end, capacity
> > * begin, end, pointer to physical end
> > * begin, size, capacity
> > * begin, size, pointer to metadata/bookkeeping
> > ...
> >
> >
> > And even if they match, who tells you they're used in a consistent way?
> >
> > You need something *beyond* C++ to deal with ABI incompatibilities and
> > with the unsafety of plugin loading in general.
>
>
> Maybe I'm going off into fairytale land with it here, but we could
> compute a hash sum for all of the members, so for example let's say
> the class is:
>
> class Monkey {
> int n;
> char *p;
> void DoSomething(void);
> };
>
> Then you would take the names of all of the members, i.e. n + p +
> DoSomething, and you concatenate them to give the string:
>
> "npDoSomething"
>
> and then you feed that into a hash algorithm such as sha256 to give a
> 256-Bit digest. So then you compare the two digests to see if you're
> dealing with the same implementations.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2024-11-07 14:59:56