Писать свои операторы.

Слишком не однозначное значение у "суммы цветов". Складывать компоненты RGB или CMYK?  Что делать при переполнении?
Поэтому, IMHO, "сумму цветов" оставили на совести конечных пользователей, так сказать как они это представляют.

Все приведения (если и будут) только в интерфейсном слое (Matrix).

C++ (Qt)
extern "C"
{
typedef struct matrix matrix_type;
void matrix_rotate_x( matrix_type *m, real a );
void matrix_scale( matrix_type *m, real s );
}
 
class Matrix
{
public:
    void rotate_x( real a );
    void scale( real s );
 
private:
    matrix_type m_matrix;
 
// а лучше 
// class priv;
// priv    *d;
};
 
// ---
 
void Matrix::rotate_x( real a )
{
    matrix_rotate_x( &m_matrix, a );
}
 
void Matrix::scale( real s )
{
    matrix_scale( &m_matrix, s );
}
 

С одной стороны (пользовательский код) виден только интерфейс Matrix, с другой стороны все реализуется через С-функции.

Что такое инженерный расчет и какое отношение он имеет к классам?

Весь пользовательский код будет работать с объектами DrawBuffer_cpp, а про DrawBufferRec будет знать только прослойка.

Я несколько раз писал, что по моему мнению так делать нельзя. Как правило получается не удобная фигня.
Нужно сесть и представить (с точки зрения пользовательского кода), а как бы мне было удобно эффективно это все описать на C++.
Для примера, есть библиотека для работы с БД. Решение в лоб, это описать классы Поле, Запись, Таблица, Соединение и потом из Полей формировать Записи, из Записей Таблицы и т.д. А мне оказалось удобней оставить только две сущности: Запрос и Соединение. В которые, я и спрятал все обращения С-функциям. Весь пользовательский код знает только про эти два класса и пользуется только их интерфейсом. Бэкенд БД легко меняется, хочешь SQLite, MySQL, ...

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

А он по умолчанию открывается как бинарный, если не указывать при открытии QIODevice::Text

"часто не лучший" и "Ну может конечно и нет".  Все от воли Божьей.

А так да, все может быть, но я сильно сомневаюсь в "часто не лучший", у меня противоположная статистика.

А чем же нужно заниматься?

std  и boost это по сути С++, это нужно знать, если хочешь владеть своим инструментом (С++). Вряд ли, кто-то сейчас сможет сделать готовый проект используя только stdlib, а вот с бустом уже можно.
Qt удобная вещь для быстрого ваяния GUI. Как правило, если не делать "очередные многопоточные серверы" (в коих, я уверен, у вас огромный опыт ), то остальные заказчики хотят тыкать мышкой в окошки.
Python удобный скриптовый язык. На нем не обязательно делать большие проекты, он очень сильно может помочь в автоматизации сборки и тестирования своих систем, генерации каких-то данных и т.д.

Мне кажется без этих знаний сейчас рассчитывать особо не на что...

P.S. А еще желательно знать и понимать forth - его я считаю самой красивой идеей/реализацией вообще в программировании за все времена. Еще не плохо знать ассемблер, какой нибудь, не обязательно на нем программировать, но эти знания будут очень полезны. И есть еще много чего, что хорошо бы знать и будет полезно...

Будет одинаково.

Ты посмотри от кого наследуется QTextBrowser...

Как вариант, он будет хранить указатель на C-структуру DrawBuffer

C++ (Qt)
DrawBuffer::DrawBuffer( DrawBufferPtr ptr ) :
    m_drawBuffer( ptr )
{
}
 
DrawBuffer::DrawBuffer( int w, int h ) :
    m_drawBuffer( new DrawBufferRec )
{
    m_drawBuffer->width = w;
    m_drawBuffer->height = h;
}
 

А можно разложить поля С-структуры в поля класса:

C++ (Qt)
class DrawBuffer
{
    PixArray m_bufferBase;    // Предполагается, что конструктор PixArray умеет конструироваться из указателя на буфер RGB_Float
public:
    DrawBuffer( DrawBufferPtr ptr ) :
        m_bufferBase( ptr->mbufferBase )
    {
    }
}
 

Нужно сесть и продумать, а как было бы удобно это использовать в клиентском коде.
Например, решаем использовать три сущности:

C++ (Qt)
// Рендер - может генерировать DrawBuffer
class Renderer
{
public:
    DrawBuffer run( ... );    // В run используется C-API, возвращает же она уже C++ объект.
};
 
// Рисовальщик - умеет его выводить на всякие разности
class Drawer
{
public:
    void draw( const DrawBuffer &buf );
};
 
// Буфер - сам буфер
class DrawBuffer
{
public:
    DrawBuffer( int w, int h );
 
private:
    DrawBuffer( DrawBufferPtr );    // Прячем конструктор, который умеет создавать объект из C-структуры
    friend class Renderer;                  // Даем возможность методу Renderer::run использовать спрятанный конструктор для создания объектов из C-структуры
}
 

Для пользователя нет C-API, все спрятано в этих трех классах.

Так а что показывать? API С-библиотеки не доступно, обсуждаем одну структуру RGB_Float.

Для пользователя она должна быть скрыта за классом RGBReal и все доступные методы должны использовать ее:

C++ (Qt)
void DrawBuffer( const std::vector<RGBReal> &buf, int width, int height );
 

Для хранения буферов можно сделать свой контейнер:

C++ (Qt)
class PixBuffer
{
public:
    RGBReal &at( int x, int y );
    const RGBReal &at( int x, int y ) const;
}
 
void DrawBuffer( const PixBuffer &buf, int width, int height );
 

Здесь нужно садиться и смотреть какие сущности нужны для пользовательского кода и как сделать их удобное взаимодействие, и за этими классами прятать весь C API. И не в коем случае не наоборот!

А у меня твой тестовый пример не падает.