Remember this code is for VB6. It isn't going to work anywhere else without major work, UDTs or no UDTs.
The reasons to use UDTs are exactly the same.Remember this code is for VB6. It isn't going to work anywhere else without major work, UDTs or no UDTs.
Not according to #20.The reasons to use UDTs are exactly the same.
#20 was but one good reason to use them. It was not all inclusive by any means. We all agree that abstraction for the hell of it is useless and I personally dislike OOP in the embedded domain.Not according to #20.
Disagreement warmly welcomed, but I did specifically say that user-defined types are a good thing for library APIs, e.g., FILE and clock_t.I certainly don't want to always see what the actual data types are at the point of use within, for instance, the FILE abstract data type.
Yes, you did. Part of the point I was trying to make is that a lot of user-defined code is properly treated as library APIs.Disagreement warmly welcomed, but I did specifically say that user-defined types are a good thing for library APIs, e.g., FILE and clock_t.
Typically, once in a datatype, you use that datatype. Like using P.X instead of X.Now suppose that the calling routine has calculated the individual values. You then need to add this before the call:
P1.x = X1;
P1.y = Y1;
P2.x = X2;
P2.y = Y2;
then the call:
P = intersect(P1, P2);
Then after the call you need to extract the return values:
X = P.X;
Y = P.Y;
Now it doesn't look like much of an improvement.