Re: [Vala] Can adding new virtual method break ABI?




If you need to do these things manually, then what's the point in using
vala? It's the job of compilers.I got a proposed solution, please say if you agree.

First, make a new attribute called "ClassStruct" with the field virtual_methods_total, which is the total 
virtual methods(used + unused).
This can't be decided automatically, since it doesn't know how many virtual methods the developer think of.

Secondly, use a half human half machine file called by default vala_abi_doc, which keeps the position of any 
generated virtual method.
The developer can do this manually before the compiler choose position, or let the compiler do this 
autocratically. The next compiler will
respect the offsets that has been chose. This file of course must be shipped with the library.

The first one solve the padding issue, the second solve the ordering issue.

Please share your opinion,
Tal

Date: Sat, 17 Dec 2011 12:01:45 +0800
From: pcman tw gmail com
To: mikkel kamstrup gmail com
CC: vala-list gnome org
Subject: Re: [Vala] Can adding new virtual method break ABI?

If you need to do these things manually, then what's the point in using
vala? It's the job of compilers.
People who like to do the job of compilers manually should use GObject/C
instead.
Manually filling a virtual function table and calculate offset of
pointers are really of fun. lol
Creating some empty functions for padding is even easier and more readable
IMO.
 
On Wed, Dec 14, 2011 at 6:15 PM, Mikkel Kamstrup Erlandsen <
mikkel kamstrup gmail com> wrote:
 
On 12 December 2011 12:15, Jürg Billeter <j bitron ch> wrote:
On Mon, 2011-12-12 at 12:12 +0100, Luca Bruno wrote:

On Mon, Dec 12, 2011 at 12:01 PM, Jürg Billeter <j bitron ch> wrote:
        On Sun, 2011-12-11 at 11:34 +0100, Luca Bruno wrote:
        > 2011/12/11 Tal Hadad <tal_hd hotmail com>
        >
        > > This idea is based on the assumption that the size of
        XClass struct
        > > doesn't matter and can be changed(Am I right?).
        > > Also, how does the virtual method order is currently done
        by Vala? Is it
        > > alphabetic or by the order of the decelerations?
        > >
        >
        > The ordering does not matter, the padding does.

        Ordering matters as well. Vala uses declaration order.

We're talking about virtual methods, aren't we? There's no ABI break
if the order of N pointers is exchanged.

When a subclass overrides a virtual method, the class_init function uses
the offset of the virtual function pointer. If that offset changes, the
subclass will need to be recompiled to work again.

Indeed.

Would it make sense to a [CCode (vfunc_padding = "8")] to class
declarations? This could then be decremented when new virtual
functions are added (to the end of the class!).

Cheers,
Mikkel
_______________________________________________
vala-list mailing list
vala-list gnome org
http://mail.gnome.org/mailman/listinfo/vala-list


_______________________________________________
vala-list mailing list
vala-list gnome org
http://mail.gnome.org/mailman/listinfo/vala-list                                          


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]