[ненависти псто] Всё больше убеждаюсь, что 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

[fatoff.livejournal.com]

Когда библиотечки начинают претендовать на натягивание C++ на глобус, ещё не то вылазит. Давно уже пора всем для app development использовать единую Qt, как платформу. Она разумная, вот QSettings вместо этого libconfig с операторам "доступа", которые не дают компилировать код.

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

[dememax]

Единую... Ок.
Значит, разумная, добрая...
Скажите, а вы - ходите строем?
;-)

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

[fatoff.livejournal.com]

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

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

[dememax]

Бывает!

Скорее, это - эффект человека с молотком: после этого всё, что попадается на глаза - превращается в гвоздь!

И много приходится с Qt работать?

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

[fatoff.livejournal.com]

За 10 лет третья моя работа с. Вторая подряд. Сейчас рисуем под эмбеддед Линукс, а борд ещё не готов, нет hardware. То есть, в процессе дорабатываем спеки для хардверщиков. Как-то: иметь множественные network interface. Аппликуха такая, в десктопной среде довольно трудно емулировать. Вот подскажи, как одновременно к одному линуксу подключить несколько WiFi камер, и стримить каждую в своё окошко?

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

[dememax]

А я не очень понимаю, в чём эта, в обобщённом виде, задача отличается от десктопного варианта. Некоторые современные встроенные системы дадут ещё фору тому, что было десктопом лет пять назад.

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

Если одна сетевая карта - справляется (и, соответственно, внутренняя шина), то какие проблемы принимать на один сетевой интерфейс с разных камер? У нас железяки были в прошлом проекте - старые (думаю, до 2010 разработанные, но в авионике - свои приколы), сейчас - поновее, с некоторыми из них - можно работать, как с десктопом, достаточно мощные.

Скажем, если вы получаете закодированное, например, в H.26x изображение, то на железке нужен железячный декодер. Если этот декодер - без особенностей (например, воспользоваться им - можно, но нужно особым образом память управлять, бывает и такое), то хорошо, иначе у тебя начинаются "пляски с бубнами". Не мешает убедиться ещё и, а можно ли несколько параллельных потоков декодировать, хватит ли мощности...

У нас сейчас на работе проект, где ужа с ежом скрещивают, между FPGA и производительным ARM'ом нужно данные гонять... И вот там всплывают подробности, что шина - может так работать, но так - нет, а если ещё тут - то, то... С Qt - там тоже всплывают проблемы адаптирования, сборки, а там ещё - OpenGL/CL, но я этим уже - не занимаюсь...

Короче, надо исходить из того, что вы собираетесь делать, на какой архитектуре (по опыту, многие производители типа Марвелла и НВидии - дают немодифицируемые блобы в виде компонентво системы, а уже они накладывают ограничение на версию системы и компилятора, драйвера, и пр.), как, какой запас есть (по принятию трафика извне, по прогону трафика внутри, по отдаче, по памяти, по производительности, ...).

В общем, однозначного ответа на такой общий вопрос - нет.

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

[fatoff.livejournal.com]

Спасибо, пока что именно при помощи USB WiFi dongle пытаюсь эмулировать.
Тут Qt слабовата, не могу найти пока способ ассоциировать SSID c Network Interface.
Обе абстракции во фреймворке есть, а как их соотнести, до того как открыл сессию, интересный вопрос.

А наличествующий десктопный Network Manager (часть GNOME?), через который, по идее, можно достучаться до корректной инициализации сессии по ssid через правильный интерфейс, тот заведомо будет отсутствовать в железке.

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

[dememax]

Я вообще-то не совсем понимаю, о каком идентификаторе идёт речь и зачем для него узнавать интерфейс, какая задача решается?

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

[fatoff.livejournal.com]

Я просто любопытствую, так как что-то похожее читал у тебя, тематика, в смысле. Ответить может быть не просто, не требую.

SSID -- Service Set Identifier. Для WiFi это название "сети", мы его выбираем, затем пароль вводим. Вот что выводит ifconfig для двух WiFi адаптеров в системе. К каждому подключена WiFi-камера-сеть.

ifconfig -a

wlp2s0 Link encap:Ethernet HWaddr f8:16:54:bd:d3:19
inet addr:10.5.5.100 Bcast:10.5.5.255 Mask:255.255.255.0
inet6 addr: fe80::6bcf:8ea9:849c:5903/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1059967 errors:0 dropped:0 overruns:0 frame:0
TX packets:211718 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1381151702 (1.3 GB) TX bytes:26866934 (26.8 MB)

