Thorsten Glaser wrote:
Waldek Hebisch dixit:
Adriaan van Os wrote:
[...]
-fborland-objects -fmac-objects -fooe-objects -fgnu-objects
Or maybe (since they are mutually exclusive) -fobject-model=xx, where xx is bp,delphi,mac,ooe or default. The default model links to the dialect setting.
I have already implemented the -fxxx-objects version. -fobject-model=xx requires more work...
But it does look more logical, compared with all the other recent changes (such as -march= instead of e.g. -mpentium), and less bloated.
We do not want to have many objects models. So the bloat is limited. But if -fobject-model=xx is considerd better we can have it in the future.
By the way, I just digged out my old TP 6.01 manual and started throwing some random OOP code at gpc (20050217), and to my (but not too big) surprise everything worked as I remember from long ago. What, exactly, does "gnu objects" differently than borland (turbo pascal) as long as I use the object keyword?
The goal is to have no difference (be backwards compatible). There is small difference in new functionality (and it is likely to grow once new features get implemented).
Waldek Hebisch wrote:
Thorsten Glaser wrote:
Waldek Hebisch dixit:
Adriaan van Os wrote:
[...]
-fborland-objects -fmac-objects -fooe-objects -fgnu-objects
Or maybe (since they are mutually exclusive) -fobject-model=xx, where xx is bp,delphi,mac,ooe or default. The default model links to the dialect setting.
I have already implemented the -fxxx-objects version. -fobject-model=xx requires more work...
But it does look more logical, compared with all the other recent changes (such as -march= instead of e.g. -mpentium), and less bloated.
We do not want to have many objects models. So the bloat is limited.
Actually, if implementation bloat is meant, I think it's the other way around -- as Waldek wrote, the ...=... options would be more work here: These options are mostly there to imply other feature-specific options. We already have a table for option implications, and adding to it requires only some table entries, and no new code. To do this for ...=... options would probably require another mechanism or special case code.
Another difference is that, AFAIK, each backend can have its own -march= options (which probably leads to "bloat" there more easily), whereas the object model would be specific to one frontend, namely GPC, which does and will not have many models, as Waldek said.
By the way, I just digged out my old TP 6.01 manual and started throwing some random OOP code at gpc (20050217), and to my (but not too big) surprise everything worked as I remember from long ago. What, exactly, does "gnu objects" differently than borland (turbo pascal) as long as I use the object keyword?
The goal is to have no difference (be backwards compatible). There is small difference in new functionality (and it is likely to grow once new features get implemented).
New functionality means things such as "is" and "as" (which BP doesn't support), or not being required to call a constructor before a virtual method, etc. The implementation is a little different (but not too much), e.g. even objects without con-/destructors or virtual method have a VMT in GPC, not so in BP; BP does some contortions to do memory allocation within a constructor, while in GPC it's done by the caller which seems much easier; GPC's VMT has a few more fields to retrieve the object type name and parent type at runtime; etc.
Delphi and OOE objects use "class", so there will be no conflicts. Mac Pascal objects use "object" and are quite different from BP objects, but IMHO GPC's for object should always remain BP objects (plus extensions).
Frank
-
Frank Heckenbach -
Waldek Hebisch