3 ms·
> (0) Forward declarations are the only way not to explicitly reveal the representation of types, but you have to pay an indirection tax for it, whether you act
by slrz 9y ago
> (0) Forward declarations are the only way not to explicitly reveal the representation of types, but you have to pay an indirection tax for it, whether you actually need indirection or don't.
If you don't want the indirection, you need to declare at least size and alignment requirements. So why not go ahead and just do that.
struct typename {
uchar xxx[THE_SIZE];
} __attribute__((aligned($your_alignment)));
If your compiler doesn't support such alignment specification, there are ways to work around that.
> (2) Again, without heavily abusing the preprocessor, there is no way to make common algorithms work on abstract data types that have a common interface.
There are. Look at any bigger C project to discover them. A common approach is the use of "ops" structures containing function pointers that are filled depending on the type in use.
Yes, doing all of this manually tends to be more cumbersome than it might be using other more modern languages. Just as manual memory management tends to be more painful than working in a proper garbage-collected environment.
If you still pick C for writing your program, you probably don't mind it or have some other reason for sticking with C.
- catnaroek 9y ago> (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.