According to Frank Heckenbach:
According to myself (Peter Gerwinski):
It's "class" = "reference to object". Fortunately, the GCC front-end is able to deal with such things,
Fine! :-) (Front-end? Or back-end?)
The front-end definitely is (read: we can use this for GPC); for the back-end it *might* be necessary to convert references to pointers. No big deal.
gpc will certainly not remove objects when classes are implemented. :-)
It won't. :-)
According to Frank Heckenbach:
According to The African Chief:
New(Foo); Foo.Create;
If it's undefined in Delphi, it wouldn't hurt if there is a defined behaviour in gpc. :-)
You cannot `New' a class because it is a reference, no pointer. The above should be a syntax error in GPC as well as in Delphi.
My suggestion: implement a compiler switch like '--base-class="TObject"' so that gpc will use this class by default as a parent class if no parent is declared (and, of course, if the current class is not "TObject" itself ;-). With "--delphi", this switch could be set automatically. Then, TObject could be declared in some unit (like System for Delphi). (For "completeness", we could also have '--base-object' or so...)
Sounds reasonable.
BTW: This is similar to the '--uses="system"' I suggested -- things that are not really the job of the compiler, but needed for compatibility. Such switches seem to make the difference to the compiler as small as possible.
Sounds reasonable. (Even *more* switches!)
For BP/Delphi programs that are just recompiled with gpc, these switches can be used. When the programs are really ported to gpc, these things would probably put into them programs themselves, and the switches would not be used anymore (neither for native gpc programs), I guess.
That's the anti-motivating part of compatibility: All this is intended *not* to be used.
Like I said, "Create" and "Destroy" are empty in TObject (i.e., they contain just an empty "begin end;" block). "Free" checks whether the pointer is Nil, and if it is not, it calls Destroy.
Nice little "trick", but not very systematic. "Free" is a method of an object, and this object can be "nil^"!? Technically, it works, but "Free" must not be virtual (I guess it isn't in Delphi)! But as a clean way, I'd prefer a procedure... (Or should we regard it as defined behaviour to call a static method of a non-existing object if the method doesn't access any fields of the object?)
Sorry, but this nice little trick is purest brain-damage!
I saw similar tricks in Turbo Vision. All of this works, but it relies on how the compiler and the RTS do things.
- Dereferencing a `Nil' pointer should yield a runtime error. Both BP and GPC don't check this, but this is a bug in the compiler to be eliminated when we implement runtime checks into GPC.
- Releasing the storage of an object while a method of it is running is idiocy. It should yield a runtime error, too, but this is too hard to detect for the compiler.
Greetings,
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]
-
Peter Gerwinski