nephrael22 июл 2012 в 17:18

Portable Components, вспомогательные средства разработки ПО

13 мин

8.9K

C++ * Программирование *

+52

Комментарии 46

marklarius 22 июл 2012 в 17:50

А почему изобретён велосипед для логгинга? Ведь есть же log4cpp.

nephrael 22 июл 2012 в 17:56

Так в том то и дело, что если вы используете POCO, то вам не нужно обременять себя заботой о ведении проекта с дополнительными библиотеками. Как следствие отпадает необходимость в обновлении, перекомпилировании.

marklarius 22 июл 2012 в 17:57

Интересно. Если честно, то Я статью просмотрел мельком — обещаю попробовать на деле и доложить о впечатлениях.

EvilsInterrupt 22 июл 2012 в 19:11

Боже упаси юзать log4cpp, куда лучше boost.log или glog

marklarius 22 июл 2012 в 19:34

Legacy code :(

tenzink 23 июл 2012 в 05:46

Ещё очень неплох log4cplus

EvilsInterrupt 23 июл 2012 в 08:12

Какие ваши критерии по выбору библиотеки логирования?

tenzink 23 июл 2012 в 08:46

Я рассматривал следующие критерии:
— Конфигурации логирования без перекомпиляции приложения. Возможность переконфигурации уже запущенного приложения «на лету»
— Поддержка многопоточности
— Возможность вывода в stdout/stderr/file/debug output/console/… Возможность асинхронного логирования
— Возможность настройки формата вывода лога
— «Хорошая» лицензия
— Кроссплатформенность + поддержка VS 2010
— Библиотека не «заброшена»
— Поддержка нескольких уровней логирования
— (желательно) наличие stream-like интерфейса (как при выводе в std::ostream)

Под них хорошо подходили log4cplus, и POCO::Logging. В итоге остановились на первом (не хотелось тянуть всю библиотеку только ради логирования)

Gorthauer87 22 июл 2012 в 18:28

std::string text = config().getString("Group.ValueText"); // text == "Hello world"
int value = config().getInt("Group.IntValue"); // value == 123

Ну что за адЪ? Почему нельзя было сделать

auto text = config().value("Group.ValueText", "Some default text");
auto int = config().value("Group.IntValue", 100500);

marklarius 22 июл 2012 в 18:34

А такая жёсткая привязка к C++0х разве не противопоказана библиотеке широкого применения?

Gorthauer87 22 июл 2012 в 20:06

auto как раз таки не жесткая привязка, просто лень тип вписывать.

marklarius 23 июл 2012 в 18:58

auto, как замена декларации типа это фича C++11, разве не так?

Gorthauer87 23 июл 2012 в 19:51

Да, но это не жесткая привязка, от auto отвязаться гораздо легче, чем от variadic templates например.

nephrael 22 июл 2012 в 18:49

Вопрос стоит скорей, возможно ли использовать такой код в рамках стандарта C++03 и без RTTI

string text = config().value("Group.ValueText");
int integ = config().value("Group.IntValue");

И насколько данный код будет производителен.

nephrael 22 июл 2012 в 18:50

И к тому же возможны преобразование Int -> string, но не всегда наоборот (ваш К.О.)

Gorthauer87 22 июл 2012 в 20:08

А вы не поняли кода просто

template <typename T>
T Config::value(const std::string &key, const T &defValue);

А там уж или преобразование типа Any в нужный тип делать или специализировать для int, std::string, const char * и так далее. Скорость будет точно такой же как и в случае с кучей stringValue, intValue, а объем кода заметно меньше и апи чище.

nephrael 22 июл 2012 в 21:00

Только там не Any, разработчики решили не связываться с RTTI, наверняка поэтому такая «красота».
Однако ваш метод имеет право на жизнь, можно отправить предложение разработчикам.

Gorthauer87 23 июл 2012 в 09:47

QVariant не использует RTTI, там внутри нет никаких typeid и dynamic_cast'ов.

Riateche 22 июл 2012 в 21:05

Если возникнет необходимость различать, например, int и char, то придется писать что-то вроде value(key, (char) 1), это получается более громоздко, чем charValue(key). К тому же приведение типов может сработать очень неочевидно и привести к неожиданным последствиям, а в коде будет выглядеть вполне правдоподобно. Ярким пример тому — функция QString::arg, значение которой может разительно изменяться в зависимости от того, передали вы 'x' или QChar('x'). Поэтому рассматривать перегрузку метода как панацею не стоит.

А еще когда вы пишете «stringValue», код более читабельный: сразу видно, какой тип вы ожидаете на выходе. А в вашем варианте сразу это поймет только человек, который знаком с функцией value и знает, что ее тип зависит от типа второго аргумента. По умолчанию это неочевидно.

Я не утверждаю, что ваш вариант хуже. Я считаю, в каждом из них есть плюсы и минусы. А мне больше всего нравится вариант, реализованный в Qt: функция QSettings::value возвращает объект псевдодинамического типа QVariant, который затем может быть преобразован к нужному типу с помощью toString(), toInt() и т.д. Кстати, в Poco вроде есть аналог этого типа.

nephrael 22 июл 2012 в 21:30

Кстати, в Poco вроде есть аналог этого типа.
Да, Any и DynamicAny

Gorthauer87 23 июл 2012 в 09:48

Под капотом пусть лучше будет как раз тот вариант с аналогом QVariant'а

webhamster 23 июл 2012 в 07:15

> auto int = config().value(«Group.IntValue», 100500);

Меня все больше и больше страшат нововведения в стандарт C++.
Что сия команда значит?

nephrael 23 июл 2012 в 08:29

auto intA = config().value(«Group.IntValue», 100500);
//Все довольно таки просто:
//config().value(«Group.IntValue», 100500) - вернет int, в соотв. с типом 2ой переменной
//при инициализации intA примет тип rvalue, то есть int
//данная декларация аналогична
int intA = config().value(«Group.IntValue», 100500);

webhamster 27 июл 2012 в 12:42

Да это понятно, просто товарищ Gorthauer87 допустил ошибку в коде, вместо

auto intA =

написал

auto int =

Я вот про что спрашивал.

nephrael 27 июл 2012 в 13:15

Это опечатка, вестимо

lui 22 июл 2012 в 18:59

Как же задолбала эта КДПВ!
Что ни статья на околодевовскую тематику, так обязательно в ней этот дом на курьих ножках :)

