On Mon, Sep 17, 2012 at 3:31 PM, Marvin Humphrey <[email protected]> wrote: > On Mon, Sep 17, 2012 at 1:24 PM, Nathan Kurz <[email protected]> wrote: >> http://blog.omega-prime.co.uk/?p=121 > > Rats. I wish what was described in that post actually worked. It would be > so nice if we could alias e.g. `lucy_Query_to_string_OFFSET` to > `cfish_Obj_to_string_OFFSET`. > > Even better if we could alias to a constant, so that e.g. > `lucy_Query_to_string_OFFSET` could be replaced by `72` at link-time.
I'm hoping there still is a way, and hoping that way isn't too awful. I mean, it's obviously possible, just a question of how low we have to go. Do you suppose it would be awkward to distribute our own dynamic linker? :) > >> I think the general approach of this paper: http://2f.ru/holy-wars/fbc.html >> Old, and C++, but a nice simple approach. Add padding where you think >> you'll need it, and have an "ioctl" type safety net. We may also be >> able to use their trick of padding both the top and bottom of the >> VTable to allow us to move things between parent and child. > > Yeah, some people abide by such constraints: > > http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B > > I think it's an outmoded approach in the era of CPAN, rubygems, etc. The > fragile coupling of C++ is poorly suited for distributed development and > dynamic > linking. Personally, I'm not willing to put up with it. > > Clownfish solves most of these issues already -- we don't have to pull any > silly tricks to preserve vtable ABI compat, for example. Only member variable > issues remain and stand in the way of a comprehensive solution to the fragile > base class problem. Yes, I essentially agree. I was probably unclear, and wasn't suggesting this was a good solution for VTables. It's not. Instead, I was suggesting that we might take an analogous approach for instance variables. I think the main weakness of the BeOS approach is how it handles overrides. Is it even possible to override an instance variable? Instead, it's more frequently a matter of additions, and occasionally movement of a variable between a parent and a child. As such, I think we could do quite well sticking with simple structs and padding them with some extra internal space. The 'ioctl' wouldn't be a 'perform' function, but a link to a substruct. If the padding ran out and we desperately needed to add another variable to a parent class, we'd add a pointer to a struct in the last space. Then one would reference foo->extra->new1, foo->extra->new2. This would hold us until the next major release, when we'd clean up, fold this into the main struct, and add extra padding if still needed. Not too pretty, but a decent backstop. And if we plan ahead as to where additions are most likely, we shouldn't ever have to resort to it. I love the simplicity of a simple struct: no macros, no accessors, no opacity. If there is any way we can keep it for instance variables, I think we should. --nate
