Краткое введение в boost::program_options

[Gorthauer87]

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

[kokorins]

Есть слишком много вещей, которые хочется взять и переписать с нуля, но времени на всё не хватит и значит с чем-то приходётся мириться. Если говорить о Qt, то мне гараздо больше не хватает вменяемых chart-ов.

[EvilsInterrupt]

Зря не упомянули о прикручивании response-файлов, а их не так-то уж и сложно прикручивать с помощью этой либы. Зато это сэкономило бы время читателю пытающегося прикрутить столь полезную фичу к тулзе

>>скудная документация
Нет. Очень даже на высоте! Даже такой ленивый как я и то за 1 час чтения разобрался

Добавлю альтернативную библиотеку: tclap.sourceforge.net/

[kokorins]

Я долго думал, что включить: custom parsers, config files. Решил остановится на том, что качует из проекта в проект и только это. Библиотека не очень большая, и самое тяжёлая задача убедить себя. что её использовать проще, чем написать очередной парсер самому.

Мне было проще было читать код, чем доки, поэтому не очень хорошего о них мнения.

[EvilsInterrupt]

Там по сути нужно открыть только одну страницу и 2 примера, а дальше становится понятно и можно писать свое.
Также не упомянули «скрытие» опции. Т.е. когда вы решили включить фичу в продукт эксперементально, чтобы ее потестили другие, но пока об это заявлять рано и поэтому вы в '--help' не показываете

[kokorins]

Я полностью согласен, что это очень полезная опция и и возможность создания скрытых опции неявно следует из следующего кода. Никто ведь не обязан передавать все группы в --help. Например, так:
desc.add(train_desc).add(recognize_desc);//.add(score_desc); std::cout << desc << std::endl;

[dixx]

А чем их не устраивал стандартный getopt_long()?

[dkrot]

Видимо, тем что его на виндах нету.
Но застав однажды такое вольное решение как svn.boost.org/trac/boost/ticket/850, сам предпочитаю getopt_long на *nix. (поясню — в версии 1.41 они _по-умолчанию_ стали вырезать кавычки из аргументов).

[kokorins]

С boost таких косяков много, но мне он не критичен.

[kokorins]

Ручная обработка ошибок на типы аргументов заставляет меня грустить.

[ruzzz]

Для информации, разбор параметров командной строки в библиотеке Poco: pocoproject.org/slides/190-Applications.pdf

[Ryadovoy]

Функция train нарушает принцип DRY.
Что будет, если вздумается переименовать/добавить/удалить параметр?
Разве нельзя автоматически привязать все параметры к переменным и использовать статическую типизацию для контроля на этапе компиляции?

[Cupper]

Поддерживаю! Смысл в функции train

...
if (vm.count("input")) {
      input_path = vm["input"].as<std::string>();
    }
...

если все равно все параметры скорее всего предполагаются обязательными.

[kokorins]

Как раз vm.count(var_name) проверяет встречается ли такой параметр во входных данных, так что не все параметры обязательные.

[EvilsInterrupt]

>>vm.count(var_name)
А меня эта ф-ция бесит! ;( Противоречивая. В командной строке нельзя написать больше чем 1 аргумент, а название функции 'count' намекает на возможность нескольких. Мне больше нравится 'is_set', поэтому у меня возникают функции-врапперы. Они конечно лучше, т.к. код становится понятней, но не хочется писать того что лучше было в родной либе

[kokorins]

Отвечу в обратном порядке:

Про статическую типизацию не понял, все равно аргументы все строковые, а значит lexical_cast будет плеваться динамически. функция as статически типизирована

Привязать переменные можно: в примере так обрабатывается task_type. В таком подходе я вижу следующую проблему, так как я описываю все возможные интерфейсы в одном месте, то прямо там нужно инициализировать все переменные. Если групп больше двух, то получается месиво из переменных, большая часть из которых остается не инициализированной.

Я воспринимаю аргументы командной строки как внешний интерфейс: переименовывание/удаление/добавление аргументов означает изменение контракта на интерфейс со всеми вытекающими.

Насчёт, как это сделать DRY и можно ли это — надо подумать.

[oYASo]

     ("ethanol,e",  po::value<std::string>(), "Etalon .trn file")

Так этанол или эталон? :)

[kokorins]

Я вот до сих пор не уверен насколько корректно использовать слово etalon. Более правильное pattern, standard. но pattern уже занято, а использовать standard мне очень не удобно. Ethanol хорошая альтернатива =).

[oYASo]

Да нет же!
У Вас в первом случае написано «ethanol», что с английского переводится как "этанол" — одноатомный спирт.
А в другом случае у Вас написано «etanol», что переводится как "'эталон", т.е. средство измерения.

[Sild]

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

[oYASo]

Ого, 4 года прошло!

[Sild]

Еще 2 года, а я снова читаю эту статью как в первый раз :D