nephrael 22 июл 2012 в 19:17

Но ведь картинка то прикольная

nephrael 22 июл 2012 в 19:23

да и всего то 10 статей

dustalov 22 июл 2012 в 19:59

Программирование на XML. Теперь и в C++.

EvilsInterrupt 22 июл 2012 в 19:59

Сами эти POCO не во всем придерживаются того что придумали. Соглассно их кодинг-стайлу: строчка из poco-1.4.3p1\Net\src\NameValueCollection.cpp:

const std::string& NameValueCollection::get(const std::string& name, const std::string& defaultValue) const
{

должна быть совершенно другой:

const std::string& NameValueCollection::get(
    const std::string& name,
    const std::string& defaultValue) const
{

Странно. Вроде дядьки умные, а почему-то не юзают то что сами и разрабатывают!

НЛО прилетело и опубликовало эту надпись здесь

f0b0s 22 июл 2012 в 21:07

Класс! Следующее же мелкое приложение напишу с POCO, столько всяких мелких вкусностей, которые раньше руками приходилось делать или собирать: glog, TCLAP (аргумент командной строки) и прочее.

Спасибо!

nephrael 22 июл 2012 в 21:57

Добро пожаловать на темную сторону.

f0b0s 22 июл 2012 в 22:02

Наоборот, светлая сторона просвещения. Темная сторона с++ это как раз сильная разрозненность библиотек и подходов. Стандартизация, хотя бы де-факто, базовых возможностей — это хорошо. Не нужно изобретать логгер каждый раз. Был бы стандартный — 90% разработчиков бы пользовались. Так же и со всякими приведенными в посте остальными вещами.

Zigmar 23 июл 2012 в 02:28

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

nephrael 23 июл 2012 в 06:09

Это действительно так, но boost принято рассматривать STL-like библиотеку общего назначения, а POCO всё же ориентирована на скорейшую разработку сетевых приложений. Да и POCO более высокоуровневая, нежели boost.

Gorthauer87 23 июл 2012 в 09:50

Хотите стандартизацию дефакто, юзайте Qt или буст на крайняк, а про остальное забудьте

f0b0s 23 июл 2012 в 12:18

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

Ну поко миленький и довольно известный. Еще из известных слышал про ACE и ICU (для юникода, юзал, умеет все, что только можно представить, ибо это и есть реализация стандарта юникода)

EvilsInterrupt 23 июл 2012 в 05:37

Я отказался от TCLAP в пользу boost.program_options и не жалею! )

f0b0s 23 июл 2012 в 12:19

Ну это если вы тянете буст. На тот момент я не тянул, там был небольшой проект, но с кучей опций. Зато он header-only, что сильно выделяло его на фоне всех остальных библиотек.

EvilsInterrupt 23 июл 2012 в 12:40

>>На тот момент я не тянул
Что вы вкладываете в эти слова? Не знание?

>>Зато он header-only
Буст солидной частью тоже в хидер-онли

f0b0s 23 июл 2012 в 12:43

Не изпользовал. Это в некотором смысле была лабараторная и была острая необходимость, чтобы проект суммарно занимал несколько мегабайт. Я знаю, что можно с помощью bcp отобрать только нужные хедеры из буста, но там такие зависимости, что даже самый незначительный shared_ptr тянет 3 мб сорцов.

>> Буст солидной частью тоже в хидер-онли
бесспорно, но про program_options я не знаю, а там бывает, что на ровном месте библиотека требует компиляции. boost filesystem, например.