Сишные макросы это кувалда, которая легко проламывает систему типов и имеет подобные весёлые side-эффекты. Громоздкость, это цена, чтобы сделать их хоть чуть более безопасными.
В большом проекте писать потенциально опасные макросы - непрофессиональная небрежность. Завтра их кто-то вынесет в общий хедер, потому-что там нужна такая же логика, которая уже проверенно работает, и тоже хочется. Послезавтра кто-то другой использует не так как вы хотели и т.п.
Для личных поделок такая небрежность в написании макросов, безусловно, простительна.
Хорошие грабли вы заготовили для себя будущего и следующего, кто будет поддерживать этот код. Вызов UPDATE_POS кажется безопасным и выглядит прямо как вызов функции, но написан плохо. Вот тут будет oops.
if (flag)
UPDATE_POS(x);
else
UPDATE_POS(y);
Раз любите макросы, то хотя бы пишите их грамотно. В этом случае нужно использовать трюк с do { ... } while(0)
Теоретически я слышал, что такое бывает, и даже "друг говорил", что у его знакомого такое встретилось. Но на поверку всегда оказывалось, что там был UB или логическая ошибка. Наверняка у компилятора бывают баги, но на практике так и не удалось с этим столкнуться
Отвечу за автора комментария. У большей части есть. Нет там, где нет альтернативы и/или есть доверие к создателю. У этой поделки есть и альтернативы, и доверие нулевое.
Если тема интересна, есть шикарный доклад по теме CppCon 2016: Nicholas Ormrod “The strange details of std::string at Facebook" (https://www.youtube.com/watch?v=kPR8h4-qZdk)
Да бог с ним с хешем, тем более, что сейчас вы его поправили. Теперь, правда, документация некорректна. Там уже O(n), и не то, чтобы реализация быстрая.
Теперь возьмём ds_push. Каждый вызов делает новую строку (с новой аллокацией памяти), что совсем необязательною Иногда хочется расширять строку, добавляя в конец элементы. Но ваша строка такой API не предоставляет в отличии от критикуемой вами стандартной библиотеки. При этом с ds_push очень легко словить утечку, а при использовании в цикле получить O(n^2). Но страдать с несуразностями этого API вы предоставляете пользователю.
Беда вашего подхода не в том, что реализация строки УГ - это нормально для экспериментов в период обучения. Нормально и то, что вы пока сами не осознаёте, насколько эта реализация ужасна.
Проблема в том, что вы огульно охаиваете другие решения, не пытаясь разобраться в том, какие осознанные решения были приняты и как они повлияли на реализацию.
Уровень реализации не соответствует уровню пафоса. Хеш одинаковых строк должен быть одинаковым - в вашей реализации это не так. Пока, к сожалению, не тянет даже на учебную поделку.
А где тут нейрослоп? Статья явно писалась на базе своего опыта и при том очень интересная.
А как же канбановские wip-лимиты? Они же как раз и придуманы для этого
Ну да, по ответу видно, что он знал эти загадки
Сишные макросы это кувалда, которая легко проламывает систему типов и имеет подобные весёлые side-эффекты. Громоздкость, это цена, чтобы сделать их хоть чуть более безопасными.
В большом проекте писать потенциально опасные макросы - непрофессиональная небрежность. Завтра их кто-то вынесет в общий хедер, потому-что там нужна такая же логика, которая уже проверенно работает, и тоже хочется. Послезавтра кто-то другой использует не так как вы хотели и т.п.
Для личных поделок такая небрежность в написании макросов, безусловно, простительна.
Хорошие грабли вы заготовили для себя будущего и следующего, кто будет поддерживать этот код. Вызов
UPDATE_POSкажется безопасным и выглядит прямо как вызов функции, но написан плохо. Вот тут будет oops.Раз любите макросы, то хотя бы пишите их грамотно. В этом случае нужно использовать трюк с
do { ... } while(0)Теоретически я слышал, что такое бывает, и даже "друг говорил", что у его знакомого такое встретилось. Но на поверку всегда оказывалось, что там был UB или логическая ошибка. Наверняка у компилятора бывают баги, но на практике так и не удалось с этим столкнуться
У меня как-то получилось - системные файлы защищались не так хорошо. Да и экран смерти иногда ловил.
Жесть начинается, когда сзади 3 ребёнка и у них начинается конфликт. Средний толкнул младшего, а старший решил вмешаться.
Дешевле другое - вносить изменения на поздних стадиях разработки
Так автора бы это не спасло. Скорее всего пользователь был владельцем каталога custom, и никакие запросы прав не требовались
Мне и по отдельности шаги показались безумием. Странная логика поиска, отсутствие проверок, рекурсивное удаление - это прямо треш
Не проверял и не собираюсь. У меня нет ни времени, ни квалификации
Конечно значит:
Я могу придти с патчем и пофиксить проблему - и я так делал, хотя непростительно редко
Когда автор/корпорация забросит свой проект, его может подхватить и/или форкнуть кто-то ещё. Это греет душу. Примеры есть
В перспективе проект с открытыми исходниками будет проще развивать с помощью LLM. Вот даже Торвальдс уже подтягивается
Нет, конечно. Писал же "Нет там, где нет альтернативы и/или есть доверие к создателю"
Русинович - легенда. Тут беру не глядя
Не мой случай. Я начинал с win, dos не застал, с linux плотно познакомился сильно позже. Так что неприятия GUI у меня нет, хотя Far уважаю
У всех свои критерии. Лично мне btop кажется красивым. На обычном ui как-то не заходят
Отвечу за автора комментария. У большей части есть. Нет там, где нет альтернативы и/или есть доверие к создателю. У этой поделки есть и альтернативы, и доверие нулевое.
Ситуация, когда читаешь пост, и никак не можешь понять - это стёб или на полном серъёзе.
Если тема интересна, есть шикарный доклад по теме CppCon 2016: Nicholas Ormrod “The strange details of std::string at Facebook" (https://www.youtube.com/watch?v=kPR8h4-qZdk)
Да бог с ним с хешем, тем более, что сейчас вы его поправили. Теперь, правда, документация некорректна. Там уже O(n), и не то, чтобы реализация быстрая.
Теперь возьмём
ds_push. Каждый вызов делает новую строку (с новой аллокацией памяти), что совсем необязательною Иногда хочется расширять строку, добавляя в конец элементы. Но ваша строка такой API не предоставляет в отличии от критикуемой вами стандартной библиотеки. При этом с ds_push очень легко словить утечку, а при использовании в цикле получить O(n^2). Но страдать с несуразностями этого API вы предоставляете пользователю.Беда вашего подхода не в том, что реализация строки УГ - это нормально для экспериментов в период обучения. Нормально и то, что вы пока сами не осознаёте, насколько эта реализация ужасна.
Проблема в том, что вы огульно охаиваете другие решения, не пытаясь разобраться в том, какие осознанные решения были приняты и как они повлияли на реализацию.
Уровень реализации не соответствует уровню пафоса. Хеш одинаковых строк должен быть одинаковым - в вашей реализации это не так. Пока, к сожалению, не тянет даже на учебную поделку.