C headers (mixed C/C++)

[Old]

Выложить его не могу, да и что там собственно видеть? typedef struct - вот и все, просто много

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

В смысле вызовов ф-ций SDK - этот подход прекрасный. Но вот со структурами данных..

А что со структурами данных? Часть из них может вообще исчезнуть для конечного пользователя, другая адаптироваться для объектного API.

[Old]

Код

C++ (Qt)
class RGB_Real
{
public:
    RGB_Real( const RGB_Float & ); 
};
 
//  void RaiseContract(RGB_Real &);  // здесь плюсовый класс для расчетоы
..
RaiseContract(c_struct->color);   // а данные в структуре С
..
 

А лучше, что бы данных в C-структурах больше не было.

[Igors]

Код

C++ (Qt)
class RGB_Real
{
public:
    RGB_Real( const RGB_Float & ); 
};
 
//  void RaiseContract(RGB_Real &);  // здесь плюсовый класс для расчетоы
..
RaiseContract(c_struct->color);   // а данные в структуре С
..
 

А так c_struct->color не модифицируется (не говоря уже о том что копирование из одной структуры в др не украшает)

Это нужно что бы определиться какие классы нужны и как они будут взаимодействовать.
..
А что со структурами данных? Часть из них может вообще исчезнуть для конечного пользователя, другая адаптироваться для объектного API.

Если С структура большая - с ней проблем не возникает, прекрасно работает все что предлагалось выше. И унаследоваться хорошо, и хранить член-указатель на исходную С структуру. Неприятности (мелкие но много) с простейшими классами ("цвет", "точка" и.т.п.) потому что в рабочем коде к ним масса обращений

[Old]

А так c_struct->color не модифицируется (не говоря уже о том что копирование из одной структуры в др не украшает)

Вот по этому:

А лучше, что бы данных в C-структурах больше не было.

В пользовательском коде уже не должно быть C-структур, весь пользовательский код должен работать с врапперами.

[vregess]

А что если хранить в обертке указатель/ссылку?

Код

C++ (Qt)
class Wrapper
{
public:
  Wrapper(RGB_Float &data): m_data(data) {}
 
private:
  RGB_Float &m_data;
}
...
 
RaiseContract(Wrapper(c_struct->color));
 

тогда все манипуляции будут отражаться на исходном объекте

[Igors]

Вот по этому:

А лучше, что бы данных в C-структурах больше не было.

В пользовательском коде уже не должно быть C-структур, весь пользовательский код должен работать с врапперами.

Хотелось бы, но пока не вижу как это аккуратно сделать

А что если хранить в обертке указатель/ссылку?

Код

C++ (Qt)
class Wrapper
{
public:
  Wrapper(RGB_Float &data): m_data(data) {}
 
private:
  RGB_Float &m_data;
}
...
 
RaiseContract(Wrapper(c_struct->color));
 

тогда все манипуляции будут отражаться на исходном объекте

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

[m_ax]

А что если хранить в обертке указатель/ссылку?

Код

C++ (Qt)
class Wrapper
{
public:
  Wrapper(RGB_Float &data): m_data(data) {}
 
private:
  RGB_Float &m_data;
}
...
 
RaiseContract(Wrapper(c_struct->color));
 

тогда все манипуляции будут отражаться на исходном объекте

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

Код

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

Но у такого варианта всё равно есть свой минус..

Можно сделать лучше, пожалуй) 

[Igors]

Тогда уж так:

Код

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

Но у такого варианта всё равно есть свой минус..

Ох уж это пьянствование std..  Лучше самописного может на копейку, а здесь так вообще ничем. Зато как затрудняет нормальному человеку понимание текста - не задачей занимаемся, а так, "эрудицию" развиваем.

[m_ax]

Тогда уж так:

Код

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

Но у такого варианта всё равно есть свой минус..

Ох уж это пьянствование std..  Лучше самописного может на копейку, а здесь так вообще ничем. Зато как затрудняет нормальному человеку понимание текста - не задачей занимаемся, а так, "эрудицию" развиваем.

Точно) Зачем использовать готовые стандартные решения, когда всегда приятнее потратить лишнее время для написания своего велосипеда)

[Пантер]

Igors, не соглашусь с тобой. STL вариант сразу дает понять, что хотел программист. А в самописных решенияъ нужно разобраться, чтобы понять.

[Igors]

Точно) Зачем использовать готовые стандартные решения, когда всегда приятнее потратить лишнее время для написания своего велосипеда)

А не уйдет ли вся силенка в запоминание стандартных решений? Это ох как часто бывает.

Однако вернемся к теме. От того что оно стандартное - легче почему-то не стало   Минусы точно такие же как и в варианте ck

[Old]

А не уйдет ли вся силенка в запоминание стандартных решений? Это ох как часто бывает.

Еще чаще бывает полное переписывание чужих велосипедов на стандартные решения, для облегчения дальнейшего сопровождения системы.

Однако вернемся к теме. От того что оно стандартное - легче почему-то не стало   Минусы точно такие же как и в варианте ck

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

[m_ax]

А не уйдет ли вся силенка в запоминание стандартных решений? Это ох как часто бывает.

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

А чердачное хламокопание, с целью написать очередное решение.. хм.. Это не развитие (если вы об этом), а простаивание на месте( 

[m_ax]

Однако вернемся к теме. От того что оно стандартное - легче почему-то не стало  Минусы точно такие же как и в варианте ck

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

Код

C++ (Qt)
template <class T>
class wrapper : public std::reference_wrapper<T>
{
public:
    wrapper(T &x) : std::reference_wrapper<T>(x) {}
 
    wrapper& operator=(const T &x) {
        this->get() = x;
        return *this;
    }
 
    wrapper& operator=(const wrapper<T> &x) {
        this->get() = x.get();
        return *this;
    }
 
// + Ещё какой либо функционал, в зависимости от задачи..
};
 
template <class T>
inline const T operator+(const wrapper<T> &x, const wrapper<T> &y) {
    return x.get() + y.get();
}
 
template <class T>
inline const T operator-(const wrapper<T> &x, const wrapper<T> &y) {
    return x.get() - y.get();
}
 
void print(int x) {
    std::cout << "print int: value = " << x << std::endl;
}
 
template <class T>
void print(wrapper<T> &w) {
    std::cout << "print wrapper: value = " << w << std::endl;
}
 
int main()
{
    int a = 10;
    int b = 20;
    int c = 0;
 
    wrapper<int> wa(a);
    wrapper<int> wb(b);
    wrapper<int> wc(c);
 
    wc = wa + wb;
 
    print(wc);
 
    print(c);
 
    return 0;
}
 

А теперь,  заменяем int на RGB_Float и пишем в отдельном хедере необходимые для него (RGB_Float) операторы (+,- и т.д.)
делаем typedef:

Код

C++ (Qt)
typedef wrapper<RGB_Float> RGB_Real;
 

 
и радуемся жизни)

[twp]

Если используется Qt то можно задействовать QSharedData в купе с QSharedDataPointer (или даже QExplicitlySharedDataPointer, если надо поведение ссылок).