Richard R wrote:
> in vc++ there are a number of structures with pointers to those structures,
> and they are empty.
>
> typedef struct tsxSOBJ { };
>
> in the API such stuctures are referenced as pointers *tsxSOBJ
That's common idiom for creating distinct handle types. It forces the
compiler to generate error messages that mention the given struct name
instead of always talking about void* types (THandle in Delphi).
> If I had to do this in delphi, i would have to type cast everything (if
> possible) like I would in vc++
>
> The function I'm refering to is a function in the API of the host
> application. It checks if a pointer to a geometry object is a metaball
> primitive and returns true or false. It also returns the parent (metaball)
> in one of the parameters, yet it returns nil if a nil is passed in there and
> that's where the problem is.
When you pass a nil reference to a geometry object, what else would you
expect it to return for that object's parent? There is no object, so how
could there be a parent?
> However this is something the company has to
> fix. So if i built the structures in delphi (records), itd be pointless
> since there is nothing in there to work with, which is why I'm using type
> pointer. It works just fine, except in faulty functions.... which is kinda
> like faulty towers, one bad move and it's a bloody mess. =P
You'd be using pointers either way. But by defining the records, your
pointer types will be pointers to those record types instead. It lets
you know, just by looking at a variable's declaration, why kind of thing
it holds. If everything's a pointer, then you can assign anything to
anything else, and the compiler can no longer do any meaningful
type-checking.
Type-casting isn't necessarily a bad thing. It highlights places in your
code where you're treating data of one type as though it's data of
another type. Places where you change something's type are places for
errors, and it's better not to hide those places by removing the type-casts.
--
Rob
__________________________________________________
Delphi-Talk mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi-talk
