Новая утилита мониторинга ИБП upsm 1.0.0

Какой-то хелоу вордный велосипед

if (status == "OL")
     {
      t = tr ("voltage normal");
      tray_icon.setIcon (icon_green);
     }   
     
  if (status == "OL TRIM")
     {
      t = tr ("ups is trimming voltage");
      tray_icon.setIcon (icon_yellow);
     } 
  
  if (status == "OB")
     {
      t = tr ("battery mode");
      tray_icon.setIcon (icon_red);
     } 

Мне кажется тут чего-то не хватает

фронт-энд к утилите upsc из состава Network UPS Tools.

До сих пор юзаю knutsclient

Да, тут явно напрашивается парочка else. Но тут вопрос, с какой частотой этот статус опрашивается. Если раз в секунду, то оно явно некритично.

Если раз в секунду, то оно явно некритично.

Вопрос не столько в быстроте исполнения, а быдлокодинга.

Я не раз видел, что афтор не поставил else. Потом ещё условия нарастил, да и сами исполняемые блоки разрослись. И понять уже как должен исполняться код становится не так просто, реально это else или нет, особенно если автор сам сделает ошибку-описку в какой-нибудь условии (по типу копи паста, но забыл поправить).

Так что за такое надо томиком Кнута по голове.

Да, тут явно напрашивается парочка else
status == «OB»

В плюсах так можно ? 0_o

Откуда вы такие лезете?

http://www.cplusplus.com/reference/string/string/operators/

От туда откуда и ты, я плюсы не знаю и знать не желаю, подобные сравнения объекта (хоть и строкового) и строки выглядят (для меня) инопланетно.

Спасибо.

Божественная перегрузка операторов. Сишники всасывают.

Сишники всасывают.

Пффф, мы явно сравниваем массивы байт без лишних сущностей.

В C есть массивы?

Эмм, да.

Да, тут явно напрашивается парочка else. Но тут вопрос, с какой частотой этот статус опрашивается. Если раз в секунду, то оно явно некритично.

Всегда надо оставлять потенциал для развития программы ;) Вообще частота опроса севера/обновления данных задается в настройках.

Откуда вы такие лезете?

«Эта программа имеет бесконечный потенциал развития» - хороший пример как можно сказать толерантно нехорошее слово

Network UPS Tools

ни один мой ИБП ниразу не подхватил.

До сих пор юзаю knutsclient

Я бы тоже его использовал, если бы не появилась Плазма вместо старого доброго KDE. А так - пришлось писать нечто для визуального мониторинга самому. Я написал upsm примерно за полчаса просто для домашнего использования, и лишь потом пришла мысль «оформить» его для публичного выкладывания. Если бы я задумывал так изначально, то сделал бы, допустим, настраиваемый пользователем список, какие переменные ИБП показывать, а не жестко три параметра.

Тогда else как раз лучше добавить. :)

>В плюсах так можно ? 0_o

Именно.

И то, что в Си приходится обкладываться пирамидой вызовов str*, весьма затрудняет его использование в прикладном программировании.

Тогда else как раз лучше добавить. :)

Так уже добавил :) Вообще это было бы весомо при программировании для Спектрума. Хотя если всё же писать хорошо, то конечно два лишних сравнения строк это смертный грех.

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

Ну если это считать массивом...

int a = 0;
int b[] = {1,2};
a = a[b];

Что это за бред?

И? А что для тебя массив? Абстрактный изолированный и безопасный тип данных который содержит линейную стопку других типов?

Абстрактный? Да, это такая абстракция данных. Несколько более высокоуровневая, чем доступ к памяти через указатель со смещением. Изолированный и безопасный? Ну это уж как получится. И оно не обязательно «стопка». Может быть и прямоугольник или кубик или ...

Да я к тому что ты сказал что массив в С не массив, в прямом смысле этого слова какая разница объект языка это или просто сырой набор байт с маленьким сахаром в виде []. Если приспичит можно и в С сделать что-то вроде

typedef struct
{
   size_t    len;
   wchar_t * str;
}string_t;

И наделать безопасных функций для обработки/сравнения/выделения/обрезания и прочего, при этом уже финты с указателями не прокатят (можно с указателями на структуру играть да) вернее не то что не прокатят, а просто делать их не нужно.

Так ведь и в самом деле не массив :)
Не, при наличии холодной головы и горячего сердцапрямых рук, C  — безусловно мощный и универсальный инструмент. И при «приспичит» реализовать на нём можно всё. Но к собственно языковым возможностям отношение оно будет иметь слабое.

два лишних сравнения строк это смертный грех

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

if (status ==

Блин, я бы на свитче это переписал.

Свитч со строками? :)

Есть для apcupsd что-то подобное? upsmon - древность 2008 года, а веб-мониторинг неудобен.

upsmon - древность 2008 год

Вот это древность? https://github.com/networkupstools/nut/

