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.kamst...@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...@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
