DeHL 0.3 is out

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.

Just a few points:
– I tried to build it with HPP generation enabled, but BCC doesn’t swallow many things in the headers, mainly because of QC’s #71288, #73543, #73545 and #73546.
– Why did you disable function inlining?
– Did you suggest to use your library as an internal stress test for DCC’s generics and HPP generation? If not, please do it

I do. Not all of your classes are generic, and even those should be possible to access from C++, e.g. if you’re dealing with a Delphi unit that uses them in the interface section.
FWIW, three of the four reports I mentioned above are not related to generics.