Ошибочка вышла - имел ввиду gapsmon (GUI-мониторинг для apcupsd)

Ошибочка вышла - имел ввиду gapsmon (GUI-мониторинг для apcupsd)

Я бы мог добавить в upsm поддержку apcupsd, однако apcupsd не хочет видеть мой ИБП (STATUS: COMMLOST при любых раскладах), а без тестирования, вслепую писать не хочу, хотя можно было бы.

Тут явно напрвшивается std::map и std::pair, std::make_pair из STL:

C++ 0x11 map<const QString, pair<QString,QIcon>> Map= { { «OL», { tr («voltage normal»), icon_green } }, { «OL TRIM», { tr(«ups is trimming voltage»), icon_yellow } }, { «OB», { tr («battery mode»), icon_red }} }; auto pIterator=Map.find(status); if (pIterator!=Map.end()) { t = pIterator->second->first; tray_icon.setIcon(pIterator->second->second); };

C++ map<const QString, pair<QString,QIcon>> Map; Map[«OL»]=std::make_pair(tr («voltage normal»), icon_green); Map[«OL TRIM»]=std::make_pair(tr(«ups is trimming voltage»), icon_yellow); Map[«OB»]=std::make_pair(tr («battery mode»), icon_red); map<const QString, pair<QString,QIcon>>::iterator pIterator=Map.find(status); if (pIterator!=Map.end()) { t = pIterator->second->first; tray_icon.setIcon(pIterator->second->second); };

Новая и уже стабильная версия по semver? Лол.

«Это не критика, это гон троллей против славянского ПО.» (c) аффтар

Боюсь, что авторский вариант (если в него добавить недостающие else) куда более нагляден, чем эта лапша из pair и map. Хотя если количество вариантов перевалит за десяток - возможно, картина будет другая.

Хотя если всё же писать хорошо, то конечно два лишних сравнения строк это смертный грех.

Да. Я вот тоже считаю, что свой код надо любить и стараться писать так, чтобы не было чувства неудовлетворённости. Благо в хобби-проектах это обычно достигается легче: заказчики/начальство не давят, время есть.

Если приспичит можно и в С сделать что-то вроде...

...и получить очередной GObject.

Нет.

В идеале вообще не делать ничего hardcoded и вынести связи символьных кодов ИБП с сообщениями в отдельный файл, который бы потом парсился в действительно какую-нибудь map-подобную штуку. Таким образом можно было бы припахать второй такой файл уже для apcupsd, и дать возможность переключения между двумя демонами мониторинга. Но пока я не вижу в этом смысла, поскольку apcupsd не видит мой ИБП, стало быть я не могу проверить работу apcupsd и не отпадает смысл развития программы в этом направлении. Покамест я вижу несколько других направлений развития upsm - добавление реакции на события (допустим, питание от батареи ИБП более стольких-то минут - запуск пользовательской команды для выключения компа), настройки выбора цветов, а может быть общение с USB-устройством средствами самого upsm, а не через демон, но это если моё желание изучить этот вопрос будет сильнее лени и появится свободное время.

Не согласен. При использовании контейнера четко видна структура данных и алгоритм действия. Первое четко отделено от другого. Использование одного и того же кода 2 раза - зло. Использование кода 3 раза, как в примере - мегазло. Такое в современных условия можно оправдать только тем, что человек не умеет использовать конейнеры и не знает STL.

Ты можешь свои 2 варианта в тег code обрамить? А то сейчас твой вариант трудночитаем даже теми, кто знаком с STL.

Обоснуй. По-моему, так явления одного порядка.

Я не глубоко знаю GObject, но всё же сам он основан на GType и вместе они образуют целую инфраструктуру динамических типов, я же просто делаю структуру и функции где будет явно отслеживаться длинна строки, всё. И я не понимаю негодования, составные типы данных типа структур обычное дело и что в этом такого? И не GObject единым если мне захочется контроля я не стану городить свой велосипед и возьму libcello где всё готово и можно легко понять что в кишках в отличии от GObject где чёрт ногу сломит.

Вот когда в ОПП язычках делают объекты на 100500 элементов со скрытыми/открытыми интерфейсами, общими методами причём понять что происходит внутри мало того что сложно в виду того что тонна кода так ещё это возбраняется, мол это чёрная короба это класс это объект он должен делать что-то своими интерфейсами, а что внутри не ваше дело. Это норма, а если я делаю в С составной тип на 2 элемента то всё, капут )))

Использование кода 3 раза, как в примере - мегазло.

Когда я вечером после установки Mageia Cauldron писал себе утилиту мониторинга, мне надо было видеть итог работы как можно быстрее, а не продумывать архитектуру программы :)

Обновление upsm - добавлена интеграция с рабочим столом, иконка, починено make install.

Да не понял ты меня, ни негодования, ни капута нет. Я просто констатирую схожесть подходов - попытка сделать на Си защищённую строку.

libcello

А вот за это спасибо, не знал про такую.