Какой фреймворк стоит брать для нового проекта? Если брать catch2 то с помощью чего создавать mock объекты удобнее всего?

Или gtest/gmock - непобедим?

Мы обновили свою легковесную C++14 библиотеку для встраивания HTTP-входа в C++ приложения до версии 0.4.3.

Основные изменения в RESTinio со времени последнего анонса:

• новые варианты restinio::run(), позволяющие задать внешний asio::io_context для RESTinio;
• добавлена поддержка sendfile (https://stiffstream.com/en/docs/restinio/0.4/sendfile.html);
• request_id теперь доступен внутри обработчика входящего HTTP-запроса;
• плюс несколько мелких изменений и улучшений в коде самого RESTinio.

Библиотека живет на bitbucket-е (https://bitbucket.org/sobjectizerteam/restinio-0.4) c зеркалом на github-е (https://github.com/Stiffstream/restinio), документация доступна у нас на сайте (https://stiffstream.com/en/docs/restinio/0.4/). Распространяется под BSD-3-CLAUSE лицензией.

Мы создавали RESTinio для того, чтобы иметь возможность асинхронной обработки входящих запросов в случаях, когда для формирования ответа нужно обратиться к медленно отвечающему стороннему сервису. Иногда обращения к таким сторонним сервисам нужно делать посредством HTTP. Для таких целей широко используется Си-шная библиотека libcurl. Подружить асинхронную обработку входящих запросов посредством RESTinio с асинхронной обработкой исходящих запросов посредством libcurl можно несколькими способами. Подробнее эту тему мой коллега раскрыл в небольшой серии статей: часть 1, часть 2, часть 3.

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

• что бы вам хотелось увидеть в RESTinio?
• чего не хотелось бы видеть?
• что останавливает вас от использования RESTinio?

Где такое реализовано???!!! Хочу! Хочу! Хочу!

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

Последние 7 лет я пишу сугубо на C, и только под Linux (да, да -std=gnu99 и accept4, dup3, __attribute__((cleanup(dtor))) и прочие приятности, позволяющие сделать волосы шелковистее на 15.5%) и не понимаю, для чего вообще нужен C++? То, что на сишке делается красиво и элегантно, в крестах напоминает соитие парализованных дцпшников (к сожалению, утерял картинку, но именно этот образ всплывает в голове, когда вижу очередную порцию крестолапши).

Давайте посмотрим на типичного C++ разработчика: он использует STL, boost, многие любят Qt (не только для GUI), якобы чтобы «писать кроссплатформенный код». В итоге болезный не знает током ни WinAPI, ни POSIX — ничерта. Он абсолютно не разбирается, как работает целевая система, для которой пишет код! Крестокодер просто не осознает, какой лютый ужас кроется за его любимыми iostream-ами, какое лютое говно лежит в boost::filesystem::path, насколько убого-низкоуровневым является boost::asio в 2016 году.

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

Также эти убогие завистливо смотрят на type inference в языках, проектировавшихся не как «C на стероидах», и в ответ начинают лепить template и auto не к месту, от чего код адово пухнет и даже IDE перестает его понимать.

Серьезно, просто прекратите писать на этом языке. В следующий раз, начиная новый проект, выберите java (щютка)/go/swift/rust/c. Прекратите насиловать труп и отравлять зловонием все вокруг!

Перемещено true_admin из talks

Есть: один монитор в ноутбуке, Дебиан, Матэ и четыре воркспейса на десктопе.

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

Qt не видит воркспейсы. Я пробовал и дебажил каждый метод для:

«QApplication::screens()» — всегда один скрин, тут нечего ловить

«QDesktopWidget» — всегда один скрин, isVirtualDesktop() возвращает false, все методы возвращают QRect только про один скрин.

«QWindow» — только про один скрин.

Вчера весь вечер яндексял гуглеца. Я так понял что только у виндузятни такой проблемы нет. А у мака и линя есть, ибо нагуглил я вот такое: https://stackoverflow.com/questions/16775352/keep-a-application-window-always...

1) Если я не прав — у кого есть рабочий кусок кода определить скрины, воркспейсы и вот это все? Можно и ссылочкой на исходники какой-нить кутешной программы.

2) Или если все так плохо (да и просто для интереса) приглашается Zubok, знающий как правильно приготовить иксы. Покажи пожалуйста на примере как узнать на каком воркспейсе расположено окно?

Добрый день.

