Последние сообщения

Здравствуйте, господа форумчане.
Следующий вопрос относится больше к QNX6.6, но буду рад и ответам относительно QNX6.5.
Перейду к самому вопросу.

Как настроить на QNX6 несколько мониторов?
При подсоединении дополнительного монитора, изображение отображается только на первом.
Хочу увидеть одно и тоже отображение на двух мониторах.
В QNX6.6 данные настройки должны производится в файле /usr/lib/graphics/intel-drm/graphics.conf
Но что-то мои мучения над этим файлом завершились неудачей.

Так что, если кто-то уже ранее добивался успехов в решении данной задачки, буду рад услышать
дельных советов.

сделать обёртку типа my_shutdown() которую собить С

При таком же вызове во время обработки сообщения,

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

Будете смеяться, но у меня и system() проблемы.
Посмотрите мое соседнее сообщение.

Я вдруг понял - Вам не нужны объяснения). Странно правда, что Вы исренне удивляетесь при этом замечаниям сторонних людей)

Да нет, нужны. Просто я их так же анализирую, оцениваю и сравниваю в разных ситуациях. Вот, скажем, сейчас я применил RAII-подход, который вы советовали, для работы с базой данных (класс CRecordset из MFC). Этот класс действительно удобно так обернуть - экономия кучи проверок при подключении к записи базы данных. Но просто так я эти замечания не использую. Почему? Потому что за десятилетия у меня выработалась своя база приёмов и подходов и чтобы её менять нужно очень тщательно разобраться с плюсами и минусами. А следовать слепо приёмам любого автора - это настоящий фанатизм. Чего смешного на том же хабре в этих замечаниях? То, что если разбирается код того же Кармака, то находятся 1001 объяснение того, почему он сделал именно так, причём, от тех же людей, что только что ругали то же самое у других.  При этом на каждого критикующего автора найдётся такой же с противоположным мнением. Вот именно поэтому слепо следовать советам тоже не дело. А вот собирать их - отличная идея.

О! Эта великая экономия на спичках! Вот они преимущества макросов ))

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

Но этот вопрос сродни вопросу....

Я вдруг понял - Вам не нужны объяснения). Странно правда, что Вы исренне удивляетесь при этом замечаниям сторонних людей)

стоит всё же посмотреть IDA что конкретно сделает компилятор и на что будет похож такой код в сравнении с обычным макросом.

О! Эта великая экономия на спичках! Вот они преимущества макросов ))

А вы вызовите shutdown now через system.

Да я обычно на Си и работаю.
К сожалению, не в этом проекте.

Можно переименовать поле, например, в class1.
Но не хочется править системные h-файлы.

Меня смущает, что разработчики так неаккуратно выбрали идентификатор.

как вариант - сделайте отдельный C-шный файл, в котором будет включаться этот заголовочный файл и в котором будет Ваша функция, которая вызывает shutdown_system().

Почему метод написан так, что сам код не объясняет решение/подход?

Но этот вопрос сродни вопросу, как имея формулу расчета, понять, как она была выведена? За каждой функцией лежит некий алгоритм. Вот в приведённой функции, например, даже прочитав описание идеи (я эту идею взял из книжки Хонича 1996 года “Как самому написать трёхмерную игру”, описывающую DooM изнутри) не сразу понимаешь, как это работает – придётся посидеть с карандашом и понять идею изменения столбцов экрана при проецировании сегмента на экран.

начиная от того что нет нужды разделять объявления локальных переменных и их инициализацию, 

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

до того - что циклы с отрисовкой - явные кандидаты на сервис-методы

Да ну, зачем ещё ради 10 строчек отдельную функцию плодить…

Читаемость кода - в приоритете даже над его производительностью!

Это верно. Однако, тут тоже на всех не угодишь.

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

Это непривычный для меня вариант. Может быть, потом понравится.

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

В случае с классом - да, все эти методы будут inline (если я их не вынесу в cpp-файл). В других случаях с заданным явно inline - как повезёт. В целом, да, использование класса снимет эту проблему. Хотя, возможно, стоит всё же посмотреть IDA что конкретно сделает компилятор и на что будет похож такой код в сравнении с обычным макросом.

Да я обычно на Си и работаю.
К сожалению, не в этом проекте.

Можно переименовать поле, например, в class1.
Но не хочется править системные h-файлы.

Меня смущает, что разработчики так неаккуратно выбрали идентификатор.