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" <[email protected]> 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 <[email protected]> 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" <[email protected]> wrote: > >> > >> On Sun, Jul 12, 2015 at 1:56 PM, Jonathan S. Shapiro <[email protected]> > >> 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 > >> [email protected] > >> http://www.coyotos.org/mailman/listinfo/bitc-dev > > > > > > _______________________________________________ > > bitc-dev mailing list > > [email protected] > > http://www.coyotos.org/mailman/listinfo/bitc-dev > > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
