Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

metamodular.com

Post reply on HN
Print view View original

11–20 of 35 posts

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

#11

Post by caseymarquis »

notacoward wrote: post #7
kccqzy wrote: 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?

Generic collections in C implemented with macros are so heinous, I think this comparison may actually be fairer to C. I say that as an abuser of C macros, and someone who genuinely likes C.

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

#12

Post by AnimalMuppet »

badsectoracula wrote: post #6
kccqzy wrote: 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.

It depends on what you want. If you want to be able to see everything, then the C++ code is better. If you want to get the trees out of the way so that you can see the forest, the C++ code is better.

And, for most of us, if you want to just write it and have it work, the C++ code is better. Sure, I might have to find an example of the iterator code in order to get the syntax right, but it's a lot easier to mess up the double indirect pointer code. Worse, when I mess up the iterator code, it likely doesn't compile. If I mess up the double indirect pointer code, it it likely to silently corrupt memory somewhere.

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

#13

Post by WalterBright »

kccqzy wrote: 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…

Forgot to check for null return from malloc().

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

#14

Post by notacoward »

caseymarquis wrote: post #11
notacoward wrote: post #7

Earlier quoted context omitted.

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

Generic collections in C implemented with macros are so heinous, I think this comparison may actually be fairer to C. I say that as an abuser of C macros, and someone who genuinely likes C.

Not a huge fan of those kind of macros myself, because they still leave too much of the implementation exposed. The other alternative is pointer-arithmetic implementations, which do hide the implementation better but often come with limitations (e.g. list members have to be first and you can't be on two lists at once). But either way, that's C for you. The language has its limitations, and there's only so much you can do. Comparing that to an API in a language with better support for such things seems a bit unfair and snobbish. It's like comparing a matrix-math API in a language where it's native to the guaranteed-horrific internals of a C++ library to do the same thing.

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

#15

Post by jcelerier »

badsectoracula wrote: post #6
kccqzy wrote: 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.

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

but why do you want to spend time parsing code that

- does textbook-level things ?

- has a thousand different places where a typo can end up

- needs to be rewritten for every kind of list

those are the red flags. Do you also go read your graphics driver's code when you push pixels to the screen ?

> and also very ugly (i never liked C++'s iterators).

ignoring the jump from what you like to a global assertion (the C version makes my eyes bleed), in C++ 20 you can also just do

    list.insert(std::lower_bound(list, val), val);

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

#16

Post by attractivechaos »

notacoward wrote: post #14
caseymarquis wrote: post #11

Earlier quoted context omitted.

Generic collections in C implemented with macros are so heinous, I think this comparison may actually be fairer to C. I say that as an abuser of C macros, and someone who genuinely likes C.

Not a huge fan of those kind of macros myself, because they still leave too much of the implementation exposed. The other alternative is pointer-arithmetic implementations, which do hide the implementation better but often come with limitations (e.g. list members have to be first and you can't be on two lists at once). But either way, that's C for you. The language has its limitations, and there's only so much you ca…

For double-linked list, a better choice is to use intrusive data structures. Cleaner and more flexible than both macros and void pointers. However, only double-linked list and binary search trees, to a lesser extend, can be implemented with intrusive data structures.

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

#17

Post by xvilka »

At this point it's better just to convert the code into the proper modern programming language without all C drawbacks - Rust. Amazing c2rust[1] tool offers automated conversion[2] and refactoring[3] capabilities. It even allows you to script[4] the refactoring with Lua. All while preserving ability to run and (probably) pass the tests.

[1] https://github.com/immunant/c2rust

[2] https://c2rust.com/manual/quickstart.html

[3] https://c2rust.com/manual/c2rust-refactor/index.html

[4] https://c2rust.com/manual/c2rust-refactor/doc/scripting_api....

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

#18

Post by kccqzy »

notacoward wrote: post #7
kccqzy wrote: 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?

My point is, C doesn't give you enough tools to build an elegant, easy-to-use interface, so people reimplement things over and over again. So in typical application code you see people using the "interface" in C++ but manually inlining the "implementation" in C. And what's why it is a fair comparison.

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

#19

Post by zik »

xvilka wrote: post #17

At this point it's better just to convert the code into the proper modern programming language without all C drawbacks - Rust. Amazing c2rust[1] tool offers automated conversion[2] and refactoring[3] capabilities. It even allows you to script[4] the refactoring with Lua. All while preserving ability to run and (probably) pass the tests. [1] https://github.com/immunant/c2rust [2] https://c2rust.com/manual/quickstart.h…

> the proper modern programming language

I understand wanting to advocate for your favorite programming language but this kind of elitist attitude doesn't do the cause any favors, it's more likely to turn people away than anything.

Rust is not "the proper programming language". It's just one of many excellent choices.

Post reply on HN