Binary Trees in C

[Karl Heuer]

In article <1990Mar16.112415.803 at hellgate.utah.edu> kbreinho%ug.utah.edu at cs.utah.edu (Keith Breinholt) writes:
>In article <23127 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
>>As for your binary tree implementation: I would likely use pointers to
>>pointers, but then I write declarations like
>>	int (*(*bloog[10])(char *, void (*)(int, int (*)(void))))[4];
>>without flinching. :-)
>
>... Do you really think someone would want to [maintain] crap like that?

Actually, I have to agree.  Since a pointer-to-entire-array is so much weaker
than a pointer-to-element, I would assume that the existence of even a single
function returning such a type (not to mention an array of pointers to such
functions) is evidence that, in this project, "int[4]" is an important
construct and should probably have had its own typedef.

Of course, that has to have been an exaggerated example--did you miss the
smiley?  A more serious example would be
	extern void (*signal(int, void (*)(int)))(int);
, which is probably the most complex declaration you'd encounter in practice.
Though I personally don't bother with "typedef void (*sighandler_t)(int)", I
don't look down on those who do.

But for the original problem, a pointer-to-pointer seems to be the natural
solution, and anybody who can't understand such a construct needs to practice
a bit more before trying to write production-quality code.

Karl W. Z. Heuer (karl at ima.ima.isc.com or harvard!ima!karl), The Walking Lint