That means you have to have the correct headers for the library version you are linking against. You can do that be appending the library version to the shared objects, and choosing to link against the one that matches the headers used at compile time.
I think neither Swiift, Objective-C nor C# do anything more sophisticated than this. I would be interested if anyone knows otherwise. Keean. On 13 July 2015 at 08:15, Matt Rice <ratm...@gmail.com> wrote: > only if the class heirarchy is from the same shared library as the > field lookup... some language runtimes can cache the relocation e.g. > when run in a loop if they have a way to invalidate the cache when an > object size changes, others cannot... > > On Mon, Jul 13, 2015 at 12:03 AM, Keean Schupke <ke...@fry-it.com> wrote: > > Is the overhead not eliminated in the link phase when ld.so replaces all > the > > relocation information with the absolute address loaded at? > > > > I would have thought after symbol relocation at link time (when the > shared > > object is loaded) the machine code executed at runtime should/could be > the > > same. > > > > Keean. > > > > On 13 Jul 2015 7:12 am, "Matt Rice" <ratm...@gmail.com> wrote: > >> > >> Right, the objective-c approach to the fragile base class problem is > >> to have an symbol which stores the offset of the subclass relative to > >> the base class, and when the base class that symbol gets patched up to > >> reflect the base classes new size, this requires an addition of the > >> end_of_base_class+fields_offset, to access a field... they deem this > >> an acceptable overhead, not going to really argue with that its > >> constant at least... > >> > >> what I take umbrage with is that it puts you in a position where it is > >> deemed acceptable to not know the actual shape of an object until > >> runtime, and if you care or worse require that the size of an object > >> at compile time *is* the size of an object at runtime, I find it an > >> unacceptable position. > >> > >> On Sun, Jul 12, 2015 at 10:37 PM, Keean Schupke <ke...@fry-it.com> > wrote: > >> > Really each Swift component is like a COM component and designed to be > >> > dynamically loaded at runtime. > >> > > >> > On a unix/Linux platform its the equivalent of compiling every object > as > >> > a > >> > separate shared object library. What swift does, like C# does for COM > is > >> > hide the boilerplate of the dynamic library loading, making it > >> > automatic, > >> > and hidden from the programmer. > >> > > >> > Objective-C is really two languages, a static 'C' fragment, and a > >> > Smalltalk > >> > fragment (in the square brackets). Where the COM like functionality is > >> > handled by the Smalltalk fragment. Swift integrates these two parts > into > >> > a > >> > single language. > >> > > >> > Keean. > >> > > >> > On 13 Jul 2015 2:24 am, "Matt Rice" <ratm...@gmail.com> wrote: > >> >> > >> >> On Sun, Jul 12, 2015 at 1:56 PM, Jonathan S. Shapiro < > s...@eros-os.org> > >> >> wrote: > >> >> > Matt: > >> >> > > >> >> > While size and offset unknowns may begin with a type variable, they > >> >> > are > >> >> > compounded both by combinatorics and by overload resolution. The > >> >> > latter > >> >> > especially in the presence of inlining. > >> >> > >> >> Precisely why the separate compilation strategy was limited to the > set > >> >> of types with known sizes and offsets, (or isolation between > >> >> environments which can contain variables of :type, and actual type > >> >> values... albeit pessimistically... there are some caveats where > >> >> things really don't care and passing a shape as a parameter is > >> >> adequate I don't have any answer for cases such as that yet > >> >> really...), > >> >> > >> >> I don't really see this complication as adequate justification for > >> >> post compilation relocation... though the separate compilation > >> >> available is a bit weird compared to what we typically associate with > >> >> the term I suppose... > >> >> > >> >> Anyhow, sorry for rambling off the topic of swift... > >> >> _______________________________________________ > >> >> bitc-dev mailing list > >> >> bitc-dev@coyotos.org > >> >> http://www.coyotos.org/mailman/listinfo/bitc-dev > >> > > >> > > >> > _______________________________________________ > >> > bitc-dev mailing list > >> > bitc-dev@coyotos.org > >> > http://www.coyotos.org/mailman/listinfo/bitc-dev > >> > > >> _______________________________________________ > >> bitc-dev mailing list > >> bitc-dev@coyotos.org > >> http://www.coyotos.org/mailman/listinfo/bitc-dev > > > > > > _______________________________________________ > > bitc-dev mailing list > > bitc-dev@coyotos.org > > http://www.coyotos.org/mailman/listinfo/bitc-dev > > > _______________________________________________ > bitc-dev mailing list > bitc-dev@coyotos.org > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
