ORIGINAL: yvesp
ORIGINAL: Shannon V. OKeets
Delphi permits some generality for argument passing, but Pascal is stronglytyped. So, when a function is passed, the compiler wants to have information about the argument list so it can check whether the passed function matches. The result is that you need more than one 'universal' function. Here is some of the new code in MWIF:
// ****************************************************************************
// The next 6 routines pass Func or Proc as parameters. In order for the Func
// and Proc to execute correctly, they cannot use any variables that are local.
// All referenced variables have to either be a parameter in the argument list
// of the called Func/Proc or else be global. The module PassedParameters
// defines global variables which are used expressly for this purpose. Care
// must be taken to not use these in recursive calls or nested calls that use
// the same variable.
// ****************************************************************************
function DoesAnyStack(const Func: TStackFunc): Boolean;
function WhichStackDoes(const Func: TStackFunc): TMapStack;
function DoesAnyUnit(const Func: TUnitFunc): Boolean;
procedure ProcessEachUnit(const Proc: TUnitProc);
procedure ProcessEachUnitReverse(const Proc: TUnitProc);
function CountEachUnitReverse(const Func: TUnitFunc): Integer;
...
TUnitProc = procedure(var U);
TUnitFunc = function(var U): Boolean;
TStackFunc = function(var S): Boolean;
THexFunc = function(const Hex): Boolean;
TCoastalProc = procedure(var CD);
As I understand this, it really means that there are no generics in Delphi like there are in Java, ADA or C++ templates.
What was the rationale behind the choice of Delphi ?
I know you had no choice ; but did Chris tell you why he chose that framework ?
Yves
I don't know.
However, I believe that Delphi was a good choice (maybe the right choice).
---
I've written major applications in C++ (> 100,000 lines of code) and one of its weaknesses is it strength: the ability to do whatever you like as far as variable typing is concerned. Often that is done by inserting C code down at a lower level.
There is a substantial amount of code in MWIF that uses pointers, with the variable type being 'cast' onto the abstract pointer. I am not real happy with that code since it is vulnerable to errors that the compiler can not detect. To give you some insight into how I prefer things, I use AU, NU, and LU as variable names for air, naval, and land units. I restrict using U for a unit to those cases where I do not know the branch of service. In comparison, CWIF used U almost exclusively, which provided less information to me (the programmer) when I was reading the code. I also use Bmbr and Fgtr for bombers and fighters if the code fragment has narrowed down the unit type to that degree.
My point here is that by choosing good names for variables and functions/procedures the code is much easily to proof read. If I never see another Void Pointer in my life, I will not shed hot, wet tears. Being able to override the principle purpose of a language (e.g., Pascal: strong typing) is not a good thing in my opinion. It opens the door for creating code that can go flying off into the weeds without any warning. In essence, I deploy "tricky code" since being able to recognize it and remember what it does is difficult 6 months after you have written it.
Most of the 'tricks' are in legacy code (or taught in computer science courses as "neato stuff"), which were written when available memory was at a premium and CPU speed was a driving concern in order to get a program to function at all. Neither of those should be a factor in 99% of the applications written today. [Of course real-time software is an exception.]
Just my highly biased viewpoint.[:)]
