11

Какие пакеты вы используете для обработки параметров командной строки, настроек и файлов конфигурации?Как вы обрабатываете параметры командной строки и файлы конфигурации?

Я ищу что-то, что читает пользовательские параметры из командной строки и/или из файлов конфигурации.

Параметры (настройки) должны быть разделены на разные группы, поэтому я могу передавать разные (подмножества) параметры для разных объектов в моем коде.

Я знаю boost::program_options, но я не могу привыкнуть к API. Есть ли легкие альтернативы?

(Кстати, вы когда-либо использовать глобальные параметры объекта в коде, который может быть считан из любого места? Или вы считаете, что зло?)

ответ

5

Ну, вы Мне не понравится мой ответ. Я использую boost::program_options. Интерфейс немного привыкает, но, как только у вас есть это, это потрясающе. Просто убедитесь, что выполняете лодку модульного тестирования, потому что если вы получите синтаксис неправильно, вы получите ошибки выполнения.

И, да, я храню их в одном объекте (только для чтения). Я не думаю, что в этом случае это зло. Это один из немногих случаев, когда я могу придумать, где одноэлемент является приемлемым.

+1

+1 для boost :: program_options, но только просто! Я был бы осторожен с использованием программных опций в качестве одноэлементного. Мы были укушены, сделав это в том, что теперь нам нужно добавить разные наборы параметров для разных файлов. Сначала нам нужно вернуться и удалить синглтон, чтобы мы могли хранить разные наборы параметров для каждого отдельного файла. –

+0

Хорошая точка, Ричард. Я использую boost :: program_options для игры, и, очевидно, для каждого процесса достаточно одного набора параметров, но для разных целей это будет плохая идея. – rlbond

+0

Вы все еще в пользу boost :: program_options? Похоже, что он больше не разработан (последний веб-сайт docs был изменен в 2004 году). Использует ли он/совместим с C++ 11? При чтении между строками вашего сообщения это на самом деле не очень хорошая рекомендация: * Просто убедитесь, что делаете лодку модульного тестирования, потому что, если вы получите неверный синтаксис, вы получите ошибки времени выполнения * - это большой красный флаг! – Walter

-4

Apache Ant Попробуйте. Его основное использование - проекты Java, но в нем нет ничего Java, и его можно использовать практически для чего угодно.

Использование довольно простое, и у вас также есть поддержка сообщества. Это действительно хорошо, когда вы делаете то, что вы просите.

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

+3

Uuh, Apache Ant? Инструмент построения? Что он должен делать с чтением параметров командной строки в C++? – Frank

+0

Вы можете сохранить базовый файл конфигурации для C++, но вся фактическая работа может быть выполнена с помощью Ant. См. Http://www.codemesh.com/products/junction/doc/ant_cpp.html или просто http://www.google.com/search?hl=ru&site=&q=using+ant+c%2B%2B&btnG= Поиск –

0

Не уверен в анализе аргументов командной строки. Я не нуждался в очень богатых возможностях в этой области и, как правило, откатился, чтобы сохранить дополнительные зависимости от моего программного обеспечения. В зависимости от ваших потребностей вы можете или не захотите попробовать этот маршрут. Программы C++, которые я написал, обычно не вызывают из командной строки.

С другой стороны, для конфигурационного файла вы действительно не можете использовать формат XML. Это читаемый, расширяемый, структурированный и т. Д. :) Кроме того, есть много XML-парсеров. Несмотря на то, что это библиотека C, я предпочитаю использовать libxml2 с xmlsoft.org.

+0

Зайдите [pugixml.org] (http://pugixml.org) для быстрых парсеров XML, написанных на C++. В качестве бонуса он поддерживает «XPath» и только заголовок! – Sean

3

Если Boost является излишним для вас, GNU Gengetopt, вероятно, тоже, но IMHO, это забавный инструмент, с которым можно возиться.

И, я стараюсь держаться подальше от объектов глобальных опций, я предпочитаю, чтобы каждый класс читал свою собственную конфигурацию. Помимо всей философии «Глобалы - злые», она, как правило, становится постоянно растущей беспорядком, чтобы иметь всю вашу конфигурацию в одном месте, а также сложнее сказать, какие переменные конфигурации используются там где. Если вы держите конфигурацию ближе к тому месту, где она используется, более очевидно, для чего она предназначена, и проще поддерживать ее чистоту.

(Что касается того, что я использую, лично, за все, что в последнее время он был запатентованный командной строки разборе библиотеки, что кто-то в моей компании писал, но это не поможет вам много, к сожалению)

1

GNU getopt довольно хорошо. Если вы хотите чувствовать C++, рассмотрите getoptpp, который является оберткой вокруг родного getopt. Что касается файла конфигурации, вы должны попытаться сделать его настолько глупым, насколько это возможно, чтобы синтаксический анализ был простым. Если вы немного внимательны, вы можете использовать yaac & lex, но это было бы очень большой бакс для небольших приложений.

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

11

В Google мы используем gflags. Он не выполняет конфигурационные файлы, но для флагов это намного менее болезненно, чем использование getopt.

#include <gflags/gflags.h> 
DEFINE_string(server, "foo", "What server to connect to"); 
int main(int argc, char* argv[]) { 
    google::ParseCommandLineFlags(&argc, &argv, true); 
    if (!server.empty()) { 
     Connect(server); 
    } 
} 

Ставит DEFINE_foo в верхней части файла, который должен знать значение флага. Если другие файлы также должны знать значение, вы используете в них DECLARE_foo. Там также очень хорошая поддержка для тестирования, поэтому модульные тесты могут устанавливать разные флаги независимо.

+0

Мне нравится! Выглядит очень прост в использовании. – Milan

1

Если вы работаете с Visual Studio 2005 на x86 и x64 Windows, в утилите SimpleLibPlus library есть несколько полезных утилит для командной строки. Я использовал его и нашел его очень полезным.

3

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

Я до сих пор впечатлен, и я, скорее всего, буду использовать его в будущем, особенно потому, что он поддерживает файлы конфигурации. TCLAP - более сложная библиотека, но простота и дополнительные возможности от ezOptionParser очень привлекательны.

Другие льготы от своего веб-сайта включают в себя (по 0.2.0):

  • Довольно печать разбираемых входов для отладки.
  • Создание сообщения автоматического использования в трех макетах (выровненный, чередующийся или шахматный).
  • Реализация единого заголовка.
  • Зависит только от STL.
  • Произвольные короткие и длинные имена опций (тире '-' или плюс '+' префиксы не требуются).
  • Произвольные разделители списков аргументов.
  • Разрешено несколько экземпляров флагов.
  • Проверка требуемых параметров, количество ожидаемых аргументов на флаг, диапазоны типов данных, диапазоны, определенные пользователем, членство в списках и регистр для строковых списков.
  • Критерии валидации, определяемые строками или константами.
  • Несколько импорт файлов с комментариями.
  • Экспортировать в файл либо задавать параметры, либо все параметры, включая значения по умолчанию, когда они доступны.
  • Опция разбора индекса для зависимых от заказа контекстов.
+0

Я знаю, что это очень старая нить, но просто чтобы кто-то еще не попал в ту же ловушку, что и я, после прочтения этой темы. ezOptionParser хорошо работает для фактических вариантов синтаксического анализа, но у него есть фатальная ошибка, которая приводит к сбою вашего приложения, если вы используете функцию getUsage() для сообщения параметров командной строки. Теперь библиотека не поддерживается автором, поэтому эта ошибка никогда не будет исправлена. Используйте с особой осторожностью; или лучше, используйте что-то еще. – Graham

Смежные вопросы