Using Object Pointers in a DataSet TField

I have seen code where an object pointer is stored in each row of a TDataSet, and referenced by code.  So skipping the question of the validity of such code, how do you support X86 and X64 bit code, especially if you use persistent TFields (use Delphi’s Form Designer RAD approach for the UI)?

For 32 bit development a TIntegerField works just fine.  Compile for Win64 (the OS/X compiler still doesn’t support 64 bit code) and everything seems fine until you run the app and exercise the code to find an AV.

A NativeInt scalar type is variable depending on the word size of the CPU, but there is no equivalent TField descendant (TNativeIntField), so you are forced to choose a different TNumericField descendant depending on your target (32 or 64 bit) or one that can support both.  The TLargeIntField uses a largeint (equivalent to an Int64) for internal field storage so it is the only possible choice that could support both targets and still provide design-time support.  The overhead of such an approach is questionable.  Otherwise, if you create the fields in code I would suggest conditional compilation using the CPUX64/CPUX86 directives.

If you need to support 64 bit targets I would also suggest development using Win64 so you don’t have to test each pathway for a 32 bit application to ensure it runs fine as a 64 bit EXE.

3 Responses to “Using Object Pointers in a DataSet TField”

  1. skamradt Says:

    unfortunately I have seen this practice more times that I care to. One other thing to be aware of, that pointers CAN have negative values even in the 32bit space. Pointers are unsigned, so any test against them should be against 0 not greater than 0. This is one of those bugs that you won’t see in dev environment with a few records, but likely to hit once your system is put under stress at your largest client.

    Also be aware of conversions at this larger space. a negative INT when converted to an INT64 will NOT be bitwise identical, so you MUST use extreme caution and make sure that ALL of your routines that are dealing with the field are dealing with it properly.

  2. Joseph Says:

    >So skipping the question of the validity of such code,

    But … but… but… you can’t tease us with this description and then not tell us for what nightmarish purpose it was intended!

  3. Larry Hengen Says:

    @Joseph,

    It was to store a pointer to the MVVM view model for the current dataset row. Not a very scalable technique, and as it turns out not a very portable one either.

Leave a Reply