YAPB

I’m proud to announce the 0.3 version of DeHL library. This release focused on bug-fixes and extensions to type support engine. This version should pretty much stabilize what I started and should leave me more time to extend other interesting parts of the library such as collections.

For those who are new, DeHL is a project of mine designed to fill in some holes in the Delphi’s RTL — most notably, some centralized and OOP-ish Date/Time support, more generic collection classes and “big integer” math support. DeHL also builds up a new layer of “type support” which is very useful to abstract all type management tasks in generic classes. This projects only supports Delphi 2009 (and above) since Generics, Anonymous methods, and Unicode are widely used whithin the library. So even if you are not interested in the library itself, it may prove a good read if you are interested in all new features Delphi 2009 has to offer.

New features:

• Type support classes now expose methods to convert a type from an to a Variant.
• Based on the newly added Variant conversion, a new type: TConverter<T1, T2> is present. You can use it to support “blind” conversion in a class.
• Much improved type support system
  • Now more functionality is split between generic and non-generic variants of the type support classes (IType, IType<T>, TType, TType<T>).
  • TypeSupport has been renamed to TType and IType repectively.
  • IType/TType now export Name, Size, Management, TypeInfo and Family properties. You can use those properties to get more information about your generic type.
  • Custom type registration has been improved. A new cleaner API can be used to register you custom types into the DeHL’s type system.
  • TType<T>.Default is now an overloaded function. The first form is the usual one. The second form receives a set of “type families” that are expected to represent the generic type. This way you can effectively impose run-time type restrictions.
  • TClassType is now generic with T being class-restricted. This allows to avoid compile-time type incompatibilities.
• All important standard types in Delphi are now supported. This support required the working custom types system, since these types can’t be handled “by default“:
  • Boolean, ByteBool, WordBool, LongBool
  • TDateTime, TTime, TDate
  • NativeInt, NativeUInt
  • Real
  • OleVariant
  • UCS4Char, UCS4String
  • UTF8String
  • RawByteString

Bug fixes:

• Fixed a bug in BigCardinal and BigInteger variant types related to string conversion.
• A few changes in TDictionary to avoid compiler problems.
• In a multi-threaded environment, the custom type support would not unlock properly leading to a dead-lock.
• Cleanup routines for TDictionary and THashSet were flawed since those used FillChar to clear the array. Managed types had problems with that.
• Char type support class now acts properly.

Note: It may be possible that the Testing project will not compile due to a bug in the Delphi compiler. But that should not prevent the usage of the library itself.

The download section can be found here.

Testing feeds. Ignore me!

Did I catch your attention? I guess I did if you are reading this. Just to be clear, I don’t hate integers — I hate using integers (a.k.a. signed numbers) where they don’t make sense. For example let’s take the standard intrinsic routine called Length (in System unit). It returns the length of an array (or string) in format of a signed 32-bit integer. While I doubt anyone will use 2 gigs of memory for an array, this still breaks the prettyness of the code. Almost all routines that need an unsigned integer still require a signed one. And this is not limited only to Delphi — most of the .NET libraries use “int” when they should use “uint” (I’m not even going to mention Java here! Last time I checked there was no concept of “unsigned” in it).

Anyway, being as I am, I always try to use the Cardinal type when I do not require the negative values. For instance iterating in a FOR loop from 0 (zero) to a length of an array. This doesn’t benefit me in any way, aside of personal satisfaction. It even tends to “bite me in the ass” sometimes. Let’s take this example:

function MakeString(const AChar: Char;
  const ACount: Cardinal): String;
var
  I: Cardinal;
begin
  Result := '';

  for I := 0 to ACount - 1 do
    Result := Result + AChar;
end;

begin
  WriteLn('Str1 = ', MakeString('A', 2));
  WriteLn('Str2 = ', MakeString('B', 0));

  ReadLn;
end.

What will this program write on the console? I bet you though it would be: “Str1 = AA” and “Str2 = “. Think again, but this time harder.

Now let me explain what is really going on:

1. I pass 0 as the ACount parameter to the MakeString function.
2. I use a Cardinal data type for my FOR loop.
3. I start at 0 and go to ACount – 1.
4. ACount being 0, the upper bound of the FOR loop becomes (0 – 1) =4294967295.
5. The FOR loop continues for a lot of iterations.
6. You will either run out of memory or get bored waiting for a result…
7. If  I were an Integer the loop would have worked flawlessly.

“I hate integers …”

Not many changes in this release:

• Fixed a bug in BigCardinal related to zero-length numbers
• BigCardinals embedded in variants now properly negate.
• Support for the NOT operation for BigCardinal.
• … As usual some tests.

0.2.3 is based on 0.2.2 and not on the trunk since trunk is seriously damaged. Downloads can be found here.