[ненависти псто] Всё больше убеждаюсь, что libconfig - не лучший выбор
И полное отсутствие пакетов, которые зависят от этой библиотеки на моей системе - это только подтверждает.
Речь про https://github.com/hyperrealm/libconfig
Не скажу, что это был мой выбор.
Но очень быстро я нашёл, в чём разочароваться.
Сначала меня удивило, что старый добрый what() у исключений возвращает не конкретное сообщение об ошибке (хотя не так уж и сложно составить детальное описание проблемы в этом месте), а имя класса исключения, например:
const char *ParseException::what() const throw()
{
return("ParseException");
}
Вообще, если исключения включены, то я класс - и так могу через RTTI узнать. Непонятно, зачем это вообще, ведь нужно возвращать осмысленное сообщение, вся информация в полях для этого есть. Больше похоже на остатки от прототипа или заглушкам к первой версии.
Думал предложить пулл-реквест, сделал себе копию проекта, а там - новая засада с временными файлами, непонятно, зачем их хранить в системе контроля версий, я ещё понимаю раздавать в бандле для релизов. Короче, бросил эту идею. Хотя, изменения ортогональны этим, но как-то руки уже опустились.
А сегодня я напоролся на проблему, которая у них идёт - [та-да-а-а-а-а!] - за номером раз!
Имеем на интерфейсе класса Setting среди прочего такие операторы приведения:
operator const char *() const;
operator std::string() const;
На что автор библиотеки отвечает: hyperrealm commented on Mar 10, 2014
The const char* casts are very useful actually, when you are using libconfig with a framework that has its own string class (e.g., Qt or my libcommonc++). If you remove these then every conversion will have to go through std::string first, which is wasteful as it involves heap allocation and memory copying.
I would rather get rid of the std::string assignment and cast operators, if this doesn't break existing code that uses them.
По-моему, если уж тебе в другую библиотеку без потерь нужно передать что-то - так и адаптируй для той библиотеки этот случай с помощью отдельного оператора, на публичном интерфейсе - сделай возможность (скажем, метод c_str()) и вперёд!
Почему другие должны страдать, кто не пользуется другими библиотеками, зачем ограничивать в интуитивно понятной выразительности людей на плюсах?!
Речь про https://github.com/hyperrealm/libconfig
Не скажу, что это был мой выбор.
Но очень быстро я нашёл, в чём разочароваться.
Сначала меня удивило, что старый добрый what() у исключений возвращает не конкретное сообщение об ошибке (хотя не так уж и сложно составить детальное описание проблемы в этом месте), а имя класса исключения, например:
const char *ParseException::what() const throw()
{
return("ParseException");
}
Вообще, если исключения включены, то я класс - и так могу через RTTI узнать. Непонятно, зачем это вообще, ведь нужно возвращать осмысленное сообщение, вся информация в полях для этого есть. Больше похоже на остатки от прототипа или заглушкам к первой версии.
Думал предложить пулл-реквест, сделал себе копию проекта, а там - новая засада с временными файлами, непонятно, зачем их хранить в системе контроля версий, я ещё понимаю раздавать в бандле для релизов. Короче, бросил эту идею. Хотя, изменения ортогональны этим, но как-то руки уже опустились.
А сегодня я напоролся на проблему, которая у них идёт - [та-да-а-а-а-а!] - за номером раз!
Имеем на интерфейсе класса Setting среди прочего такие операторы приведения:
operator const char *() const;
operator std::string() const;
На что автор библиотеки отвечает: hyperrealm commented on Mar 10, 2014
The const char* casts are very useful actually, when you are using libconfig with a framework that has its own string class (e.g., Qt or my libcommonc++). If you remove these then every conversion will have to go through std::string first, which is wasteful as it involves heap allocation and memory copying.
I would rather get rid of the std::string assignment and cast operators, if this doesn't break existing code that uses them.
По-моему, если уж тебе в другую библиотеку без потерь нужно передать что-то - так и адаптируй для той библиотеки этот случай с помощью отдельного оператора, на публичном интерфейсе - сделай возможность (скажем, метод c_str()) и вперёд!
Почему другие должны страдать, кто не пользуется другими библиотеками, зачем ограничивать в интуитивно понятной выразительности людей на плюсах?!