Прошу о помощи. Некорректно работает приложение Qt 5.6 в двухмониторной конфигурации (в частности, при запуске на первом мониторе главное меню работает нормально, при запуске на втором оно мертвое). Пытаюсь получить и проинтерпретировать информацию о мониторах/экранах. Для этого добавил в приложение следующий код:

class SvuApplication : public QApplication
{
...
public:
...
static QString desktopInfo();
}; ...

QString SvuApplication::desktopInfo()
{
QString l_info("--- Desktop info ---\n");
QDesktopWidget *l_p_dTop = desktop();

l_info += «Screen(s) count: » + QString().setNum(l_p_dTop->screenCount()) + '\n';
l_info += «Primary screen: » + QString().setNum(l_p_dTop->primaryScreen()) + '\n';
l_info += «Is virtual: » + QString(l_p_dTop->isVirtualDesktop() ? «yes» : «no») + '\n';

for(int i=0; i<l_p_dTop->screenCount(); i++)
{
QRect l_avRect = l_p_dTop->availableGeometry(i),
l_screenRect = l_p_dTop->screenGeometry(i);

QString l_avGeometryStr(" available geometry:(%1,%2,%3,%4) common screen geometry:(%5,%6,%7,%8)");

l_info += «Screen:» + QString().setNum(i) + l_avGeometryStr.arg(l_avRect.x()).arg(l_avRect.y()).arg(l_avRect.width()).arg(l_avRect.height()). arg(l_screenRect.x()).arg(l_screenRect.y()).arg(l_screenRect.width()).arg(l_screenRect.height()) + '\n';
}

return l_info;
}

И далее распечатываем возвращаемую этим методом строку. Вот что получаем...

--- Desktop info ---
Screen(s) count: 2
Primary screen: 0
Is virtual: yes
Screen:0 available geometry:(0,0,1920,986) common screen geometry:(0,0,1920,1080)
Screen:1 available geometry:(0,0,0,0) common screen geometry:(1920,0,1920,1080)

Т.е. - десктоп определяется как виртуальный
- но при этом определяются два экрана
- и самое интересное - у второго экрана (именно того, на котором приложение некорректно работает) доступная геометрия экрана определяется как вырожденный прямоугольник (width = height = 0)

Вопрос. Что можно сделать для того, чтобы система видела оба экрана?

Информация о системе:
opsvu@STRIT2:~$ uname -a
Linux STRIT2 4.2.0-23-generic #28astra39 SMP Tue Mar 1 17:41:12
MSK 2016 x86_64 GNU/Linux

opsvu@STRIT2:~$ lsb_release -a
No LSB modules are available.
Distributor ID: AstraLinuxSE
Description: Astra Linux SE 1.5 (Smolensk)
Release: 1.5
Codename: smolensk

Заранее благодарен за помощь. С уважением

Привет, эксперты. Нужно придумать какой-нибудь протокол обмена между клиентом и сервером по сетке (транспорт TCP).

Данные гоняются всякие разные:

• Авторизация клиента на сервере по логину-паролю
• Получение клиентом настроек некоей «системы» с сервера
• Отправка команд клиентом на сервер (сделай то-то, поменяй настройки такого-то компонента «системы»)
• Получение клиентом различных списков с сервера (события, ошибки, отчеты)
• Получение клиентом данных о состоянии компонентов системы (числа, графики)
• Получение клиентом документов с сервера (текст отчетов)

Может что-то еще, о чем я забыл упомянуть.

Протоколы обмена, с которыми сталкивался, обычно были сделаны довольно топорно, в стиле: номер байта где что-то полезное_количество полезного_полезное_какая-нибудь контрольная сумма.

Соответственно, может есть какие-нибудь банальные инструменты и популярные подходы, которыми решаются подобные задачи? Пока смотрю в сторону отправки данных в формате json или xml, слать в виде: пара байт на длину сообщения_тело сообщения (json или xml). Возможно, в будущем этот трафик надо будет шифровать.

RESTinio - это header-only, кросс-платформенный инструмент для встраивания HTTP сервера с удобным express-like маршрутизатором и вебсокетами. Главная задачей RESTinio является упрощение асинхронной обработки запросов. Чтобы, грубо говоря, обработчик спокойно мог потратить 15 секунд на формирование ответа, но это бы не влияло на параллельные запросы.

RESTinio с самого начала создавался так, чтобы его с одной стороны было удобно использовать, а с другой, чтобы он был производительным и масштабируемым. RESTinio с самого начала написан с использованием C++14.

