Martin schrieb:
c) keep the current behaviour, but add functionality to the compiler
to help debug problems that can occur as a result of problems that can
occur as a result of this behaviour
Concrete: add means to ignore "const" with managed types.
Further debugging aids as far as feasable. Do we want to make FPC an
outstanding compiler, WRT bug hunting? IMO *not* a realistic goal.
Actually I think you can describe that as 3 independent proposals:
1) Add a compiler switch or directive to disable "const"behaviour for
ref counted types (e.g. simply ignore "const" for
string/dyn-array/interface params; Actually downgrade, still prevent
assignment to local var)
+1
2) Add automatic optimization of dropping ref-count and exception frame,
if the compiler can prove it to be save (e.g. no calls to any other
code...). This can happen completely independent of either the present
or meaning of const.
~ [people will point at you if it doesn't work perfectly :-]
3) Add safety checks (similar to range checks)
As a debug feature only, on demand (debugging memory manager?)
Most people don't have problems with const, according debug features are
*not* an urgent requirement.
I only agree that a *quick workaround* (global "ignore const" option) is
highly desireable (a *must*) for the rare (but real) cases where it can
make runtime errors disappear.
Extended debug features are not so important, because code with such
problems typically suffers from *general* problems, which suggest a
change of the personal coding style. A compiler can prevent an user from
shooting himself into one foot, at best, but not prevent him from
shooting himself into other limbs :-]
3)
Might not only help to fix issues, but might also create awareness.
This may apply to newbies, but IMO will be ignored by people which
*believe* that they are superior coders, maybe from practice in other
languages. A collection of suggested design patters (resource
protection, object ownership...) would be nice - in detail for pointing
people with coding style problems to. We could add to that collection
all demo code, that forces unexpected exceptions, together with a safe
version of the same code, that eliminates the demonstrated problem.
If an exception frame already exists (even if on a higher stackframe),
and the compiler can detect that it does exist:
then instead of creating an exception frame for the current stackframe,
all the variables that need refcount decrement, can be added to a list.
This list can be processed by the exception handler, before any other
code executes. The draw back is, that memory needs to be allocated for
this list.
IMO this is what the compiler already does, or should do - an implicit
try-finally block with a list of variables to be finalized on exit of a
subroutine (used also in stack unwinding after an exception). One should
not confuse try-except (*handling* exceptions) and try-finally
(guaranteed *cleanup*).
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
