История изменений

Ну, вижу. И каких комментариев ты ждёшь? Сделано в целом приемлемо, но сфера применения не совсем понятна.

Хотя, list_free может например молча устроить memory leak. А если он за этим не следит, то непонятно зачем вообще функция обёртка над двумя free. А да, нашёл внизу list_free_items_and_destroy, но тогда новые вопросы:

1) почему тогда list_free не static, раз уж её сделали отдельной, а показывать наружу надо вторую?

2) получается этот list годится только как список плоских блоков данных, аллоцированных malloc-ом, сложное в него пихать нельзя, а если и пихать - придётся нарушать и так неважную инкапсуляцию и реализовывать где-то снаружи альтернативное list_free_items_and_destroy.

А ещё я бы не стал аллоцирование самого list_t сюда вообще включать, т.к. эта тривиальная структура из 12-16 байт почти не отличается по размеру от указателя размером 4-8 байт, и много где её желательно было бы хранить статически.

Аааа! capacity/length мало того что не size_t так ещё и signed! Стандартный дефект твоих любимых «сишников» в самом плохом смысле этого слова, традиционный для в 80-х годов. (впрочем, признаю, в моём .c файле тоже int не к месту в одном месте, но переполнение в нём невозможно т.к. с ним кроме инкремента от 0 до заранее заданной константы ничего не делается) Нет проверки на переполнение когда capacity умножается на sizeof(void*).

Ну, про realloc ты уже писал. А ещё на мой взгляд разширение массива методом умножения на 2 не всегда хорошо (но это вкусы), и там опять нет проверки на переполнение (а это уже явно плохо).

list_move_to_end() в виде list_del+list_add с одной стороны зрительно замусоривает код, с другой вызывает ненужное list_resize в середине, а могли бы вставить туда memmove + перемещение одного item-а в явном виде.

Дальше лень смотреть.

А да, я не про те списки думал. То что в этом файле я обычно массивами называю. А списками - односвязные или двусвязные.

Ну, вижу. И каких комментариев ты ждёшь? Сделано в целом приемлемо, но сфера применения не совсем понятна.

Хотя, list_free может например молча устроить memory leak. А если он за этим не следит, то непонятно зачем вообще функция обёртка над двумя free. А да, нашёл внизу list_free_items_and_destroy, но тогда новые вопросы:

1) почему тогда list_free не static, раз уж её сделали отдельной, а показывать наружу надо вторую?

2) получается этот list годится только как список плоских блоков данных, аллоцированных malloc-ом, сложное в него пихать нельзя, а если и пихать - придётся нарушать и так неважную инкапсуляцию и реализовывать где-то снаружи альтернативное list_free_items_and_destroy.

А ещё я бы не стал аллоцирование самого list_t сюда вообще включать, т.к. эта тривиальная структура из 12-16 байт почти не отличается по размеру от указателя размером 4-8 байт, и много где её желательно было бы хранить статически.

Аааа! capacity/length мало того что не size_t так ещё и signed! Стандартный дефект твоих любимых «сишников» в самом плохом смысле этого слова, традиционный для в 80-х годов. (впрочем, признаю, в моём .c файле тоже int не к месту в одном месте, но переполнение в нём невозможно т.к. с ним кроме инкремента-декремента в строгих рамках ничего не делается) Нет проверки на переполнение когда capacity умножается на sizeof(void*).

Ну, про realloc ты уже писал. А ещё на мой взгляд разширение массива методом умножения на 2 не всегда хорошо (но это вкусы), и там опять нет проверки на переполнение (а это уже явно плохо).

list_move_to_end() в виде list_del+list_add с одной стороны зрительно замусоривает код, с другой вызывает ненужное list_resize в середине, а могли бы вставить туда memmove + перемещение одного item-а в явном виде.

Дальше лень смотреть.

А да, я не про те списки думал. То что в этом файле я обычно массивами называю. А списками - односвязные или двусвязные.

Ну, вижу. И каких комментариев ты ждёшь? Сделано в целом приемлемо, но сфера применения не совсем понятна.

Хотя, list_free может например молча устроить memory leak. А если он за этим не следит, то непонятно зачем вообще функция обёртка над двумя free. А да, нашёл внизу list_free_items_and_destroy, но тогда новые вопросы:

1) почему тогда list_free не static, раз уж её сделали отдельной, а показывать наружу надо вторую?

2) получается этот list годится только как список плоских блоков данных, аллоцированных malloc-ом, сложное в него пихать нельзя, а если и пихать - придётся нарушать и так неважную инкапсуляцию и реализовывать где-то снаружи альтернативное list_free_items_and_destroy.

