Комментарии 22
В целом уже ничего, но иногда мне хочется наконец взять и написать нормальный парсер, но видимо на Qt, на голых плюсах локализацию неудобно делать.
0
Зря не упомянули о прикручивании response-файлов, а их не так-то уж и сложно прикручивать с помощью этой либы. Зато это сэкономило бы время читателю пытающегося прикрутить столь полезную фичу к тулзе
>>скудная документация
Нет. Очень даже на высоте! Даже такой ленивый как я и то за 1 час чтения разобрался
Добавлю альтернативную библиотеку: tclap.sourceforge.net/
>>скудная документация
Нет. Очень даже на высоте! Даже такой ленивый как я и то за 1 час чтения разобрался
Добавлю альтернативную библиотеку: tclap.sourceforge.net/
+2
Я долго думал, что включить: custom parsers, config files. Решил остановится на том, что качует из проекта в проект и только это. Библиотека не очень большая, и самое тяжёлая задача убедить себя. что её использовать проще, чем написать очередной парсер самому.
Мне было проще было читать код, чем доки, поэтому не очень хорошего о них мнения.
Мне было проще было читать код, чем доки, поэтому не очень хорошего о них мнения.
0
Там по сути нужно открыть только одну страницу и 2 примера, а дальше становится понятно и можно писать свое.
Также не упомянули «скрытие» опции. Т.е. когда вы решили включить фичу в продукт эксперементально, чтобы ее потестили другие, но пока об это заявлять рано и поэтому вы в '--help' не показываете
Также не упомянули «скрытие» опции. Т.е. когда вы решили включить фичу в продукт эксперементально, чтобы ее потестили другие, но пока об это заявлять рано и поэтому вы в '--help' не показываете
0
А чем их не устраивал стандартный getopt_long()?
0
Видимо, тем что его на виндах нету.
Но застав однажды такое вольное решение как svn.boost.org/trac/boost/ticket/850, сам предпочитаю getopt_long на *nix. (поясню — в версии 1.41 они _по-умолчанию_ стали вырезать кавычки из аргументов).
Но застав однажды такое вольное решение как svn.boost.org/trac/boost/ticket/850, сам предпочитаю getopt_long на *nix. (поясню — в версии 1.41 они _по-умолчанию_ стали вырезать кавычки из аргументов).
+2
Ручная обработка ошибок на типы аргументов заставляет меня грустить.
+2
Для информации, разбор параметров командной строки в библиотеке Poco: pocoproject.org/slides/190-Applications.pdf
+1
Функция train нарушает принцип DRY.
Что будет, если вздумается переименовать/добавить/удалить параметр?
Разве нельзя автоматически привязать все параметры к переменным и использовать статическую типизацию для контроля на этапе компиляции?
Что будет, если вздумается переименовать/добавить/удалить параметр?
Разве нельзя автоматически привязать все параметры к переменным и использовать статическую типизацию для контроля на этапе компиляции?
+1
Поддерживаю! Смысл в функции train
если все равно все параметры скорее всего предполагаются обязательными.
...
if (vm.count("input")) {
input_path = vm["input"].as<std::string>();
}
...
если все равно все параметры скорее всего предполагаются обязательными.
0
Как раз vm.count(var_name) проверяет встречается ли такой параметр во входных данных, так что не все параметры обязательные.
0
>>vm.count(var_name)
А меня эта ф-ция бесит! ;( Противоречивая. В командной строке нельзя написать больше чем 1 аргумент, а название функции 'count' намекает на возможность нескольких. Мне больше нравится 'is_set', поэтому у меня возникают функции-врапперы. Они конечно лучше, т.к. код становится понятней, но не хочется писать того что лучше было в родной либе
А меня эта ф-ция бесит! ;( Противоречивая. В командной строке нельзя написать больше чем 1 аргумент, а название функции 'count' намекает на возможность нескольких. Мне больше нравится 'is_set', поэтому у меня возникают функции-врапперы. Они конечно лучше, т.к. код становится понятней, но не хочется писать того что лучше было в родной либе
0
Отвечу в обратном порядке:
Про статическую типизацию не понял, все равно аргументы все строковые, а значит lexical_cast будет плеваться динамически. функция as статически типизирована
Привязать переменные можно: в примере так обрабатывается task_type. В таком подходе я вижу следующую проблему, так как я описываю все возможные интерфейсы в одном месте, то прямо там нужно инициализировать все переменные. Если групп больше двух, то получается месиво из переменных, большая часть из которых остается не инициализированной.
Я воспринимаю аргументы командной строки как внешний интерфейс: переименовывание/удаление/добавление аргументов означает изменение контракта на интерфейс со всеми вытекающими.
Насчёт, как это сделать DRY и можно ли это — надо подумать.
Про статическую типизацию не понял, все равно аргументы все строковые, а значит lexical_cast будет плеваться динамически. функция as статически типизирована
Привязать переменные можно: в примере так обрабатывается task_type. В таком подходе я вижу следующую проблему, так как я описываю все возможные интерфейсы в одном месте, то прямо там нужно инициализировать все переменные. Если групп больше двух, то получается месиво из переменных, большая часть из которых остается не инициализированной.
Я воспринимаю аргументы командной строки как внешний интерфейс: переименовывание/удаление/добавление аргументов означает изменение контракта на интерфейс со всеми вытекающими.
Насчёт, как это сделать DRY и можно ли это — надо подумать.
0
("ethanol,e", po::value<std::string>(), "Etalon .trn file")
Так этанол или эталон? :)
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Краткое введение в boost::program_options