Recursive calls and private objects
In a Stack Overflow question, someone asked about some nested procedure call he found out. That is, a procedure inside another procedure.
He found out this coding style to be messy, which sounds like a reasonable opinion. But his alternative proposal of putting the internal procedure outside the main one, i.e. making it global, is IMHO even worse.
In some case, a private
class, or even
object with methods is an handy and maintainable implementation
To process all nodes, a recursive call of
But you have to note that sometimes, inner functions need to access a lot more data than a few parameters.
Potential implementations may be:
- Use "flat" procedures, as in the naive rewrite of the Stack Overflow's OP;
- Use "nested" procedures, as in the original implementation;
- Create a dedicated
record+ methods) which will remain private to the implementation part of the
Of course, the 3rd option sounds the more maintainable.
It will allow clear separation of the process, and allow the use of variables local to their methods.
record (or an
object for older versions of
Delphi) will allow the processing object to be allocated on the stack of the
main procedure, so you won't need to write
Obj := TInterType.Create; try .. finally Obj.Free.
But if you use an
object please note that some new version of Delphi
has compilation issue - you should better use record with methods.
The "flat" procedure style is IMHO not better than "nested" procedure, and
even worse, since it would need to add additional parameters to the inner
calls, or use some global variables.
By the way, having a lot of variables for every call will increase stack space, and reduce speed.
The "nested" style is in fact OOP oriented. When an inner function is called, the compiler pass the caller stack base in a register to the nested function (just like the additional self parameter of an object). So the inner function is able to access all the caller stack variables, just as if they were declared in a private object (the 3rd solution).
The Delphi IDE and internal debugger handles nested procedures quite well. IMHO it could make sense for some small piece of code (that is, something that can be read on the same screen height). Then, when you need more process, a dedicated record/object with methods and explicit variables will be more maintainable. But the "flat" option is IMHO not to be coded.
In mORMot source code, you will
find some nested procedure calls, and some dedicated private
object, when it deals with recursion algorithms within
For instance, here is how we implement an optimized Quick Sort algorithm in
SynCommons.pas, for the
procedure. Even the pivot is allocated in this implementation, to let the stack
be as small as possible.
Code is still very readable and maintainable, IMHO.
type /// used internaly for faster quick sort TQuickSortRawUTF8 = object Values: PPointerArray; Compare: TUTF8Compare; CoValues: PIntegerArray; Pivot: pointer; procedure Sort(L,R: PtrInt); end;
procedure TQuickSortRawUTF8.Sort(L, R: PtrInt); var I, J, P: integer; Tmp: Pointer; TmpInt: integer; begin if L<R then repeat I := L; J := R; P := (L + R) shr 1; repeat pivot := Values^[P]; while Compare(Values^[I],pivot)<0 do Inc(I); while Compare(Values^[J],pivot)>0 do Dec(J); if I <= J then begin Tmp := Values^[J]; Values^[J] := Values^[I]; Values^[I] := Tmp; if CoValues<>nil then begin TmpInt := CoValues^[J]; CoValues^[J] := CoValues^[I]; CoValues^[I] := TmpInt; end; if P = I then P := J else if P = J then P := I; Inc(I); Dec(J); end; until I > J; if L < J then Sort(L, J); L := I; until I >= R; end;
procedure QuickSortRawUTF8(var Values: TRawUTF8DynArray; ValuesCount: integer; CoValues: PIntegerDynArray=nil; Compare: TUTF8Compare=nil); var QS: TQuickSortRawUTF8; begin QS.Values := pointer(Values); if Assigned(Compare) then QS.Compare := Compare else QS.Compare := StrComp; if CoValues=nil then QS.CoValues := nil else QS.CoValues := pointer(CoValues^); QS.Sort(0,ValuesCount-1); end;
In all cases, do not be afraid of creating some internal objects/classes to
implement your algorithms. The latest versions of Delphi allows even private
types in class definition - but sometimes, I feel more confortable with making
the internal object totally private to the
implementation part of
the unit, i.e. non even appearing as private members of the
interface part of the unit.
Classes are not only meant for publishing your process outside of the unit: OOP applies also to implementation patterns.
Your code will be more maintainable, and in most case, the
self parameter will be used to refer to all associated data
at once, so your code may also be even faster and lighter!
Feedback and comments are welcome on our forum.