Вы пробовали sqitch? Я не являюсь специалистом по SQL БД и тестированию, поэтому мне он кажется замечательным. Интересно было бы услышать мнение более опытного специалиста.
Не думал, что опущусь так низко, но если хотите попробовать хороший продукт дома, то попробуйте Microsoft Visual Studio Community 2017. Это и легально, и созданные программы можно продавать подороже (если мне не изменяет память, до 1 млн.$ в год).
Если значение является не обязательным, то мне всё ещё кажется вполне логичным написать if с проверкой его существования и обработать его в соответствующей блоке кода.
Если в обработка опционального значения увеличивает глубину вложенности на 1 — это не страшно в общем случае. По-настоящему плохо становится тогда, когда это уже 3-5-8 уровень вложенности. Но в этом случае проблема уже явно не в необходимости проверки чего-либо, а в низком качестве кодовой базы (Линус как-то высказывался на этот счёт в выражениях типа «your code is already fucked up», если мне не изменяет память)
Если очень хочется и есть такая возможность, то можно использовать ранний возврат:
auto optional_value = function_returning_optional();
if (!optional_value) {
return;
}
auto& my_precious_value = *optional_value;
// Great code that cannot be put under "if"
Если в блоке кода может появится много опциональных значений, то возможно проблема в самом коде, надо что-то исправить.
Мне кажется, Вы тоже немного лукавите. Тот факт, что существует std::optional не означает, что его следует использовать всегда и везде:
Если требуется иметь описанное Вами поведение, то std::optional не нужен. Если же очень хочется, то всегда можно оставить логику, связанную с nullptr: в случае, если результат не интересен, передавать nullptr в качестве значения std::optional для опционального выходного аргумента (хотя это и костыль). Отдельно хотелось бы отметить, что может иметь смысл создание перегрузки, которая не принимает этот самый выходной аргумент, который может быть иногда не нужен — если результат часто бывает не нужен, то такой вариант сократит возможность возникновения ошибки. (Если я не ошибаюсь, выходные аргументы в современном C++ считаются немного не актуальными в общем случае, но у меня нет под рукой ссылок для подтверждения.)
Мне кажется, углубление позитивной ветки кода логично, если данная ветка должна работать со значением, которого может не быть. Винить в этом нововведения не разумно — раньше Вам точно также пришлось бы проверять, вернулось ли что-то, если оно могло не вернуться. В случае же, когда std::optional используется для возврата значений, которые должны быть возвращены всегда, в коде могут существовать более серьёзные проблемы, чем лишний уровень вложенности.
Не забывайте, что C++ — это, в первую очередь, инструмент. И добавление в него «новых модных плюшек» вовсе не означает, что они должны полностью заменять то, что уже есть в языке. Вот если бы наряду с добавлением, скажем, std::function удалили бы возможность использования указателей на функции, тогда можно было бы говорить о том, что новые возможности ущербны, ведь они что-то там не позволяют делать.
Зависит от ситуации. Если приложение должно быть закрытым, а денег на коммерческую лицензию Qt нет, то Qt Charts и Qt Data Visualisation становятся недостижимой роскошью.
Что-то мне подсказывает, что людям с XP и «надо чтобы был ровно один абсолютно портабельный файл» в наивысшей степени безразлично, что и какие лицензии нарушает.
Относительно ощущений о производительности ITK соглашусь — при попытке использовать ITK-SNAP для простой сегментации кости по уровню пришлось долго ждать расширения области. Почему нельзя было просто пройти по всему объёму без использования затравочных точек и сделать костью всё подходящее — не вполне понятно. Соблазняет только то, что алгоритмов реализовано, судя по всему, достаточно много и код, возможно, протестирован. Своя реализация, безусловно, лучше, но я в себе не ощущаю необходимых сил)
Есть ли у Вас опыт использования ITK для решения задач, связанных с сегментацией. Последние 3 года я смотрю в сторону данного фреймворка, но всё не решаюсь начать освоение.
Какой вариант алгоритма марширующих кубов Вы применяете? Существует улучшенный вариант алгоритма, позволяющий получать более точные полигональные поверхности (если верить авторам). Интересно Ваше мнение по данному вопросу.
Рассматривали ли Вы использование не одномерных передаточных функций? Сам я не пробовал данный подход (в решаемых задачах используется визуализация исключительно сегментированных данных, где для каждого элемента задан материал, определяющий параметры отображения), но было бы интересно узнать, насколько актуально его применение в реальном ПО.
P.S. Публикации по ссылкам не самой первой свежести, но до других у меня на данный момент руки не дошли.
Вот так посмотришь на инструменты для сегментации томограмм которые делают другие, потом на те, которые делаешь сам, и понимаешь, что ты делаешь фигню.
Главная прелесть planform.io в том, что его можно запускать из командной строки. При этом можно запускать как сборку всех целей (под разные платы, если есть), так и под конкретную. Единственное, что мне показалось не совсем удобным, это способ задания последовательного порта. Но это может быть причиной поверхностного ознакомления с документацией.
Я тоже в какой-то момент столкнулся с такой проблемой. Насколько я понимаю, фактически это нарушает всю идею заголовочных файлов. Причина этого в том, как Arduino IDE (если это поделие можно называть IDE) производит обработку файлов. Повозившись немного, понял, что лучшим решением проблемы является переход на использование инструментов, разработанных для разработчиков, а не для домохозаяек.
Лучшим, что нашёл, является platform.io. Порадовало наличие возможности производить тестирование кода, организация сборки под разные платформы, наличие работающей системы зависимостей (в Arduino IDE есть выкидышь на эту тему, целый пакетный менеджер, который не позволяет задавать зависимости проекта, в результате чего периодически сборка чужого проекта превращается в игру «угадай версию библиотеки, использованной разработчиком»). На данный момент меня полностью устраивает. В случае, если будете пользоваться и посмотрите в сторону IDE, рекомендую посмотреть на версию, основанную на VS Code. Как минимум на моём не молодом ноутбуке данная версию работала куда как бодрее, чем выкидышь на Atom.
При использовании соотвутствующих инструментов появляется возможность проводить тестирование этой самой бизнес-логики на стороне БД. Может быть это излишне или даже не нужно (я не специалист но разработке БД), но, как показывает мой не слишком богатый опыт, позволяет меньше усилий тратить при разработке и тестировании кода приложения, использующего БД.
Сходная проблема есть и в Emacs: при переключении системной раскладки на русский язык какие-либо команды выполнить нельзя. Для себя я это и на Windows, и на Kubuntu решил очень просто: в настройках переключения раскладки включил использование отдельной раскладки для каждого отдельного приложения (могу ошибаться, но быть может даже окна на Kubuntu) и Emacs использовал только встроенную систему интернационализации и переключения раскладок. В результате волки сыты (всё равботает, я доволен), и овцы целы (не пришлось что-либо делать).
Хотел бы заметить, что Вы только частично правы относительно того, что «физические карточки» не прижились. У Nvidia есть Tesla (http://www.nvidia.ru/object/why-choose-tesla-ru.html), которая, хотя и является формально графическим ускорителем, лишена (насколько мне известно) возможности вывода графики и предназначена только для ведения рассчётов. Не только физических, конечно же.
Относительно RAII согласен, механизм прекрасный. Недавно открыл его для себя. Я имею в виде не теоритически, но на практике.
Про отдельные задачи теперь понял, спасибо) В моём восприятии всё упёрлось в то, что отдельная задача выполняется целиком отдельным потоком, который целиком останавливается.
Хотелось бы добавить немного подробностей относительно pthread_cancel. Безусловно, использование данного механизма может приводить к проблемам с освобождением мьютексов и ресурсов. Однако, стоило также упомянуть про механизм pthread_cleanup_push() / pthread_cleanup_pop (), позволяющий устанавливать функции-обработчики для выполнения процедуры корректного освобождения ресурсов при завершении работы потока. Я сталкивался с тем, что отмена потока при помощи pthread_cancel () приводит к тому, что мьютекс остаётся не освобождённым. И добавление простейшего обработчика, который мьютекс освобождает, решило проблему. Безусловно, написание такого рода обработчиков достаточно трудоёмко. Тем не менее, упомянуть о таком варианте, на мой взгляд, стоило.
Также хотелось бы уточнить, что означает фраза «Нельзя применить для прерывания отдельных функций или задач»? Меня она поставила в тупик)
Извините меня, пожалуйста, но лучше бы Вам прекратить писать статьи. В каждой статье Вы пишете глупости, каждый раз Вы делаете это с огромным количеством грамматических ошибок, каждый раз Вы пытаетесь представить себя экспертом предметной области. Не надо. Если Вам хочется самовыражения — пишите код. Старый добрый код. Или играйте на гитаре. Или вырезайте из слоновой кости статуэтки котиков. Но вот писать статьи на хабр не надо. По крайней мере до тех пор, пока у Вас не появится за плечами достаточно опыта и знаний русского языка за 5 класс.
Вы пробовали sqitch? Я не являюсь специалистом по SQL БД и тестированию, поэтому мне он кажется замечательным. Интересно было бы услышать мнение более опытного специалиста.
Не думал, что опущусь так низко, но если хотите попробовать хороший продукт дома, то попробуйте Microsoft Visual Studio Community 2017. Это и легально, и созданные программы можно продавать подороже (если мне не изменяет память, до 1 млн.$ в год).
Мне кажется, Вы тоже немного лукавите. Тот факт, что существует std::optional не означает, что его следует использовать всегда и везде:
Не забывайте, что C++ — это, в первую очередь, инструмент. И добавление в него «новых модных плюшек» вовсе не означает, что они должны полностью заменять то, что уже есть в языке. Вот если бы наряду с добавлением, скажем, std::function удалили бы возможность использования указателей на функции, тогда можно было бы говорить о том, что новые возможности ущербны, ведь они что-то там не позволяют делать.
P.S. Публикации по ссылкам не самой первой свежести, но до других у меня на данный момент руки не дошли.
Спасибо за статью!
Вот так посмотришь на инструменты для сегментации томограмм которые делают другие, потом на те, которые делаешь сам, и понимаешь, что ты делаешь фигню.
Главная прелесть planform.io в том, что его можно запускать из командной строки. При этом можно запускать как сборку всех целей (под разные платы, если есть), так и под конкретную. Единственное, что мне показалось не совсем удобным, это способ задания последовательного порта. Но это может быть причиной поверхностного ознакомления с документацией.
Я тоже в какой-то момент столкнулся с такой проблемой. Насколько я понимаю, фактически это нарушает всю идею заголовочных файлов. Причина этого в том, как Arduino IDE (если это поделие можно называть IDE) производит обработку файлов. Повозившись немного, понял, что лучшим решением проблемы является переход на использование инструментов, разработанных для разработчиков, а не для домохозаяек.
Лучшим, что нашёл, является platform.io. Порадовало наличие возможности производить тестирование кода, организация сборки под разные платформы, наличие работающей системы зависимостей (в Arduino IDE есть выкидышь на эту тему, целый пакетный менеджер, который не позволяет задавать зависимости проекта, в результате чего периодически сборка чужого проекта превращается в игру «угадай версию библиотеки, использованной разработчиком»). На данный момент меня полностью устраивает. В случае, если будете пользоваться и посмотрите в сторону IDE, рекомендую посмотреть на версию, основанную на VS Code. Как минимум на моём не молодом ноутбуке данная версию работала куда как бодрее, чем выкидышь на Atom.
Насколько я понял, именно выделение бизнес-логики в хранимые процедуры позволяет упростить разработку и поддержку приложения.
При использовании соотвутствующих инструментов появляется возможность проводить тестирование этой самой бизнес-логики на стороне БД. Может быть это излишне или даже не нужно (я не специалист но разработке БД), но, как показывает мой не слишком богатый опыт, позволяет меньше усилий тратить при разработке и тестировании кода приложения, использующего БД.
Однако, по причине лени, в остальных редакторах пользуюсь той стандартной тёмной темой, которая есть.
Сходная проблема есть и в Emacs: при переключении системной раскладки на русский язык какие-либо команды выполнить нельзя. Для себя я это и на Windows, и на Kubuntu решил очень просто: в настройках переключения раскладки включил использование отдельной раскладки для каждого отдельного приложения (могу ошибаться, но быть может даже окна на Kubuntu) и Emacs использовал только встроенную систему интернационализации и переключения раскладок. В результате волки сыты (всё равботает, я доволен), и овцы целы (не пришлось что-либо делать).
Хотел бы заметить, что Вы только частично правы относительно того, что «физические карточки» не прижились. У Nvidia есть Tesla (http://www.nvidia.ru/object/why-choose-tesla-ru.html), которая, хотя и является формально графическим ускорителем, лишена (насколько мне известно) возможности вывода графики и предназначена только для ведения рассчётов. Не только физических, конечно же.
Относительно RAII согласен, механизм прекрасный. Недавно открыл его для себя. Я имею в виде не теоритически, но на практике.
Про отдельные задачи теперь понял, спасибо) В моём восприятии всё упёрлось в то, что отдельная задача выполняется целиком отдельным потоком, который целиком останавливается.
Хотелось бы добавить немного подробностей относительно pthread_cancel. Безусловно, использование данного механизма может приводить к проблемам с освобождением мьютексов и ресурсов. Однако, стоило также упомянуть про механизм pthread_cleanup_push() / pthread_cleanup_pop (), позволяющий устанавливать функции-обработчики для выполнения процедуры корректного освобождения ресурсов при завершении работы потока. Я сталкивался с тем, что отмена потока при помощи pthread_cancel () приводит к тому, что мьютекс остаётся не освобождённым. И добавление простейшего обработчика, который мьютекс освобождает, решило проблему. Безусловно, написание такого рода обработчиков достаточно трудоёмко. Тем не менее, упомянуть о таком варианте, на мой взгляд, стоило.
Также хотелось бы уточнить, что означает фраза «Нельзя применить для прерывания отдельных функций или задач»? Меня она поставила в тупик)
За статью большое спасибо, мне очень понравилось)
Извините меня, пожалуйста, но лучше бы Вам прекратить писать статьи. В каждой статье Вы пишете глупости, каждый раз Вы делаете это с огромным количеством грамматических ошибок, каждый раз Вы пытаетесь представить себя экспертом предметной области. Не надо. Если Вам хочется самовыражения — пишите код. Старый добрый код. Или играйте на гитаре. Или вырезайте из слоновой кости статуэтки котиков. Но вот писать статьи на хабр не надо. По крайней мере до тех пор, пока у Вас не появится за плечами достаточно опыта и знаний русского языка за 5 класс.