> (horrible snippet) If that's how you define abstract data types in C, then I'll stick to my current practice of not defining abstract data types in C, for ob

> (horrible snippet) If that's how you define abstract data types in C, then I'll stick to my current practice of not defining abstract data types in C, for obvious reasons. > A common approach is the use of "ops" structures containing function pointers that are filled depending on the type in use. Maybe you're confusing ADTs with objects? They aren't the same thing at all[0]. The point to ADTs is delimiting the scope where implementation details (e.g., whether a set data structure is implemented as a red-black tree or an AVL tree) are relevant. The point to objects is deferring until runtime the decision to use this or that implementation (e.g., callbacks). ADTs in general needn't pay an indirection tax. And using objects when ADTs suffice for your modularity purposes is a sign of being a very stupid programmer. [0] http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf > If you still pick C for writing your program, you probably don't mind it or have some other reason for sticking with C. The latter.