TURBU Tech

In my first look at Delphi XE, I wrote:

Oh, and apparently certain aspects of the compiler have slowed down.  Most things will compile about the same speed or even a little faster, but for really large projects (millions of lines) with complex interdependencies between units, you’ll notice some slowdown, and it’ll apparently get worse the larger your project is.  I timed it at work, on a project of about 3.5 million lines of code.  It builds in about 2 minutes on D2010, closer to 3 minutes on XE.  Bad, but still a heck of a lot better than the C family could do.  And apparently it has something to do with making Generics work right, so I can tolerate that.  Hopefully they’ll find some way to regain some of that lost speed in updates, though.

Well, I finally got around to installing XE Update 1 at work today, and I timed the build.  2:13. Continue reading ‘XE Update 1: you win some, you lose some’ »

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:

[code lang="delphi"]
for value in queue do
  process(value);
[/code]

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.

[code lang="Delphi"]
  TThreadedQueueEnumerator = class
  private
    FQueue: TThreadedQueue;
    FCurrent: T;
    function GetCurrent: T;
  public
    constructor Create(queue: TThreadedQueue);
    property Current: T read GetCurrent;
    function MoveNext: Boolean;
  end;

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

implementation

{ TThreadedQueueEnumerator }

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

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

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

{ TThreadedQueueHelper }

function TThreadedQueueHelper.GetEnumerator: TThreadedQueueEnumerator;
begin
  result := TThreadedQueueEnumerator.Create(self);
end;
[/code]

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…

One of the hallmarks of a society that values freedom is the concept of Rule of Law, which basically means that people, even the people in charge, can’t just arbitrarily decide that they don’t like what someone else is doing and act to stop them or punish them for it.  Instead we have laws that explain what’s not allowed, what the punishment for breaking them is, and how they are to be administered.  That administration part is important.  It means that if my neighbor steals something from me, I can’t go and throw him in prison, even if the punishment for it is prison time, because I’m not a law enforcement official.

In fact, we have laws that specifically say that if someone breaks the law, I’m not allowed to punish them for it, even if I was directly harmed by their actions, because I don’t have the authority to enforce the law.  People who attempt to do so are known as vigilantes, and their actions are usually illegal, because vigilante justice is flawed in several fundamental ways.  First, it’s not always easy to know if you’ve got the right guy.  Second, even if you do have the right guy, you don’t know if there are extenuating circumstances for them having done what they did.  (This idea goes a very long way, even to the most serious of crimes.  It’s why there’s a legal distinction between “murder” and “killing in self-defense,” for example.)  And third, even if you have the right guy and you know that they acted maliciously, what you might think of as a proper punishment for the crime may be way over the top, especially if you’re the injured party.  This is why trials for particularly severe and shocking crimes are often held in a different community from where it was committed, to make it possible (or at least easier) to get an impartial jury with no personal stake in the matter.

What does this have to do with software?  Well, if you’ve been following DelphiFeeds lately, you can probably guess. Continue reading ‘Rule of Law, software, and stray cows’ »

There’s been a lot of talk in the last few years about major language features that Delphi doesn’t have.  Stuff like Unicode and Generics which finally got added in D2009, stuff like 64-bit compilation that’s perenially slated for another year or two out, and so on.  There’s currently a major debate going on (and on and on) in the Delphi forums about the team’s statement that the next release won’t include inline assembly, and the effects that that will or won’t have on library compatibility and future development.

But there are also more minor, simple things that we don’t have, and some of them are a little bit silly. Continue reading ‘Why don’t we have this?’ »