3 ms·
This is a well known trade-off - your data structures affect the design and therefore run time profile of your algorithm. A tightly coupled data structure is m
by vampirechicken 14y ago
This is a well known trade-off - your data structures affect the design and therefore run time profile of your algorithm.
A tightly coupled data structure is more efficient in time and memory, but harder to reuse, and makes it harder modify the code. A more general data structure is easier to reuse and makes it easier to modify the code, at the expense of time and memory at run time.
We use a combination of Moore's Law, and the cost of a programmer to justify the less efficient general solution in the near term, and explain that we'll optimize hot spots later. This mostly works. The Author has found himself lamenting this choice in piece of high-performance software.
If he has few lists, then coding the doubly-linked list pointer directly in to his structs is the way to go. If he has many lists, I'd suggest using the cpp or m4 (or some other templating tool) to statically generate doubly-linked lists at complile time.
- rumcajz 14y agoMy point was that the trade-off is not something unavoidable. A better language could allow you to syntactically decouple the tightly coupled objects. See the example at the end of the article.
- dkersten 14y agoA better language could allow you to... And yet C is not this language.
- mpyne 14y agoAnd even if it was, C++ is nearly a superset of C. Write the part in C-style code which works best in C and then move on with your life...
- vampirechicken 14y agoI was actually agreeing with you, and elaborating on what you talked about. I went back and read the bottom of the article. The Design Pattern people might call that a decorator. The ruby folks would use a mixin to monkey patch the person class. You're in good company. The trade-offs are still code complexity + programmer time vs. memory use + run time. The more general you make something, the more overhead at run time.