David Chrisnall's libobjc2 supports it as well on non-apple platforms (I imagine only when compiled with clang) https://github.com/gnustep/libobjc2/
although I believe you are correct that neither gcc nor the gnu runtime do, anyhow it isn't limited to apple objc. On Mon, Jul 13, 2015 at 10:55 AM, David Jeske <[email protected]> wrote: > 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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" <[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 >>> > >>> _______________________________________________ >>> 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
