Thorsten Glaser wrote:
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.
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:
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.
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