Live data from Hacker News

Modular C: Reusable and Maintainable Code Using the C Language (1994) [pdf]

metamodular.com

1–10 of 35 posts

Re: Modular C: Reusable and Maintainable Code Using the C Language (1994) [pdf]

#3
"System programming differs from application programming in that system programming emphasizes performance over reusable and maintainable code"

Maybe for sufficiently small systems. But on a large scale product (reusable and maintainable code == performance). Am I missing something. Seems like something one or our EEs would say to me to excuse their poor code quality

Re: Modular C: Reusable and Maintainable Code Using the C Language (1994) [pdf]

#4
post #3

"System programming differs from application programming in that system programming emphasizes performance over reusable and maintainable code" Maybe for sufficiently small systems. But on a large scale product (reusable and maintainable code == performance). Am I missing something. Seems like something one or our EEs would say to me to excuse their poor code quality

> Am I missing something Copyright 1994. C89 only, this predates C99... The year ought to be in the title.

Re: Modular C: Reusable and Maintainable Code Using the C Language (1994) [pdf]

#5
This is old-fashioned (uses C89 instead of C99) and some of its "idioms" are questionable, like this one:

    list *p;
    list l = (list) malloc(sizeof(struct list));
    l -> val = val;
    for(p = &the_list; *p && (*p) -> val  next))
      ;
    l -> next = *p; *p = l;
Here p is a doubly indirect pointer and I would personally think this is an unwarranted cleverness.

Furthermore this is the year 2019. Why would you still manually traverse a linked list? Oh right because C doesn't have parametric polymorphism (genericity) so you can't abstract out the traversal in a standard library.

Consider the C++ equivalent (although I chose to use a doubly linked list for better reusability):

    list.insert(std::lower_bound(list.begin(), list.end(), val), val);
See how the search for the location to insert is done by the library, and the insertion is also done by the library. This, to me, is truly reusable and maintainable code.

Re: Modular C: Reusable and Maintainable Code Using the C Language (1994) [pdf]

#6
post #5

This is old-fashioned (uses C89 instead of C99) and some of its "idioms" are questionable, like this one: list *p; list l = (list) malloc(sizeof(struct list)); l -> val = val; for(p = &the_list; *p && (*p) -> val next)) ; l -> next = *p; *p = l; Here p is a doubly indirect pointer and I would personally think this is an unwarranted cleverness. Furthermore this is the year 2019. Why would you still manually traverse a…

FWIW personally i prefer the C code. It is explicit at what it does, whereas the C++ one is harder to follow exactly what it does - and also very ugly (i never liked C++'s iterators).

The double indirect pointer is hairy but at least everything you need to know to "parse" the code is right there.

Re: Modular C: Reusable and Maintainable Code Using the C Language (1994) [pdf]

#7
post #5

This is old-fashioned (uses C89 instead of C99) and some of its "idioms" are questionable, like this one: list *p; list l = (list) malloc(sizeof(struct list)); l -> val = val; for(p = &the_list; *p && (*p) -> val next)) ; l -> next = *p; *p = l; Here p is a doubly indirect pointer and I would personally think this is an unwarranted cleverness. Furthermore this is the year 2019. Why would you still manually traverse a…

You're comparing an implementation to an interface. Do you really think that's valid?

Re: Modular C: Reusable and Maintainable Code Using the C Language (1994) [pdf]

#8
post #5

This is old-fashioned (uses C89 instead of C99) and some of its "idioms" are questionable, like this one: list *p; list l = (list) malloc(sizeof(struct list)); l -> val = val; for(p = &the_list; *p && (*p) -> val next)) ; l -> next = *p; *p = l; Here p is a doubly indirect pointer and I would personally think this is an unwarranted cleverness. Furthermore this is the year 2019. Why would you still manually traverse a…

> Furthermore this is the year 2019. Why would you still manually traverse a linked list? Oh right because C doesn't have parametric polymorphism (genericity) so you can't abstract out the traversal in a standard library.

You actually can. But it takes some clever allocation tricks to precede the object allocated by the list struct. There usually is 'a way' to do it in C but it is hardly ever an elegant one.

Re: Modular C: Reusable and Maintainable Code Using the C Language (1994) [pdf]

#9
post #5

This is old-fashioned (uses C89 instead of C99) and some of its "idioms" are questionable, like this one: list *p; list l = (list) malloc(sizeof(struct list)); l -> val = val; for(p = &the_list; *p && (*p) -> val next)) ; l -> next = *p; *p = l; Here p is a doubly indirect pointer and I would personally think this is an unwarranted cleverness. Furthermore this is the year 2019. Why would you still manually traverse a…

It's sort of funny that linus torvalds actually talked about why that sort of iteration is better: https://youtu.be/o8NPllzkFhE?t=861

I think he puts it pretty well (although he them also goes on to say dumb little snippets like that really don't matter in the big picture). Essentially, by making a doubly indirect pointer you get to treat the first element exactly the same way you are going to treat every other element.

Re: Modular C: Reusable and Maintainable Code Using the C Language (1994) [pdf]

#10
post #5

This is old-fashioned (uses C89 instead of C99) and some of its "idioms" are questionable, like this one: list *p; list l = (list) malloc(sizeof(struct list)); l -> val = val; for(p = &the_list; *p && (*p) -> val next)) ; l -> next = *p; *p = l; Here p is a doubly indirect pointer and I would personally think this is an unwarranted cleverness. Furthermore this is the year 2019. Why would you still manually traverse a…

It's sort of funny that linus torvalds actually talked about why that sort of iteration is better: https://youtu.be/o8NPllzkFhE?t=861 I think he puts it pretty well (although he them also goes on to say dumb little snippets like that really don't matter in the big picture). Essentially, by making a doubly indirect pointer you get to treat the first element exactly the same way you are going to treat every other eleme…

However, Linus would object to hiding the true type of list (it's actually a pointer) --- as do I, since I was a little confused by that fragment at first, wondering what exactly was doubly indirected about it. It looks very different from the usual implementation of a "virtual head", which uses a single-indirect pointer only.
Post reply on HN