Keean, your assertion isn't very specific, so im not sure what you are implying.
C++ pretty much requires apps to be runtime linked against dll versions which exactly match the headers they were compiled against.. Because the headers share object layout. Apple objc (not gnu), swift, java, and CLR are certainly more sophisticated than this. CLR is one of the most sophisticated, as it handles all layout issues at runtime, so there are no compiled in layout dependencies. afaik it can even change in memory layouts for already allocated objects to match new alignments during dynamic loading. Apple objc (but not gnu) and swift have a fbc fix which is called "non fragile ivars". There are some details here. http://www.sealiesoftware.com/blog/archive/2009/01/27/objc_explain_Non-fragile_ivars.html So in apple objc, swift, clr, java - substantial layout resolution issues are deferred to runtime load-link... Unlike c++ which encodes layout in headers and bakes layout in at compile time. On Jul 12, 2015 9:27 PM, "Keean Schupke" <ke...@fry-it.com> wrote: > 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 > >
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
