TURBU Tech

Firebird is a great database, but it’s got one really irritating drawback: no native support for the boolean type.  The standard solution to this issue is to create a BOOLEAN domain as a special restricted version of a smallint, and then make your database driver output the correct type.

The first part is easy.  The second, not so much, if you want to use DBExpress.  This really should be handled internally as a special case inside the DBX driver.  Unfortunately neither Embarcadero nor Chau Chee Yang, maker of the alternative dbExpress Firebird driver, has released the source to their drivers, neither driver handles the BOOLEAN domain, and neither driver has any sort of callback/event handler that you can set up to intercept and modify the schema of a query result.  But I’m not gonna let a little thing like that stop me! Continue reading ‘Adding boolean support to Firebird+DBX’ »

One annoying thing I’ve noticed in building my script compiler is the way the use of generic collections tends to bloat up the size of your EXE.  I use generics for a lot of things; a compiler uses lists, stacks and lookup tables (dictionaries) all over the place.  When I was building it with DeHL, the compiler plus a very simple test frontend compiled into a 36 MB behemoth of a binary, and a quick look at the mapfile shows that the vast majority of that was DeHL collections.  Now that I’ve switched to the more simplified Collections library, it “only” takes 23 MB, a savings of about 33%.  But that’s still huge.  There has to be a better way.

Continue reading ‘Wish list: Generics collapsing’ »

Over the past couple weeks, I’ve been working on refining and testing my RTTI generation and the scripting system I’ve been building on top of it, which I’ve decided to call RTTI Script.  I think I’m finally starting to get something ready for public consumption.  I set up a Google Code repository this morning for RTTI Script, but so far all it contains is the RTTI generation code.  The actual compiler and script executor still need some work. Continue reading ‘RTTI Generation code now available’ »

A few years back, I ran across this post by Hallvard Vassbotn.  (It’s a shame he stopped blogging, because he always had some very interesting stuff about the technical details of how stuff in Delphi works.)  At the bottom was a paragraph that really fascinated me:

On a more technical level it suffices to say that they use custom and extremely compact and fast data structures, tricks and hacks to be able to represent millions and millions of objects within the constraints of a 32-bit Windows system. Throw in the use of Physical Address Extensions, storing per-class information in “virtual” class vars to reduce object instance size, creation of classes and their VMTs dynamically at runtime (!!), pointer packing, multithreading, the list just goes on and on.

Continue reading ‘Dynamic class creation: moving beyond the theoretical’ »

One of the biggest complaints about the extended RTTI introduced in Delphi 2010 is the way it adds so much to the size of your EXE.  Well, in a recent StackOverflow answer, Barry Kelly hinted that the format of the basic RTTI structures in TypInfo.pas are “more likely to change from version to version now that it has a much higher level abstraction in the Rtti unit.” Continue reading ‘Smaller, cleaner RTTI coming?’ »

Quick, what’s the output of this simple routine?
Continue reading ‘Beware using anonymous methods in loops’ »

I mentioned the new generic collection TThreadedQueue<T> in my First Look at Delphi XE. I decided to play around with it a little recently.  It’s useful for passing data between one thread that produces output and another that consumes it, keeping the two in step by blocking if the consumer tries to pop from the queue while it’s empty.

The first thread goes through and pushes data into the queue however it wants to.  The second has it easy; all it has to do is loop endlessly until the queue is shut down.  And we all know how to do that:

for value in queue do
  process(value);

Except that if you try to do that, the compiler will complain at you.  There’s no enumerator.  For some strange reason, out of all the collections in Generics.Collections, TThreadedQueue<T> alone does not descend from TEnumerable<T>.

Oh well.  It’s not all that hard to add an enumerator to a class that doesn’t have one.  Just use a class helper.

TThreadedQueueEnumerator<T> = class
  private
    FQueue: TThreadedQueue<T>;
    FCurrent: T;
    function GetCurrent: T;
  public
    constructor Create(queue: TThreadedQueue<T>);
    property Current: T read GetCurrent;
    function MoveNext: Boolean;
  end;

  TThreadedQueueHelper<T> = class helper for TThreadedQueue<T>
  public
    function GetEnumerator: TThreadedQueueEnumerator<T>;
  end;

implementation

{ TThreadedQueueEnumerator<T> }

constructor TThreadedQueueEnumerator<T>.Create(queue: TThreadedQueue<T>);
begin
  FQueue := queue;
end;

function TThreadedQueueEnumerator<T>.GetCurrent: T;
begin
  result:= FCurrent;
end;

function TThreadedQueueEnumerator<T>.MoveNext: Boolean;
begin
  result := FQueue.PopItem(FCurrent) = wrSignaled;
end;

{ TThreadedQueueHelper<T> }

function TThreadedQueueHelper<T>.GetEnumerator: TThreadedQueueEnumerator<T>;
begin
  result := TThreadedQueueEnumerator.Create(self);
end;

Well, that was easy.  That’s probably the simplest enumerator I’ve ever written, because of the way the queue’s design makes it easy to implement MoveNext.  Except… that doesn’t compile either.  Apparently you can’t put generic type parameters on a class helper, which means that as far as I can tell, you can’t apply a class helper to a generic class at all.

I suppose I could subclass it and add the enumerator that way, but TEnumerableThreadedQueue<T> is a bit of a bulky name, don’t you think?  I have to wonder why the enumerator was left off of this collection, though, especially since the standard enumerator pattern is basically the only reasonable way to use a class like this…

What’s wrong with this code?

procedure TMyCustomChecklistPopupControl.ClosePopup;
var
  i: integer;
begin
  inherited ClosePopup;
  FInternalItemStringList.Clear;
  for i := 0 to Self.CheckedCount - 1 do
    FInternalItemStringList.Add(Self.CheckedItems[i].Name);
end;

Continue reading ‘TStringList updating pitfalls’ »

My friend and coworker François Gaillard recently set up a tech blog over at fgaillard.com.  I just ran across an interesting post about using inherited; in Delphi, and since he’s not listed on DelphiFeeds yet, I figured I’d link to it here.  He’s a pretty talented engineer with a good mind, so you can expect to see some good observations over there if he keeps at it.  (He also gave a very interesting session at Delphi Live this year about speech technology, and anyone who can get an English version of Windows to understand his thick Inspector Clousseau accent obviously knows a thing or two about bending a computer to his will!)

Also, just in case anyone hasn’t seen it yet, (this isn’t quite as recent,) Nick Hodges has a blog again, over at nickhodges.com, and it’s not on DelphiFeeds yet either.  I figured I’d post a link here, since one good shout-out deserves another.

The last few versions of MS SQL Server have included a feature where you can create new functions in .NET assemblies and register them with the database server. This can be a good way to deal with concepts that are difficult to express in T/SQL, and it can provide some big performance boosts. The process is not without its warts, though. Continue reading ‘When is a null not a null?’ »