dce/rpc "client" api

[Cole, Timothy D.]

> -----Original Message-----
> From:	David Allan Finch [SMTP:david.allan at finch.org]
> Sent:	Friday, August 18, 2000 5:56
> To:	Multiple recipients of list
> Subject:	Re: dce/rpc "client" api
> 
> Luke Kenneth Casson Leighton wrote:
> 
> > p.s. if you are in contact with the X windows developers, please tell
> > them i said that this is dodgy approach!
> 
> Interesting this technique has been in uses since at least 1985 and
> X has been compiled on a large number of system with an even
> large number of C compilers.  If you are really worried about it
> I can check with some of the people that where on the C++
> committee about where it is guaranteed to work. My gut feeling
> it it is.
> 
> Personally I would have don't it as a struct with an int type
> field and a union. I.E. {pseudoC}
> 
> enum XEventType { blar1, blar2, blar3 };
> 
> union XEventData
>     {
>     XAnyEvent any;
>     XAnotherEvent somethingelse;
>     };
> 
> struct XEvent
>     {
>     XEventType type;
>     XEventData data;
>     };
> 
	I used to do this sort of code a lot, but I've started to realize
that if you have to use a "type" field to indicate which type a union is,
you're setting yourself up for a maintainence (and sometimes performance)
headache.  A union should basically "know" its type, so that the code that
actually cares which it is is more localized.

	Once you introduce a type field, you start having to sprinkle switch
statements througout your code, all of which have to be invidiually
maintained.  Putting the union in a struct with a vtable instead of a type
field makes more sense, but at that point you realize something like the GTK
system (base structure + casting) is more readable than using unions (as
well as saving memory).

	There _are_ a few times I've used unions lately when it was really
the simplest way to go, but none of those required a type field, either --
the type of the union could be inferred entirely from the context in which
it was being used.

	Just my $0.02