Вот как будет выглядеть простейший http-сервер, который отвечает на все запросы hello-world сообщением:

#include <restinio/all.hpp>

int main()
{
  restinio::run(
    restinio::on_this_thread()
      .port(8080)
      .address("localhost")
      .request_handler([](auto req) {
        return req->create_response().set_body("Hello, World!").done();
      }));

  return 0;
}

В данном примере обработчик запросов предельно прост, но, конечно, RESTinio дает доступ ко всем параметрам запроса, что позволяет делать более сложные обработчики.

Возможности:

• Асинхронная обработка запросов. В случаях, когда данные для ответа на запрос не могут быть получены сразу (или почти сразу), то можно сохранить хэндл запроса для дальнейшей обработки (например, в другом контексте исполнения) и вернуться к этому запросу, когда все данные будут готовы.
• HTTP pipelining. Хорошо работает в связке с асинхронной обработкой запросов.
• Контроль за таймаутами. RESTinio может помочь в обработке “плохих” соединений, например из которых приходит «GET /», а затем они просто висят.
• Построители ответов. Например, если нужно тело chunked-encoding, то в RESTinio есть и такой билдер.
• Express-like маршрутизатор. Нужно создать нетривиальное REST API со множеством маршрутов, в которых к тому же заключены параметры? Просто возьмите RESTinio с express-like маршрутизатором, который создан по мотивам известного js-фрэймворка.
• Поддержка TLS (HTTPS).
• Базовая поддержка websocket. При помощи restinio::websocket::basic::upgrade() можно начать websocket сессию используя соединение, в котором был получен исходный upgrade-запрос.
• Может быть запущен на стороннем asio::io_context. RESTinio отделен от контекста исполнения, что, например, позволяет запустить 2 сервера используя один asio::io_context или встраивать RESTinio в существующее приложение построенное на ASIO и для этого не потребуется отдельный io_context.
• Некоторые настройки для оптимизации. Можно задать дополнительные опции для акцептора и сокета. Если RESTinio работает на пуле, то можно задать чтобы соединения принимались параллельно и/или создание внутренних объектов для работы с соединением создавались отдельно, это позволит быстрее принимать новые соединения.

RESTinio для своей работы использует standalone версию ASIO, а также ряд других хорошо известных open-source библиотек (nodejs/http-parser и fmtlib), а также catch2 для тестов.

RESTinio-0.4 можно рассматривать как стабильную бета версию.

Репозиторий проекта: https://bitbucket.org/sobjectizerteam/restinio-0.4

Документация: https://stiffstream.com/en/docs/restinio/0.4

Взгляд со стороны, пожелания, предложения и конструктивная критика приветствуются!

Это реинкарнация проекта lorify - скрипт+расширение, реализующее функционал схожий с тем, что добавляет куклоскрипт для имиджборд.

Расширение умеет:

• Получать сообщения от сервера через WebSocket и обновлять контент на странице (новые комментарии, уведомления, правки)
  
• Индикацию на фавиконе вкладки о количестве новых комментариев (очищается даблкликом в любом месте страницы);
  Цвета информируют о состоянии соединения с сервером (зеленый - ок, желтый - отсоединился, красный - сбой)
  
• Системные оповещения о уведомлениях пользователя (для юзерскрипта требуется «разрешить сайту www.linux.org.ru показывать уведомления»)
  
• Динамическая навигация по страничкам темы (по умолчанию подгружается только текущая открытая и последняя, в настройках можно задать количество подгружаемых заранее)
  
• Само собой показ превью постов и ссылки указывающие на комментарии с ответами
  
• Кнопки разметки и хоткеи (гайд по использованию)
  
• Просмотр, масштабирование и поворачивание картинок, как для встроенных превью в топике так и доступных в тексте комментариев по прямым ссылкам (если url картинки имеет непрямой вид к нему можно добавить хэштег с названием и расширением картинки imghost.orc/24dfuh5d1#скриншот.png)
  
• Цитирование с форматированием, как всего комментария так и выделенного в нем текста

Доступны следующие варианты установки

• Юзерскрипт(тестировался с Violentmonkey)
  
• Аддон для Firefox
  
• Chrome (платный, нужно $5)
  • можно так же установить вручную включив на странице chrome://extensions режим разработчика и выбрав папку с исходниками расширения в качестве распакованного

WebExtension имеет некоторое преимущество перед юзерскриптом. В частности при переходе по ссылкам на другие темы форума, ищет уже открытую во вкладках, а так же умеет проверять уведомления в фоне.

>>> Страница проекта на GitHub

1. В каком формате сохранять? Тут у нас много вариантов. Хотел бы услышать ваши варианты, в каком лучше и чем? Тут я немного потерялся:

1.1. xml? Ну, неплохо, но пилить валидацию на момент загрузки файла.
1.2. json? Тоже хуман реадабле, но опять пилить валидацию на момент загрузки файла.
1.3. QSettings? toByteArray()? Уже глазками не почитать, но зато валидация только один раз (заполнение моделек данными).
1.4. Бинарщина? Мутотня с байтордер, да и может еще чем открыть захочу.
1.5. Я не в курсе и есть другой вариант?

2. Есть связанные и вложенные Model/View и тут бы не создавать лишних прослоек, в частности, используя xml/json получается цепочка: файл-данные-модели, а используя нечитаемые форматы будет цепочка: файл-модели. Понятно, что, модель что-то валидирует при её заполнении данными.

Вобщем вопрос такой комплексный — это вообще нормально валидировать сначала на этапе чтения формата, а затем второй раз при заполнении моделей? Если ответ ДА, то я со спокойной душой запилю на json или xml, но если есть иные менее накладные по кол-ву строк кода варианты — я бы с удовольствием их выслушал. Ну и просто приглашаю подискутировать на этот счет.

Использую Qt5.5.1 и есть задача печатать отображаемый на экране элемент. Вот тут есть небольшая проблема: когда вызываем grabToImage на элемент из qml пишет «Item::grabToImage: item's window is not visible». Что пишет понятно, нет явного создания элемента Window, поэтому и не может. Есть корявый вариант по сигналу из qml в c++ вызывать grab на весь QQuickWidget, потом его резать по координатам. Генерить рисунок отдельно вариант ещё хуже. Может кто-нибудь сталкивался с такими делами и более адекватное решение?

Всем привет,

Cобственно задача: слинковаться с GStreamer на Windows. Имеется проект, использующий GStreamer в Linux, где линковка осуществляась через:

CONFIG += link_pkgconfig
PKGCONFIG += \
    gstreamer-1.0 \
    gstreamer-base-1.0 \
    gstreamer-app-1.0 \
    gstreamer-rtsp-1.0 \
    gstreamer-rtp-1.0 \
    gstreamer-net-1.0

Скачал Gstreamer SDK для Windows, и вижу, что там есть *.pc файлы и возникла идея также использовать pkg-config и в Windows.

По-быстрому нагуглил, что можно скачать lite сборку pkg-config для Windows.

Но не понятен момент, будет ли вообще qmake «цеплять» его, даже если прописать путь к екзешечке в переменной окружения PKG_CONFIG_PATH (и достаточно ли только ее? т.к. нужно же еще и прописывать пути к самим *.pc файлам)...

Был у кого такой опыт?

Есть очень жирный проект на С++ который открыт в Qt Creator в котором включен «Clang Code Model». Проблема состоит в том, что временами процесс clangbackend уходит в себя и начинает неистово жрать время CPU. В результате чего вся система стает раком.

Понятно, что clangbackend так себя ведет не от хорошего кода (в проекте). Однако у меня вопрос: как (на уровне системы?) ограничить время CPU уделяемое процессу clangbackend (и, возможно, qtcreator)?

Багрепорт: https://bugreports.qt.io/browse/QTCREATORBUG-11640

добрый день!

друзья!

этот вопрос задавался миллионы раз — но всегда появляется кто-то кто начинает давать *практические* советы как это исправить. пожалуйста, друзья, давайте на этот раз не будем тут писать практические советы (ими заполнен четь более чем весь интернет!).

вопрос: почему во время копирования больших файлов на медленный USB-накопитель (даже из не основного диска) — вся система начинает переодически подзависать включая курсор мыши?

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

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

сможете помочь? заранее спасибо!

Здравствуйте!

Вводная: У меня ноутбук с Nvidia Optimus технологией. Дистрибутив Manjaro Linux. Имеется 2 видеокарты Intel Integrated Graphics и Nvidia GeForce 820M. Для разделения карт использую Bumblebee.

Проблема: Bumblebee не работает с Vulkan API. Фич реквест. Vulkan сообщает мне что у меня нет устройств поддерживающих данный API. Для работы необходим Vulkan.

Вопросы: Есть решение - снести к чёрту Bumblebee и сделать Nvidia видеокарту как основную. Но тогда будет Vulkan видеть одну карту или две? Какие есть соображения по этому поводу?