Re: Padding vfunc tables for less abi breakeage.

[Carl Nygard <cjnygard fast net>]

On Fri, 2005-01-07 at 10:20 +0100, Murray Cumming wrote:
> On Thu, 2005-01-06 at 21:56 -0500, Carl Nygard wrote:
> > Well, another point is that now you're locking yourself into supporting
> > all the old API, without a means to say "that was silly, we're not going
> > to support that cruft anymore".  And if you do choose to deprecate or
> > change API across minor numbers, then what was the point of the padding?
> 
> I don't understand how we get to this. We deprecate API when it gets
> old. But we don't break it's ABI during a stable series as well. We
> don't need to.
> 
> When we need to, we break ABI and do a parallel-installable version. I'm
> thinking of doing this for gtkmm 2.8, but we probably don't have enough
> little ABI changes to make it worthwhile.

That was probably muzzy thinking in the wee hours.  But I had another
thought, possibly equally muzzy.  If you pad out the vtable with dummy
signal handlers, and you have to add a new signal handler, don't you
also typically add a sigc::signal for it as well?  And I'd guess the
sigc::signal size would be more likely to vary depending on the argument
list or template parameter list, but I don't know the answer to that
either.  But if so, then that would be quite impossible to predict for
choosing padding sigc::signals.

You can't easily maintain a vector or array because you lose the type
information.

Regards,
Carl