[ненависти псто] Всё больше убеждаюсь, что libconfig - не лучший выбор

[dememax]

И полное отсутствие пакетов, которые зависят от этой библиотеки на моей системе - это только подтверждает.

Речь про 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()) и вперёд!
Почему другие должны страдать, кто не пользуется другими библиотеками, зачем ограничивать в интуитивно понятной выразительности людей на плюсах?!

Comments

Re: Давно уже пора всем для app development

[fatoff.livejournal.com]

Но конкретные вопросы не могу просто оставить:
1. Или они сами из себя могут представлять точку доступа?
Они прямо как WiFi router себя ведут. Не уверен на счёт многочисленных подключений.
2. Или там - ad-hoc соединение и они сами себе параметры устанавливают из прошивки?
Через REST выставляются все параметры камеры.
3. Дока на API - больше запутывает: что значит "WiFi пароль", когда он объясняется в контексте HTTP-запроса? Чтобы этот запрос сделать, надо чтобы уже был IP уровень, т.е. WiFi уже настроен.
Именно как у WiFi раутера пароль. В запросе никакой аутенфикации, просто текст по http get.

Ах да, ты открыл страничку про особую камеру Hero4 Pro Session. Она "тупая", её надо актировать в режим разговора с приложением APP. Как подключился к WiFi её, так надо ей послать Wake On LAN пакет по UDP ей. Больше никакой особенности у Session. Потом раз в 2.5 секунды все камеры хотят Keep Alive пакет по тому же самому UDP.

Re: Давно уже пора всем для app development

[dememax]

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

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

Re: Давно уже пора всем для app development

[fatoff.livejournal.com]

Дык. Пока до штучку доработаем, сегодняшние гаджеты уже на порядок подешевеют.