31–35 of 35 posts
Earlier quoted context omitted.
> 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.
You're absolutely right. These people have seriously marred my view of the language.
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…
A a pointer to a pointer is a perfectly valid C idiom. I'd say typedef'ing a pointer would raise more eyebrows :) E.g. I have a singly-linked list of struct x { int y; struct x* next }; I want to locate an element here and then maybe remove it (1), maybe insert a new one before (2) or after (3), maybe replace (4), or maybe just return what I've found (5). How do I write this base locator function? If I do it naively…
Yes, but you'll use merge instead:
list.merge(std::forward_list{val});
> Also, look: your C++ example calls four methods. The C code calls only one (malloc), all the rest is core language. It's 4:1 ratio for extra complexity.
This is what I call unnecessary manual inlining and reinventing the wheel for no good reason.
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 pretty easy to make something like this work:
list_insert(&itemList, struct Item, &item, &compare_item);
#define list_insert(list, type, item, compare) \
__list_insert((list), \
sizeof (type), __alignof(type), \
(item), (compare))
DEFINE_LIST_FUNCS(itemList, struct ItemList, compare_items);
itemList_insert(&itemList, &item);
Earlier quoted context omitted.
A a pointer to a pointer is a perfectly valid C idiom. I'd say typedef'ing a pointer would raise more eyebrows :) E.g. I have a singly-linked list of struct x { int y; struct x* next }; I want to locate an element here and then maybe remove it (1), maybe insert a new one before (2) or after (3), maybe replace (4), or maybe just return what I've found (5). How do I write this base locator function? If I do it naively…
> By the way, will your C++ code work with singly-linked lists? Yes, but you'll use merge instead: list.merge(std::forward_list {val}); I chose to use std::lower_bound for binary search. If you are content with linear search like in the C example, you can even write a single function that works for both doubly linked lists and singly linked lists. > Also, look: your C++ example calls four methods. The C code calls on…
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().
You'd never object "forgot to catch std::bad_alloc from new'ing", would you?