Да, заниматься рефакторингом legacy-кода категорически нельзя, если ты внутренне убежден, что написавшие систему — идиоты. Сам грешен и столько раз потом было стыдно, когда через некоторое время понимал, что наворотил более сложную и негибкую систему, чем раньше, или вместе с изменениями угробил красивое решение, которое просто не понял.
Цитата из статьи: "A* гарантированно найдёт кратчайший путь, если эвристика никогда не больше истинного расстояния."
Что понятно, т.к. при нулевом коэффициенте при расстоянии она становится жадным алгоритмом. Мне сразу интересно: равенство коэффициентов — это фазовый переход, или нет? Т.е. есть ли сценарии, когда истинное расстояние меньше эвристики, но при этом алгоритм всегда находит кратчайший путь.
Спасибо, отличная вводная статья с понятными картинками и не переусложненным кодом. Разобраться было просто. Более того, захотелось еще поэкспериментировать (а что будет, если поменять эвристику A* и т.п.) :)
Конечно, просто раньше он ставился вместе со студией (или ее nuget-расширением, не помню) и попадал в PATH в Visual Studio Command Line.
Т.е. стало выглядеть как магия — студия пакеты качает, но каким образом — не сразу понятно;)
А я-то думал: куда делся удобный command-line'овый nuget.exe. Жаль, что унификация через powershell слелана так, что без мануала нужную команду не угадаешь.
Спасибо за статью, отличный формат для вводного курса «как это в целом вообще устроено». То самое, чего больше всего не хватает в мануалах, особенно MSDN.
C MSVC понятно, что в 2015-й студии и ранее не работает, т.е. работает только в 2017-й. Коммерческая разработка не может позволить себе обновлять компиляторы каждые пару лет, увы: есть нестабильность только что вышедших версий, немалые трудозатраты на апгрейд и отлов вызванных им багов, стоимость лицензий (если речь о платных средах).
С классами-агрегатами вообще обидно вышло. Думаешь: "Ура, наконец-то я могу инициализировать non-POD структуры фигурными скобками, даёшь!" А потом выходит, что шаг вправо. шаг влево — нельзя. Например, aggreate initializtion незьзя использвать, если есть конутруктор или значения по умолчанию для полей (т.н. default member initializers), т.е. нельзя сказать
struct A {
int x = 0;
};
A obj{1};
а если отказаться от значений по умолчанию, кто-то может создать структуру в виде A obj; и получить неинициализированные поля.
К счастью, в 14'м стандарте одумались и member initializers разрешили (но до него надо еще дожить, точнее доапгрейдиться).
В своих лекциях про C++11 Scott Meyers говорил, что когда возникает новая хорошая идея (инициализировать массивы списком элементов через {}), комитет сразу думает: "ага, а давайте добавим это везде!" (разрешим в фигурных скобках писать аргументы конструктора). В итоге получается не локальная фишечка типа описанного вами std::of, а такие вот монстры, которые пытаются решить все потенциально возможные задачи.
Ну формально может быть и запрещено, но сам такое видел. В какой-то момент, например, у Яндекса возникли пешеходные дорожки и переходы, и по крайней мере некоторые из них в точности повторяли существовавшие ранее в OSM — там и там c одинаковой ошибкой.
Потом я нарисовал «свой» новый строящийся ЖК в OSM, подписав дома номерами корпусов (типа к24). Очень скоро это попало в Яндекс, а потом долго висело, уже когда дома были достроены и я проставил домам почтовые адреса.
Возможно, это делает не администрация, а пользователи (хотя в случае с пешеходными дорожками — сомнительно, но тут в теории можно объяснить одинаковыми устаревшими снимками).
Тем более, что отмеченное в OpenStreetMap рано или поздно попадает как минимум в Яндекс, а наверное и в Гугл тоже. С Яндексом проверял лично и неоднократно — там, где ему не хватает своих данных, копирует в точности, включая ошибки.
Для tie надо заранее заводить переменные, к которым привязываешь значение (т.е. нарушение RAII). Есть в 17-м стандарте Structured Bindings (https://skebanga.github.io/structured-bindings/) — ровно то, что нужно, но пока они еще далеко не везде реализованы.
Не соглашусь. Да, перечисление фич, но это те фичи, которые реально вырастают из практики. Многие из них мне, как прикладному программисту на С++, очень хотелось бы использовать для повышения читаемости и надежности кода команды (или это уже есть в C++ и активно используется).
Например, именованные аргументы исключают ошибки, когда путаются местами параметры одинакового типа, и повышают читабельность функций с многими аргументами. Цена такой ошибки — от 2 минут до многих часов отладки. Читабельнось экономит кучу времени при анализе чужого и позапрошлогоднего своего кода.
Аналогично:
when (иначе — длинные ошибкоемкие цепочки if-else для небанальных случаев)
декомпозиция (удобный возврат нескольких аргументов из функции, иначе приходится создавать на каждый чих структуру либо нарушать RAII)
not nullable (в С++ можно использовать &, но это не всегда достаточно гибко и трудно переучить народ),
перегрузка операторов (читаемость математики)
Конечно, сами по себе эти вещи не должны побуждать сразу сменить язык (тут автор статьи перегнул), но забота о таких неочевидных практических деталях показывает, что разработчики языка приближены к жизни и имеют хороший опыт коммерческой разработки.
Тут есть тонкость, что чтобы разобраться в критике, и тем более учесть ее, нужно потратить время — тот самый ограниченный ресурс, который opensource-разработчик вкладывает в проект. Имхо, у мейнтейнера есть право сказать "изини, у меня нет времени глубоко в это погружаться", хотя вряд ли он им будет пользоваться, если критика существенная (касается реальных проблем) и обоснованная.
И уж тем более у него может не быть времени разбираться пусть даже в честной критике всяких мелочей.
А, так под "он предложил два патча" имелось в виду, "сделал два pull-request'а", а не "предложил мне сделать два изменения в программе". Да, похоже я неправильно прочитал. Судя по гитхабу, там действительно pull-request c концептуальными возражениями автора библиотеки.
Тогда только fork ;)
Либо — предложить самому пофиксить свой тикет и сделать pull request (для тех тикетов, которые просто не хочется делать, но которые не ломают архитектуру).
Раздражение автора ведь началось с необходимости (хотя кто заставляет-то?) трудиться по тикетам, которые ему неинтересны. В коммерческой разработке вполне нормально принять тикет с низким приоритетом или делегировать задачу. Похоже, автор пока не умеет пользоваться этими механизмами, поэтому поставил себя в позицию "или я сейчас делаю фикс, или я нечестный парень". Дальше, конечно, конфликт неизбежен, особенно при таком неуважительном отношении собеседника.
А может быть напишете статью о том, в каком виде она сейчас есть?
Как бывшему пойнту (в свое время, увы, соблазнившемуся интернетом) — дичайше интересно. Судя по комментариям в статьях, где упоминается Фидо, интересно будет и другим.
Если концептуально нравится Zim, можно еще присмотреться к CherryTree. Он немного побогаче функционалом (например, имеет подсвеку синтаксиса, умеет рисовать таблицы), но базу хранит в xml/SQLite. Есть импорт из Zim. Но не умеет, к примеры, поддерживать список TODO.
В общем — дело вкуса, но хорошо, что есть выбор.
Просто вы просто не освоили vim ;)
Да, заниматься рефакторингом legacy-кода категорически нельзя, если ты внутренне убежден, что написавшие систему — идиоты. Сам грешен и столько раз потом было стыдно, когда через некоторое время понимал, что наворотил более сложную и негибкую систему, чем раньше, или вместе с изменениями угробил красивое решение, которое просто не понял.
Цитата из статьи: "A* гарантированно найдёт кратчайший путь, если эвристика никогда не больше истинного расстояния."
Что понятно, т.к. при нулевом коэффициенте при расстоянии она становится жадным алгоритмом. Мне сразу интересно: равенство коэффициентов — это фазовый переход, или нет? Т.е. есть ли сценарии, когда истинное расстояние меньше эвристики, но при этом алгоритм всегда находит кратчайший путь.
Спасибо, отличная вводная статья с понятными картинками и не переусложненным кодом. Разобраться было просто. Более того, захотелось еще поэкспериментировать (а что будет, если поменять эвристику A* и т.п.) :)
Конечно, просто раньше он ставился вместе со студией (или ее nuget-расширением, не помню) и попадал в PATH в Visual Studio Command Line.
Т.е. стало выглядеть как магия — студия пакеты качает, но каким образом — не сразу понятно;)
Спасибо за статью, отличный формат для вводного курса «как это в целом вообще устроено». То самое, чего больше всего не хватает в мануалах, особенно MSDN.
C MSVC понятно, что в 2015-й студии и ранее не работает, т.е. работает только в 2017-й. Коммерческая разработка не может позволить себе обновлять компиляторы каждые пару лет, увы: есть нестабильность только что вышедших версий, немалые трудозатраты на апгрейд и отлов вызванных им багов, стоимость лицензий (если речь о платных средах).
С классами-агрегатами вообще обидно вышло. Думаешь: "Ура, наконец-то я могу инициализировать non-POD структуры фигурными скобками, даёшь!" А потом выходит, что шаг вправо. шаг влево — нельзя. Например, aggreate initializtion незьзя использвать, если есть конутруктор или значения по умолчанию для полей (т.н. default member initializers), т.е. нельзя сказать
а если отказаться от значений по умолчанию, кто-то может создать структуру в виде
A obj;и получить неинициализированные поля.К счастью, в 14'м стандарте одумались и member initializers разрешили (но до него надо еще дожить, точнее доапгрейдиться).
В своих лекциях про C++11 Scott Meyers говорил, что когда возникает новая хорошая идея (инициализировать массивы списком элементов через
{}), комитет сразу думает: "ага, а давайте добавим это везде!" (разрешим в фигурных скобках писать аргументы конструктора). В итоге получается не локальная фишечка типа описанного вамиstd::of, а такие вот монстры, которые пытаются решить все потенциально возможные задачи.Потом я нарисовал «свой» новый строящийся ЖК в OSM, подписав дома номерами корпусов (типа к24). Очень скоро это попало в Яндекс, а потом долго висело, уже когда дома были достроены и я проставил домам почтовые адреса.
Возможно, это делает не администрация, а пользователи (хотя в случае с пешеходными дорожками — сомнительно, но тут в теории можно объяснить одинаковыми устаревшими снимками).
Для tie надо заранее заводить переменные, к которым привязываешь значение (т.е. нарушение RAII). Есть в 17-м стандарте Structured Bindings (https://skebanga.github.io/structured-bindings/) — ровно то, что нужно, но пока они еще далеко не везде реализованы.
Не соглашусь. Да, перечисление фич, но это те фичи, которые реально вырастают из практики. Многие из них мне, как прикладному программисту на С++, очень хотелось бы использовать для повышения читаемости и надежности кода команды (или это уже есть в C++ и активно используется).
Например, именованные аргументы исключают ошибки, когда путаются местами параметры одинакового типа, и повышают читабельность функций с многими аргументами. Цена такой ошибки — от 2 минут до многих часов отладки. Читабельнось экономит кучу времени при анализе чужого и позапрошлогоднего своего кода.
Аналогично:
Конечно, сами по себе эти вещи не должны побуждать сразу сменить язык (тут автор статьи перегнул), но забота о таких неочевидных практических деталях показывает, что разработчики языка приближены к жизни и имеют хороший опыт коммерческой разработки.
Тут есть тонкость, что чтобы разобраться в критике, и тем более учесть ее, нужно потратить время — тот самый ограниченный ресурс, который opensource-разработчик вкладывает в проект. Имхо, у мейнтейнера есть право сказать "изини, у меня нет времени глубоко в это погружаться", хотя вряд ли он им будет пользоваться, если критика существенная (касается реальных проблем) и обоснованная.
И уж тем более у него может не быть времени разбираться пусть даже в честной критике всяких мелочей.
А, так под "он предложил два патча" имелось в виду, "сделал два pull-request'а", а не "предложил мне сделать два изменения в программе". Да, похоже я неправильно прочитал. Судя по гитхабу, там действительно pull-request c концептуальными возражениями автора библиотеки.
Тогда только fork ;)
Либо — предложить самому пофиксить свой тикет и сделать pull request (для тех тикетов, которые просто не хочется делать, но которые не ломают архитектуру).
Раздражение автора ведь началось с необходимости (хотя кто заставляет-то?) трудиться по тикетам, которые ему неинтересны. В коммерческой разработке вполне нормально принять тикет с низким приоритетом или делегировать задачу. Похоже, автор пока не умеет пользоваться этими механизмами, поэтому поставил себя в позицию "или я сейчас делаю фикс, или я нечестный парень". Дальше, конечно, конфликт неизбежен, особенно при таком неуважительном отношении собеседника.
Как бывшему пойнту (в свое время, увы, соблазнившемуся интернетом) — дичайше интересно. Судя по комментариям в статьях, где упоминается Фидо, интересно будет и другим.
(Для тех, кто не в курсе: http://lurkmore.to/%D0%9D)
Если концептуально нравится Zim, можно еще присмотреться к CherryTree. Он немного побогаче функционалом (например, имеет подсвеку синтаксиса, умеет рисовать таблицы), но базу хранит в xml/SQLite. Есть импорт из Zim. Но не умеет, к примеры, поддерживать список TODO.
В общем — дело вкуса, но хорошо, что есть выбор.
Про delete и delete[] в 4 примере поясните, пожалуйста, с какой стати нет разницы для POD-типов.
Товарищи вот тут http://stackoverflow.com/questions/4255598/delete-vs-delete цитируют стандарт, где ясно сказано про undefined behaviour.
P.s. в 3 примере вообще, скорее всего, было бы уместно
std::unique_ptr<int[]> ss(new int[decks * 52]);(хотя без полного кода не скажешь, конечно).