Есть ли смысл писать реализации двухсвязанных списков под софты? (C++)

[Alexey18]

Короче я думал написать свой аналог вектору посредством(malloc/realloc), ведь это нормально так уберет вес и на какое-то время даже запутает реверс-инженера (нет).
Но узнал что существует такие методики как двухсвязанный/односвязанный список(когда элемент указывает на впереди стоящий элемент). Реализация быстрая, но собрались вопросики)
Есть ли смысл практического использования данного дела для ускорения процесса сбора там данных/обработки чего-то?
И как на подобные вещи реагирует авер?
Или есть резон тупо написать свою реализацию векторов, чтобы работало с любым типом данных?
Я в курсе что существует stl: list(аналог вектору, но выполняющий функ. двусвязанного), но тут вес и стороннее добро от майков.

Интересно послушать мнение людей, которые возможно имели практический опыт работы.

 

[Snow]

ну вообще это тема сводится к вопросу написания малвари на плюсах, а не чистом С.
Использование STL не дает лишнего веса. Разницей в несколько килобайт можно принебречь.
Теперь по порядку.

Но узнал что существует такие методики как двухсвязанный/односвязанный список(когда элемент указывает на впереди стоящий элемент). Реализация быстрая, но собрались вопросики)
Есть ли смысл практического использования данного дела для ускорения процесса сбора там данных/обработки чего-то?

Открываем вики и видим следующее.
Добавление элемента в начало и конец списка. Алгоритмическая сложность О(1).
Удаление элемента из начала и конца списка. Алгоритмическая сложность О(1).
Вставка элемента. Алгоритмическая сложность О(n).
Удаление промежуточных элементов Алгоритмическая сложность О(n).
Доступ к элементу. Алгоритмическая сложность О(n).

Сравним это с операциями в std::vector
Добавление элемента. Алгоритмическая сложность О(n).
Удаление элемента. Алгоритмическая сложность О(n).
Доступ к элементу. Алгоритмическая сложность О(1).

Поиск элемента. В худшем случае O(n). Если вектор уже отслортирован, то логарифмическая сложность.

А вообще, для оптимизации поиска я бы рекомендовал посмотреть в сторону HashMap и деревьев.


Сочинять свою козу на лисапеде имеет смысл, если ты хочешь прокачать скиллы. Только подходить к этому нужно очень тщательно. Ну и тесты, тесты и еще раз тесты для сравнения функциональности и производительности.

 

[xlx]

тут был затуп

А по вопросу тс, вполне можно использовать главное под правильную задачу. Для обработки так себе, но для сбора данных, вполне годный вариант.

 

[hahbah]

Так же задумывался над использованием своих структур. По моему мнению в 95% лучше использовать STL.
В своих проектах я часто применяю алгоритмы, сосредоточься на них лучше.
К примеру сравнение строк за константу и тд, вот они сильно ускорят твой софт.

Именно про список, то если надо много добавлять и удалять элементы(не из середины), то да, будет быстрее. Но могут возникнуть проблемы с памятью.

 

[ghost_tost]

Тут имхо больше вопрос в целесообразности - писать велосипеды конечно весело, но в один момент можно обнаружить, что ты пишешь второй стандарт вместо изначального проекта

 

[29A]

зачем писать то, что уже написано и написано хорошо

 

[Snow]

зачем писать то, что уже написано и написано хорошо

только для саморазвития. В универе это на первом курсе заставляют делать. Ну во всяком случае в мое время заставляляи.