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

[marklarius]

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

[nephrael]

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

[marklarius]

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

[EvilsInterrupt]

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

[marklarius]

Legacy code :(

[tenzink]

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

[EvilsInterrupt]

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

[tenzink]

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

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

[marklarius]

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

[marklarius]

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

[nephrael]

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

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

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

[nephrael]

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

[nephrael]

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

[Riateche]

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

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

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

[nephrael]

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

[webhamster]

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

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

[nephrael]

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]

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

auto intA =

написал

auto int =

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

[nephrael]

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

[lui]

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

[nephrael]

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

[nephrael]

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

[dustalov]

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

[EvilsInterrupt]

Сами эти 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]

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

Спасибо!

[nephrael]

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

[f0b0s]

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

[Zigmar]

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

[nephrael]

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

[f0b0s]

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

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

[EvilsInterrupt]

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

[f0b0s]

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

[EvilsInterrupt]

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

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

[f0b0s]

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

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

[northicewind]

Спасибо. Интересно. Сам недавно смотрел на POCO, но так и не решил использовать. Было бы очень интересно почитать

о модулях XML, ZIP, Data, Net

и особенно о

создании высокопроизводительных серверов на POCO

[nephrael]

Я думаю к середине или к концу недели первая статья (XML, ZIP, Data, Net) будет готова. Вторая к концу след. недели.

[EvilsInterrupt]

А можете порыться и описать что-нить для локализации. О чем это я вы можете понять почитав немного о boost.locale или GNU Gettext.

[DaleMartinWatson]

Картинка такая жизненная…