Как стать автором
Обновить
-1
0
Алексей @Tantrido

Старший программист C++/Qt/C#/.Net/Node.js

Отправить сообщение

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

Что за задержка? Не было такого. Не надо ничего «детектить»: там приходит ID, N функции, потом количество байт, что нужно прочитать, потом 2 байта CRC. Чтобы всё корректно работало и не обрывалось, нужно правильно настроить флаги COM порта: долго с этим мучился, пакеты обрывались не доходили, пока случайно не определил какие флаги выставлял сторонний клиент, который работал корректно. Вот пример для Linux-а, если кому надо, обратите внимание на флаг Ignore Break Condition — в нём проблема:

tcgetattr(fserial, &options);		// Получить текущие настройки порта
    cfsetispeed(&options, BaudRate);	// Установить скорость входящего потока
    cfsetospeed(&options, BaudRate);	// Установить скорость исходящего потока
    if(ParityOdd)
        options.c_cflag |= PARENB | PARODD; // Включить проверку четности (неч)
    else if(ParityEven)
        options.c_cflag |= PARENB & ~PARODD;// Включить проверку четности (чет)
    options.c_cflag &= ~CSTOPB;             // 1 стоп бит
    options.c_cflag &= ~CSIZE;
    options.c_cflag |= CS8 | CREAD | CLOCAL; // 8 бит, включить приемник
    if(bCTS)
        options.c_cflag |= CRTSCTS;     // включить аппаратный контроль потока
    else
        options.c_cflag &= ~CRTSCTS;    // отключить аппаратный контроль потока

    // Вместо ниже приведенных установок можно использовать
    // int cfmakeraw(struct termios *termios_p) для настройки необрабатываемого
    // драйвером последовательного порта ввода/вывода

    // Raw Input - ввод не обрабатывается драйвером порта
    options.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
    // Raw Output
    options.c_oflag &= ~OPOST;
    options.c_iflag = IGNBRK;   // Ignore Break Condition (без этого работало
                                // некорректно: CRC/Timeout errors)

    // Настройка таймаутов порта
    options.c_cc[VMIN] = 0;  // Минимальное количество символов
    options.c_cc[VTIME]= Timeout/100; // Таймаут ожидания каждого
                                      // символа *10 сек
    tcsetattr(fserial, TCSANOW, &options); // Записать новые настройки
                                           // (немедленно)
    if(MDebug > 1){
        cout << "Serial port options:" << endl;
        cout << "c_cflag: " << options.c_cflag << endl;
        cout << "c_lflag: " << options.c_lflag << endl;
        cout << "c_iflag: " << options.c_iflag << endl;
        cout << "c_oflag: " << options.c_oflag << endl;
        cout << "c_cc: " << options.c_cc << endl;
        cout << "c_ispeed: " << options.c_ispeed << endl;
        cout << "c_ospeed: " << options.c_ospeed << endl;
    }

Вот именно! Ни когда не понимал, где тут боль?! C++/Qt, Java, C# - и никакой боли. Если был выбор сразу под Линукс писал. У автора "огромное количество вариантов" - это проблема, что странно!

В классе Q_OBJECT, а не везде подряд!

В смысле как? Использую Q_ENUM.

Как по мне менее читабельный, хотя node.js люблю.

>модель Senders/Receivers

Стиль кода становится похожим на node.js.

сделал раз — работает везде».

Неправда, acestream ваш как раз перестал работать: https://forum.snapcraft.io/t/acestreamplayer-mpv-stopped-to-work-glibc-error/23061

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

Ну и почему дальше мысль не развить? Если разработчик C++, почему он не может на JS писать?! Я через неделю на ноде стал писать, когда работодатель знал, что мне вообще без разницы на чём. И прекрасно получилось всё.

Да — нужен, или да — хватит?!

QT пыталось запилить свой REST-сервер, но так и непонятно, чем всё закончилось.

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

полезности и эффективности использования PVS-Studio для контроля качества кода. Хотя мы уже писали про поверку проекта Qt (в 2011, в 2014 и в 2018), очень полезно сделать это вновь. Так, мы на практике демонстрируем простую, но очень важную мысль: статический анализ должен применяться регулярно!

А толку?! Они хоть что-то из этого исправили?!


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

Только не Qt: многие баги годами не исправляют. Вот например с датами: https://bugreports.qt.io/browse/QTBUG-67383 — вообще решили забить на него!

Ну и продолжите статью выводом как правильно сравнивать числа с плавающей точкой в JavaScript, а то какая-то неоконченная получается.

База становится всё лучше и лучше, приятнее и приятнее!!! :) Спасибо!

Люблю такие статьи: лаконично и по делу! :) Спасибо!

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

Совпадение?! Только сегодня на работе про этот шаблон говорили :)

Надо было ещё добавить в C++11 или даже 98. Хорошо, что в Qt всегда было и остаётся гораздо удобнее.

Коротко, ясно, понятно! Спасибо!

1
23 ...

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность