Yes, its a good point. Objective-C effectively has Smalltalk objects, and the CLR implements something similar based on the earlier COM protocol. These are kind of like platform specific version of CORBA. All this can be implemented in C/C++, just like you can use COM or CORBA as a library, but its obviously much neater to have it all hidden and generated automatically from the language classes. My point was that dynamic loading/linking provides the underlying functionality necessary for this, and without it you could not implement these kind of features.
On 13 July 2015 at 18:55, David Jeske <dav...@gmail.com> 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. > I agree until the "unlike C++". Clearly you can implement all this in C++, it just requires a lot of boiler plate, like COM registration, listing available methods, unpacking messages, and making response messages. Obviously most of this work is done by libraries in C++, but it still means adding a layer of boilerplate to the code. So the difference is more about ease of use / coding / maintenance, than fundamentally something you could not do in C++. Keean, > 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 > >
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