wlx048d392ae972 Link encap:Ethernet HWaddr 04:8d:39:2a:e9:72
inet addr:10.5.5.101 Bcast:10.5.5.255 Mask:255.255.255.0
inet6 addr: fe80::1c4a:accf:80b:e66c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16458 errors:0 dropped:0 overruns:0 frame:0
TX packets:1164 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:21487391 (21.4 MB) TX bytes:213597 (213.5 KB)

Использую из этого inet addr:10.5.5.100 для привязки сокета, через которого идёт UDP-стрим от камеры. Работает. Собственный IP адрес каждой из камер может быть даже фиксированным и одинаковым с другими камерами, так что мало помогает. Но не могу узнать, какой inet add для какого SSID.

Вот тут API для конкретных WiFi камер. Нам надо их подключать в количестве более одной.

Там есть ещё одна проблема, что inet addr двух разных адаптеров зачастую повторяется (!)

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

[dememax]

О, я смотрю, народ подменяет собой точку доступа для этих камер: http://goprohero.readthedocs.io/en/latest/Wifi%20Research/

Т.е., SSID - это комбинация специфического префикса и мак-адреса:

GoPro Remote Mode

This follow setup allows a Linux computer to appear as a GoPro remote to the GoPro cameras. To do this, we will set up an access point and DHCP server. In order to appear as a GoPro remote, the MAC address of the access point interface must use GoPro's OUI which is D8:96:85. So something like D8:96:85:00:00:00 will do. The access point SSID also must be in a special form - "HERO-RC-#####" where the hashes are the last 6 characters of the AP's mac address. From there, we use DHCP to hand the camera an IP, and then it is on our network!

Т.е., эти камеры - пассивны в плане получения IP-адреса в сети.

Как вы организуете настройку самих камер?
Или камеры - уже настроены другими, а вы делаете снифирилку, которая позволяет мониторить все камеры в округе? ;-)

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

[fatoff.livejournal.com]

Спасибо за взгляд с такой стороны, надо обдумать, как это поможет. Натыкался сам, но не увидев прямого ответа на свой вопрос, пошёл дальше. А SSID у них интересный. Ну, полезно для фильтра. Hotspot повертел, покрутил, странно себя ведёт, наверное из-за адаптера. Надо вникнуть, чего же они добились.

У камер есть WiFi пароль, чего их нюхать, вполне тривиальное использование, когда наш потенциальный юзверь хочет подключить и настроить под разными углами несколько штук.

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

[dememax]

Слушай, мне лень сейчас искать, читать доки по этим камерам.

Ведь, чтобы они в сети появились, они же должны подключиться по вафле куда-то, получить адрес...
Или они сами из себя могут представлять точку доступа?
Или там - ad-hoc соединение и они сами себе параметры устанавливают из прошивки?

Дока на API - больше запутывает: что значит "WiFi пароль", когда он объясняется в контексте HTTP-запроса? Чтобы этот запрос сделать, надо чтобы уже был IP уровень, т.е. WiFi уже настроен.

Или там есть замечательное:

Because of this the camera only responds to GET requests when is in APP mode, to turn the camera to APP mode send a magic packet (WoL) with these parameters: MAC ADDRESS OF THE CAMERA, 10.5.5.9 as IP ADDRESS, Subnet Mask 255.255.255.0, Port 9. For the Hero4 Session, this magic packet has to be sent when your project wants to operate with the camera.

В общем, у меня больше вопросов, чем возможности объяснить.

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

[fatoff.livejournal.com]

Спасибо!, не имел в виду работать за меня, тем не менее.

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]

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

[madf.livejournal.com]

QSettings? Которая без спросу в фоне по таймеру в файл пишет? Спасибо, накушался.
Парсер ini-файлов пишется на коленке за 5 минут.

[fatoff.livejournal.com]

По таймеру? Интересно. На доки, или исходный код Qt не покажете? Просто не знаю про эту фичу.

[madf.livejournal.com]

http://doc.qt.io/qt-5/qsettings.html#sync
http://doc.qt.io/qt-4.8/qsettings.html#sync

Сам не знал, пока в одном из проектов не начал искать где же они пишут сеттингсы в файл. Оказалось что нигде.

Re:function is called automatically... and by the event loop at regular intervals

