LINUX.ORG.RU

argparse 3.0

 , , , ,

argparse 3.0

4

2

Состоялся выпуск 3.0 C++ (стандарт C++17) header-only библиотеки парсинга аргументов командной строки argparse, распространяемой по лицензии MIT.

Что нового:

  • добавлена поддержка взаимно исключающих аргументов:
auto &group = program.add_mutually_exclusive_group();
group.add_argument("--first");
group.add_argument("--second");
  • добавлен модуль C++20;
  • добавлена поддержка выбора из нескольких значений:
program.add_argument("input")
  .default_value(std::string{"baz"})
  .choices("foo", "bar", "baz");

program.add_argument("count")
  .default_value(0)
  .choices(0, 1, 2, 3, 4, 5);
  • добавлена поддержка двоичной нотации, например, 0b101:
argparse::ArgumentParser program("test");
program.add_argument("-n").scan<'b', uint8_t>();
  • добавлен перегруженный вариант is_subcommand_used, принимающий парсер подкоманд;
  • в ArgumentParser добавлен параметр exit_on_default_arguments;
  • добавлена поддержка скрытия подкоманд из вывода команды --help:
argparse::ArgumentParser program("test");

argparse::ArgumentParser hidden_cmd("hidden");
hidden_cmd.add_argument("files").remaining();
hidden_cmd.set_suppress(true);

program.add_subparser(hidden_cmd);
  • добавлена возможность проверки наличия разобранных значений в ArgumentParser;
  • добавлено выравнивание по столбцу многострочной справки для аргументов;
  • исправлены многие ошибки.

>>> Подробности

★★★★

Проверено: maxcom ()
Последнее исправление: cetjs2 (всего исправлений: 2)

Ответ на: комментарий от liksys

Если у тебя в голове «язык скриптования» ассоциируется с чем-то плохим - я тут ни при чём. Но то что питон - язык скриптования - это факт.

firkax ★★★★★
()
Ответ на: комментарий от theNamelessOne

Ну хотя бы для вывода ошибки о некорректном параметре.

rumgot ★★★★★
()
Ответ на: комментарий от rumgot

Да, надо было написать «стандарт».

dataman ★★★★
() автор топика
Ответ на: комментарий от Shushundr

А я не написал, «убейся ап стену» это ты уже сам придумал. Я только за то, чтобы больно удариться.

crutch_master ★★★★★
()
Ответ на: комментарий от Shushundr

в случае тебя только спасибо скажут ;)

kott ★★★★★
()
Ответ на: комментарий от seiken

А сколько лет нужно ждать с момента выхода стандарта, прежде чем можно будет его «выбирать»? Десять? Двадцать?

За окном 2023-й. C++17 случился шесть лет назад.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от alex1101

Я не знаю, возможно «несколько тысяч» — это действительно перебор. Но вот типовые случаи действительно разумно разруливать библиотекой.

Например, задание взаимно исключающих наборов ключей, о которых речь в новости. Или заранее указать, что допустим, ключ -p всегда должен сопровождаться после пробела положительным номером порта, а ключ -d — неотрицательным числом секунд. Если эти параметры отсутствуют или присутствуют в неправильном формате, нужно вывести сообщение об ошибке.

Когда у тебя под рукой только argc и argv, для таких элементарнейших вещей всякий раз приходится городить трёхэтажный велосипед. Это, конечно, не смертельно, но подбешивает, поскольку отвлекает от прикладной задачи, ну и громоздкость исходников увеличивает.

В принципе, getopt.h может быть выходом, но он, ЕМНИП, понимает только однобуквенные ключи, а их не всегда хватает, да и во многих консольных программах, даже GNUтых, считается хорошим тоном иметь один и тот же ключ как в однобуквенном, так и в развёрнутом вариантах.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от intelfx

А сколько лет нужно ждать с момента выхода стандарта, прежде чем можно будет его «выбирать»? Десять? Двадцать?

речь о библиотеке, причем, такой, которую можно было бы использовать везде, в том числе там, где кодовая база нa C++98, максимум на C++11. Если бы речь шла о целиком новом ПО - выбирай хоть C++23.

За окном 2023-й. C++17 случился шесть лет назад.

Представь себе, есть проекты из начала 2000х, которые до сих пор поддерживаются.

seiken ★★★★★
()
Ответ на: комментарий от seiken

максимум на C++11

Да масса таких библиотек, в моей коллекции их >30. Надо бы свести их в таблицу и написать статью, но мне лень. :)

dataman ★★★★
() автор топика
Ответ на: комментарий от seiken

речь о библиотеке, причем, такой, которую можно было бы использовать везде, в том числе там, где кодовая база нa C++98

Представь себе, есть проекты из начала 2000х, которые до сих пор поддерживаются

Максимально идиотский аргумент.

Люблй проект из начала 2000х — это уже огромное легаси, с уже установившейся архитектурой и набором зависимостей. Притягивать туда рандомную библиотеку в качестве новой зависимости никто никогда не будет, хоть она на C++17, хоть на C++98. И переписывать в таком проекте разбор аргументов командной строки тем более никто не будет.

Эта библиотека для новых проектов.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Притягивать туда рандомную библиотеку в качестве новой зависимости никто никогда не будет

Фреймворк может быть на 98, а приложения на 11. Появляется новое приложение, начинается поиск подходящей библиотеки. А собирается всё одним компилятором с одинаковыми настройками. И всё собирать под 17 только ради одной библиотеки никто не будет.

Эта библиотека для новых проектов.

Что само по себе, концептуально, довольно странно.

seiken ★★★★★
()
Ответ на: комментарий от seiken

Фреймворк может быть на 98, а приложения на 11.

Во-первых, так не бывает. В C++11 сломали ABI.

Появляется новое приложение, начинается поиск подходящей библиотеки

Во-вторых, так тоже не бывает. Если есть «фреймворк», под который пишутся «приложения» и при этом они все «собираются одним компилятором с одинаковыми настройками» — значит, это какая-то по самые гланды зарегулированная среда и все приложения скорее всего пишутся по шаблону, и притягивать в одно из них рандомную библиотеку тоже никто не будет.

Короче, прекрати натягивать сову на глобус, она рвётся.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Во-первых, так не бывает. В

Ну пусть будет везде 11

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

Обычная среда, в которой компиляция управляется централизовано для всех частей системы, и все утилиты, механизмы многопоточности, IPC, RPC определены заранее, фиксированы и меняются только централизовано. И вот, когда будет выбор, либо getopt, либо что-то на 11, либо вот эта 17я, «рандомной» библиотекой как раз окажется 17я.

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

С разбором командной строки пример не очень, потому что если уже есть буст, то там оно есть.

Но вот, например, запросто может понадобиться валидатор XML или JSON, и тогда выбор будет ограничен 11.

seiken ★★★★★
()
Ответ на: комментарий от seiken

c++14, c++17 довольно ходовые варианты. с++11 требовать это уже моветон.

windprop2
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.