А ещё я бы не стал аллоцирование самого list_t сюда вообще включать, т.к. эта тривиальная структура из 12-16 байт почти не отличается по размеру от указателя размером 4-8 байт, и много где её желательно было бы хранить статически.

Аааа! capacity/length мало того что не size_t так ещё и signed! Стандартный дефект твоих любимых «сишников» в самом плохом смысле этого слова, традиционный для в 80-х годов. (впрочем, признаю, в моём .c файле тоже int не к месту в одном месте, но переполнение в нём невозможно т.к. с ним кроме инкремента-декремента в строгих рамках ничего не делается) Нет проверки на переполнение когда capacity умножается на sizeof(void*).

Ну, про realloc ты уже писал. А ещё на мой взгляд разширение массива методом умножения на 2 не всегда хорошо (но это вкусы), и там опять нет проверки на переполнение (а это уже явно плохо).

list_move_to_end() в виде list_del+list_add с одной стороны зрительно замусоривает код, с другой вызывает ненужное list_resize в середине, а могли бы вставить туда memmove + перемещение одного item-а в явном виде.

Дальше лень смотреть.

А да, я не про те списки думал. То что а этом файле я обычно массивами называю. А списками - односвязные или двусвязные.

Ну, вижу. И каких комментариев ты ждёшь? Сделано в целом приемлемо, но сфера применения не совсем понятна.

Хотя, list_free может например молча устроить memory leak. А если он за этим не следит, то непонятно зачем вообще функция обёртка над двумя free. А да, нашёл внизу list_free_items_and_destroy, но тогда новые вопросы:

1) почему тогда list_free не static, раз уж её сделали отдельной, а показывать наружу надо вторую?

2) получается этот list годится только как список плоских блоков данных, аллоцированных malloc-ом, сложное в него пихать нельзя, а если и пихать - придётся нарушать и так неважную инкапсуляцию и реализовывать где-то снаружи альтернативное list_free_items_and_destroy.

А ещё я бы не стал аллоцирование самого list_t сюда вообще включать, т.к. эта тривиальная структура из 12-16 байт почти не отличается по размеру от указателя размером 4-8 байт, и много где её желательно было бы хранить статически.

Аааа! capacity/length мало того что не size_t так ещё и signed! Стандартный дефект твоих любимых «сишников» в самом плохом смысле этого слова, традиционный для в 80-х годов. Нет проверки на переполнение когда capacity умножается на sizeof(void*).

Ну, про realloc ты уже писал. А ещё на мой взгляд разширение массива методом умножения на 2 не всегда хорошо (но это вкусы), и там опять нет проверки на переполнение (а это уже явно плохо).

list_move_to_end() в виде list_del+list_add с одной стороны зрительно замусоривает код, с другой вызывает ненужное list_resize в середине, а могли бы вставить туда memmove + перемещение одного item-а в явном виде.

Дальше лень смотреть.

А да, я не про те списки думал. То что а этом файле я обычно массивами называю. А списками - односвязные или двусвязные.

Ну, вижу. И каких комментариев ты ждёшь? Сделано в целом приемлемо, но сфера применения не совсем понятна.

Хотя, list_free может например молча устроить memory leak. А если он за этим не следит, то непонятно зачем вообще функция обёртка над двумя free. А да, нашёл внизу list_free_items_and_destroy, но тогда новые вопросы:

1) почему тогда list_free не static, раз уж её сделали отдельной, а показывать наружу надо вторую?

2) получается этот list годится только как список плоских блоков данных, аллоцированных malloc-ом, сложное в него пихать нельзя, а если и пихать - придётся нарушать и так неважную инкапсуляцию и реализовывать где-то снаружи альтернативное list_free_items_and_destroy.

А ещё я бы не стал аллоцирование самого list_t сюда вообще включать, т.к. эта тривиальная структура из 12-16 байт почти не отличается по размеру от указателя размером 4-8 байт, и много где её желательно было бы хранить статически.

Аааа! capacity/length мало того что не size_t так ещё и signed! Стандартный дефект твоих любимых «сишников» в самом плохом смысле этого слова, традиционный для в 80-х годов. Нет проверки на переполнение когда capacity умножается на sizeof(void*).

Ну, про realloc ты уже писал. А ещё на мой взгляд разширение массива методом умножения на 2 не всегда хорошо (но это вкусы), и там опять нет проверки на переполнение (а это уже явно плохо).

list_move_to_end() в виде list_del+list_add с одной стороны зрительно замусоривает код, с другой вызывает ненужное list_resize в середине, а могли бы вставить туда memmove + перемещение одного item-а в явном виде.

Дальше лень смотреть.