Pointers to Pointers

When you first learn about pointers, it takes a little while to get that aha moment. They're a bit like recursion and closures in that respect. Then, just when you think you've got it, get shown pointers to pointers. You understand the concept, but can't really figure out where they'd be useful. So you look at the examples, but you still can't see their use. The examples are just so contrived, that you're left thinking, I'm never really going to need to pointers to pointers.

Delphi does a pretty good job of hiding anything to do with pointers from you, and you can go for years without using a pointer if you really didn't want to. I resort to pointers quite often, but I can't really remember a time when I really needed a pointer to a pointer. That is until this weekend.

I was looking at the jclExprEval unit in the Jedi Code Library. Now the code as it stands make it very easy to add variables.

var
 A : Double;
 B : Double;
 ...
 ...
begin
 ExprEval.AddVar('A', A);
 ExprEval.AddVar('B', B);
 CompiledExpression := ExprEval.Compile('A+B');
 Result := CompiledExpression;
 

The variables A and B are internally stored as pointers to double. This is all well and good, and this works fine. Now what I wanted to do was to be able to compile an expression once, and repeat it multiple times over an array of values. Actually each variable in the formula is an array. I wanted to do something like

var
 DataA : array of double;
 DataB : array of double;
 A     : pDouble;
 B     : pDouble;
 ...
begin
 A := @DataA;
 B := @DataB;
 ExprEval.AddVar('A', A);
 ExprEval.AddVar('B', B);
 CompiledExpression := ExprEval.Compile('A+B');
 i := Length(Result);
 while i>0 do
 begin
   Result[i] := CompiledExpression;
   Inc(A);
   Inc(B);
   Dec(i);
 end;
 

I thought initially I'd just override AddVar so it can take a pointer to a double, and store it directly. That was before I thought about it properly. When I did think about it, I realised it wouldn't work. Since the variable internally is stored as a pointer to a double it is basically a copy of A. at least initially it is.

Incrementing the pointer A just gives you the following

 

As soon as you see the picture the solution is obvious.

 

A pointer to a pointer! We can manipulate A anyway we like, and our internal copy still points to the right place. Whereas before to get to the value of our variable we'd de-reference the pointer once, now we have to be careful and do it twice. I had to write quite a few classes and methods (basically replicate the whole structure that handled pointers to handle pointers to pointers) to get this to work, but as I said before, the code is well written, and extending it to do what I want was really easy. So while pointers to pointers and even simple pointers are not essential (as I'm sure a load of C# developers will tell me) they do have a place in a Delphi programmers toolbox.

My definition of good code

Following on from my post regarding JclExprEval of the Jedi Code Library, Barry Kelly, left me a comment that in fact the unit had been documented, and he gave me a link to it.

I don't think I'm going to even bother downloading it. I can't really see what the documentation can give me that looking at the code hasn't (although being a curious fellow, I no doubt will). The is self documenting. Considering it was all new code to me, it took me no more than a few minutes to make the necessary changes to it to get it to work in my situation.

So while I have said before that to describe what good code is is rather difficult, my new definition for good code is any code which is discoverable and maintainable without resorting to documentation (because be honest, who reads the manual?) is good code. I probably should add it should also do what it's supposed to, but that's a given, no?

Without flattering Mr Kelly too much, JclExprEval fits that description perfectly. Now, back to the awful code that I was labouring with on Friday, which certainly doesn't fit that description.

Faith Restored..

..in mankind that is. Well at least in developer-kind. After Friday's travails with that awful code, I was beginning to think it was impossible to pick up someone else's code and run with it. Well, today I was messing around with expression parsing and evaluation, and asked a question on stack overflow regarding the subject. One of the answers was from Barry Kelly, who works for Codegear on the compiler team. (maybe he IS the compiler team, I don't know) More often than not, it's Barry who answers my questions, I don't know why I don't just ask him for his phone number. Anyway, he pointed me in the direction of the Jedi Code Library and more specifically the JclExprEval unit. Apparently he wrote this a few years ago. It's everything that the code I was struggling with on Friday was not. It's will written, simple to read and understand, even though there is no documentation. Very easy to use, and should I ever need to debug it, I'm sure I'd have no problems. I can understand exactly what the developer had in mind, and can use it as is, or take away what I need with very little effort.

It's not always easy to describe what makes good code and what makes bad code. The thing is though, you always know good code from bad as soon as you see it. You also can tell so much about the developer who wrote it even though you've never met him or her.