C headers (mixed C/C++)

[vregess]

Баян)
Тогда уж так:

Код

C++ (Qt)
class Wrapper : public std::reference_wrapper<RGB_Float> {};
 

Хорошее замечание)

Вот, на мой взгляд, самое оптимальное решение для данной задачи:

Это врядли, тк вариант с оберткой тс не особо устраивает. Так что более лучшая обертка получается не самым оптимальным решением:

Получается что структура ну как бы "слишком мала" чтобы ее врапить. Вот с большими структурами это гуд. А так напр нужен массив RGB_Float - и не объявлять же массив Wrapper'ов.

Тут я в принципе согласен.

Конечно написать операторы + и др не вопрос, но как быть с хедером который без плюсов? Сам хедер править не запрещено, но надо учитывать

Что имелось ввиду под "как быть с хедером"? И зачем его править? Делаем header.hpp, в который включаем header.c и вспомогательные функции.
Может и не надо создавать дополнительных классов, а все перенести в статические функции (или сейчас так и сделано)?

[m_ax]

Это врядли, тк вариант с оберткой тс не особо устраивает. Так что более лучшая обертка получается не самым оптимальным решением:

Честно говоря, я уже не припомню, когда нашего ТС, что-либо полностью устраивало, особенно в плане stl  

А так, да..
Вообще, я согласен с подходом Old-а, но на это и писанины уйдёт порядочно..
Но решать, конечно, igors-у..
 

[Igors]

Вот, на мой взгляд, самое оптимальное решение для данной задачи:

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

Код

C++ (Qt)
void DrawBuffer( RGB_Float * buf, int width, int height );
 

Да, размер буфера может быть сотни мегабайт (12 байт на пыксель). Какой здесь нафиг враппер?

У любого костыля будут минусы.
Если делать основательно, то должно быть три слоя: пользовательский, враппер, С-библиотека, с обязательным условием - крайние слои ничего не знают друг про друга.

Ну так показываем (схематично) как это должно выглядеть. Зачем нам костыль, давайте основательно. Только вот дальше слов и охаивания велосипедистов дело почему-то не идет 

[Old]

Ну так показываем (схематично) как это должно выглядеть. Зачем нам костыль, давайте основательно. Только вот дальше слов и охаивания велосипедистов дело почему-то не идет  

Так а что показывать? 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. И не в коем случае не наоборот!

[Igors]

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

Ну "больше входной информации/подробностей" не всегда гарантирует более плодотворное обсуждение   Простой вызов с массивом просто показывает что враппер зднсь не подходит. А вот более живой пример

Код

C++ (Qt)
typedef struct {									
	RGB_Float * mBufferBase;	  // данные буфера (3 float на точку)			
 
// здесь десяток членов - простых типов
	SInt32 mFrame;
         ...								
 
	C_Rect mBufferRect;            // SDK структура - самописный rectangle
	C_Matrix mMatrix;		  // SDK структура - самописная матрица 4х4		
 
// здесь опять десяток простых 
	double mTime;
         ...								
 
} DrawBufferRec, * DrawBufferPtr;
 

Ну и я получаю такой вызов

Код

C++ (Qt)
SInt32 DrawBuffer( DrawBufferPtr theBuffer );   // мой код должен быть в этом вызове API
 

Что посоветуете?

[Old]

Что посоветуете?

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

Код

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, все спрятано в этих трех классах.

[Igors]

Код

C++ (Qt)
// Буфер - сам буфер
class DrawBuffer
{
    ...
    DrawBuffer( DrawBufferPtr );    // Прячем конструктор, который умеет создавать объект из C-структуры
    ...
}
 

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

Прошу показать как будет выглядеть плюсовый DrawBuffer и как он должен конструироваться из исходной С-шной структуры DrawBufferRec.

[Old]

Как вариант, он будет хранить указатель на 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 )
    {
    }
}
 

[Igors]

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

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

- для каждой С структуры создаем С++ класс используя наследование или агрегацию (по вкусу)
- если структура содержит др  С структуры, то в плюсовый класс добавляем методы возвращающие ссылку на ++ класс

Пример

Код

C++ (Qt)
class DrawBuffer_cpp : public DrawBufferRec {	
...								
	RGB_Float_cpp * BufferBase( void )  { return (RGB_Float_cpp *) mBufferBase; }
 	Rect_cpp & BufferRect( void )   { return (Rect_cpp &) mBufferRect; }
	Matrix_cpp & Matrix( void );	     { return (Matrix_cpp &) mMatrix; } 
}

Этот путь самый капитальный (не "костыль"). Так или нет?

[m_ax]

Пример

Код

C++ (Qt)
class DrawBuffer_cpp : public DrawBufferRec {	
...								
	RGB_Float_cpp * BufferBase( void )  { return (RGB_Float_cpp *) mBufferBase; }
 	Rect_cpp & BufferRect( void )   { return (Rect_cpp &) mBufferRect; }
	Matrix_cpp & Matrix( void );	     { return (Matrix_cpp &) mMatrix; } 
}

Этот путь самый капитальный (не "костыль"). Так или нет?

Это тот же костыль.. при таком то публичном наследовании от сишной структуры..

[Bepec]

Сколько бы решений не предлагали, любое решение отличное от Си структуры кто-нибудь да будет называть костылём. С++ - костыль от С. Qt - костыль от C++.

[Igors]

Это тот же костыль.. при таком то публичном наследовании от сишной структуры..

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

Ладно, то к делу не относится. Так в чем же "костыльность" и как "по всем правилам"?   

[m_ax]

Это тот же костыль.. при таком то публичном наследовании от сишной структуры..

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

Ладно, то к делу не относится. Так в чем же "костыльность" и как "по всем правилам"?  

Как правильно уже написал Old.

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

  

[Old]

Из этого неясно как полностью избавиться от обращений к С-структурам.

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

- для каждой С структуры создаем С++ класс используя наследование или агрегацию (по вкусу)

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

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

Пример

Код

C++ (Qt)
class DrawBuffer_cpp : public DrawBufferRec {	
...								
	RGB_Float_cpp * BufferBase( void )  { return (RGB_Float_cpp *) mBufferBase; }
 	Rect_cpp & BufferRect( void )   { return (Rect_cpp &) mBufferRect; }
	Matrix_cpp & Matrix( void );	     { return (Matrix_cpp &) mMatrix; } 
}

[Old]

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

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