[dememax]

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

Re: function is called automatically... and by the event loop at regular intervals

[madf.livejournal.com]

Я был в ярости :)
Qt — хорошая (за неимением лучшего) графическая библиотека. Все остальное у них реализовано... ну скажем не самым лучшим образом. Начать с того что у них в XXI веке до сих пор свои контейнеры и алгоритмы. При чем внутри там все больше и больше STL.

Re: function is called automatically... and by the event loop at regular intervals

[dememax]

А, что это очень даже отражает изначальный комментарий в ветке:

Давно уже пора всем для app development использовать единую Qt, как платформу. Она разумная, вот ...

:-)
Тоже, думаешь, писалось студентами в приступе жажды кодирования и потом переделать-переписать это нормально уже невозможно?

Ещё что мне у них "нравится": свой препроцессор.

Re: function is called automatically... and by the event loop at regular intervals

[fatoff.livejournal.com]

Никакой проблемы с контейнерами от Qt, либо STL в кьютишном коде нет. Есть даже мудрики, что производительность котейнеров тех и других теститровали. Ничего интересного. Мне нравятся некоторые специфические типы для работы с контейнерами в Qt, вроде QMutableListIterator.

Re: function is called automatically... and by the event loop at regular intervals

[madf.livejournal.com]

Вопрос не в производительности а в совместимости. Когда пишешь софт на Qt — ты практически обречен использовать только Qt. Любое взаимодействие с не-Qt кодом требует переноса данных из одних контейнеров в другие. Это лишний бесполезный код и падение производительности.
Qt застряло в каменном веке со своим убогим qmake, ужасным moc и самодельным STL. Это все им приходиться тянуть на себе, а у них уже были проблемы с финансированием.
Я надеюсь что когда-то этот монстр издохнет и какой-то хороший человек его форкнет, оставив только графику и приведя ее интерфейсы к стандартным типам данных.

Re: function is called automatically... and by the event loop at regular intervals

[fatoff.livejournal.com]

Совершенно не обречён никто использовать только Qt-шные котейнеры, более того, они теперь совместимы с STL на уровне применения к ним алгоритмов и итераторов. Хотя, грязи-то найти можно. Отличная платформа для программирования, кто знает MFC / ATL / WxWdigets в массе не против подписаться.

Лучше скажите про альтернативу.

Re: function is called automatically... and by the event loop at regular intervals

[madf.livejournal.com]

Обречен-обречен. Там практически везде QString да QByteArray.

Отличная GUI-библиотека. Сеть, файловая система, сигнало-слоты — лучше реализованы в Boost. Контейнеры, алгоритмы — в STL.

Re: function is called automatically... and by the event loop at regular intervals

[fatoff.livejournal.com]

Мне сами представители Qt компании сказали, что только приветствуют использование современных контейнеров из STL. Я понял, что Qt по прежнему отличная GUI библиотека? Ну да ладно. Что не так с сигналами и слотами при их интенсивном использовании даже догадываться на начинал, ради того мне Boost не надо.

Re: function is called automatically... and by the event loop at regular intervals

[dememax]

Увидел твой пост под замком, вспомнил эту беседу.
У нас, похоже, в результате, будут отказываться от Qt в силу уже нанесённой пользы проекту.
Не на текущей итерации, но уже посматривают, на что бы перейти потом...
Если интересно, могу потом рассказать.

Re: function is called automatically... and by the event loop at regular intervals

[fatoff.livejournal.com]

"В результате". На наши результаты если что влияет, то точно не Qt, более того, никому в голову не приходит идея чем-то заменять. Виртуальный интерфейс от WiFi не получается задействовать, вот, реальная проблема, хотя в спецификации 802.11x оно есть.

[madf.livejournal.com]

Вот весь этот opensource такой. Я тоже хотил один проект порефакторить, так они изменения быстрее вносят чем я рефакторить успеваю. Много реально хороших вещей пишется студентами в приступе жажды кодирования и потом переделать-переписать это нормально уже невозможно.

Re: Вот весь этот opensource такой.

[dememax]

Ну, зачем вот так вот сразу обобщать! :-)

Конечно, в нём много такого.
Ну, чтобы прям вот весь, не, не думаю!

Re: Вот весь этот opensource такой.

[madf.livejournal.com]

Ну ок, но мне пока хватит пальцев одной руки чтобы перечислить хорошие из тех что сталкивался :)