Skip to main content
conclusion
Source Link
Neil
  • 1.1k
  • 8
  • 18

I have only questions, but maybe some of these are useful.

  • It is desirable to fail fast and in a predictable manner to improper LINKEDLIST_GENERATE commands, maybe with a comment saying what's wrong.
  • LINKEDLIST_GENERATE_HEADER_PUBLIC, etc is probably too confusing; could it could be simplified? You include FMOD; these defines appear interconnected.
  • owner for every node is potentially wasteful, are you sure you need it? Same thing, count, are you sure you need it? It makes it so much harder to maintain the proper state.
  • Are you sure that you want to do memory allocation internal to the list? It would be much simpler to hand that over to the user. I see l_new(100), that contradicts PFX##_new(void); not sure what's going on there.
  • Are all of those functions needed? Eg, PFX##_remove_prv, cur, nxt, but the user could easily duplicate pointers.
  • In your examples, it's possible to have a l_new that's null and crash. I'm not sure whether checking the pre-conditions in each function is better, or the user is required to verify that the list is not null, but I think you should document it.
  • Floyd's algorithm provides great cycle-detection with minimal code. Might be useful when you implement splice and concat. Maybe a debug function that checks if it's in a valid state.

I think it's a very valid use of the pre-processor to generate repeated code.

I have only questions, but maybe some of these are useful.

  • It is desirable to fail fast and in a predictable manner to improper LINKEDLIST_GENERATE commands, maybe with a comment saying what's wrong.
  • LINKEDLIST_GENERATE_HEADER_PUBLIC, etc is probably too confusing; could it could be simplified? You include FMOD; these defines appear interconnected.
  • owner for every node is potentially wasteful, are you sure you need it? Same thing, count, are you sure you need it? It makes it so much harder to maintain the proper state.
  • Are you sure that you want to do memory allocation internal to the list? It would be much simpler to hand that over to the user. I see l_new(100), that contradicts PFX##_new(void); not sure what's going on there.
  • Are all of those functions needed? Eg, PFX##_remove_prv, cur, nxt, but the user could easily duplicate pointers.
  • In your examples, it's possible to have a l_new that's null and crash. I'm not sure whether checking the pre-conditions in each function is better, or the user is required to verify that the list is not null, but I think you should document it.
  • Floyd's algorithm provides great cycle-detection with minimal code. Might be useful when you implement splice and concat. Maybe a debug function that checks if it's in a valid state.

I have only questions, but maybe some of these are useful.

  • It is desirable to fail fast and in a predictable manner to improper LINKEDLIST_GENERATE commands, maybe with a comment saying what's wrong.
  • LINKEDLIST_GENERATE_HEADER_PUBLIC, etc is probably too confusing; could it could be simplified? You include FMOD; these defines appear interconnected.
  • owner for every node is potentially wasteful, are you sure you need it? Same thing, count, are you sure you need it? It makes it so much harder to maintain the proper state.
  • Are you sure that you want to do memory allocation internal to the list? It would be much simpler to hand that over to the user. I see l_new(100), that contradicts PFX##_new(void); not sure what's going on there.
  • Are all of those functions needed? Eg, PFX##_remove_prv, cur, nxt, but the user could easily duplicate pointers.
  • In your examples, it's possible to have a l_new that's null and crash. I'm not sure whether checking the pre-conditions in each function is better, or the user is required to verify that the list is not null, but I think you should document it.
  • Floyd's algorithm provides great cycle-detection with minimal code. Might be useful when you implement splice and concat. Maybe a debug function that checks if it's in a valid state.

I think it's a very valid use of the pre-processor to generate repeated code.

Source Link
Neil
  • 1.1k
  • 8
  • 18

I have only questions, but maybe some of these are useful.

  • It is desirable to fail fast and in a predictable manner to improper LINKEDLIST_GENERATE commands, maybe with a comment saying what's wrong.
  • LINKEDLIST_GENERATE_HEADER_PUBLIC, etc is probably too confusing; could it could be simplified? You include FMOD; these defines appear interconnected.
  • owner for every node is potentially wasteful, are you sure you need it? Same thing, count, are you sure you need it? It makes it so much harder to maintain the proper state.
  • Are you sure that you want to do memory allocation internal to the list? It would be much simpler to hand that over to the user. I see l_new(100), that contradicts PFX##_new(void); not sure what's going on there.
  • Are all of those functions needed? Eg, PFX##_remove_prv, cur, nxt, but the user could easily duplicate pointers.
  • In your examples, it's possible to have a l_new that's null and crash. I'm not sure whether checking the pre-conditions in each function is better, or the user is required to verify that the list is not null, but I think you should document it.
  • Floyd's algorithm provides great cycle-detection with minimal code. Might be useful when you implement splice and concat. Maybe a debug function that checks if it's in a valid state.