reinterpret_cast класса в массив

[Igors]

QVector3D богомерзок...

А на чем основывается это мнение ?

[Racheengel]

Ну вот нужно, например, glVertexPointer использовать.
Массив из QVector3D надо сперва преобразовать в массив флотов.
Потому что чего-то типа QVector3DList у нас нету, и никто не гарантирует, что эти вектора будут лежать в памяти последовательно.

[Old]

Ну вот нужно, например, glVertexPointer использовать.
Массив из QVector3D надо сперва преобразовать в массив флотов.
Потому что чего-то типа QVector3DList у нас нету, и никто не гарантирует, что эти вектора будут лежать в памяти последовательно.

QVector3D сейчас это:

Код

C++ (Qt)
struct
{
    float x;
    float y;
    float z;
}
 

со всеми гарантиями, что вектор таких структур будет хранить их последовательно.

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

[Igors]

Ну вот нужно, например, glVertexPointer использовать.
Массив из QVector3D надо сперва преобразовать в массив флотов.
Потому что чего-то типа QVector3DList у нас нету, и никто не гарантирует, что эти вектора будут лежать в памяти последовательно.

glVertexPointer (как и др ф-ции передачи геометрии) имеет stride, который как раз для данных "не идущих подряд". Так что это не проблема

Еще аргументы против QVector3D? Или Вы просто так сказали про "богомерзкость"? 

[Racheengel]

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

Как минимум это уже потенциальная проблема.
К тому же при аллокации вектора будут вызываться конструкторы класса, соответственно деструкторы при деаллокации. Производительность будет страдать.

stride может сам по себе и не проблема, но это еще один дополнительный параметр, который придется принимать во внимание.

[__Heaven__]

Так а конструктор в этом классе ничем не отличается от обычного копирования float, деструктор по умолчанию. Думаю, что все потенциально лишние копирования компилятор соптимизирует.

[Racheengel]

Так а конструктор в этом классе ничем не отличается от обычного копирования float, деструктор по умолчанию. Думаю, что все потенциально лишние копирования компилятор соптимизирует.

Хорошо, если так. Но если вдруг разработчик решит еще пару фич туда запихать?

[Old]

Хорошо, если так. Но если вдруг разработчик решит еще пару фич туда запихать?

А вот тогда, его придется заменить своим, с нужным устройством и поведением.
Но это "тогда", а чем он вам сейчас не нравиться?

[__Heaven__]

Ну тогда

а если завтра поломают кютешный, то пишете свой класс, и меняете только тайпдеф:

Код

C++ (Qt)
typedef MyValidVector3D Vector3D;
 

[Racheengel]

Но это "тогда", а чем он вам сейчас не нравиться?

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

[Igors]

stride может сам по себе и не проблема, но это еще один дополнительный параметр, который придется принимать во внимание.

Воткнуть вместо нуля sizeof - ой как много работы  

К тому же при аллокации вектора будут вызываться конструкторы класса, соответственно деструкторы при деаллокации. Производительность будет страдать.

Совершенно верно

Так а конструктор в этом классе ничем не отличается от обычного копирования float, деструктор по умолчанию. Думаю, что все потенциально лишние копирования компилятор соптимизирует.

Нет, конструктору велено заполнить нулями - он и заполнит

Код

C++ (Qt)
std::vector <QVector3D> vec(n);
<QVector3D> temp[32];  // или так
<QVector3D> v0, v1, v2;  // или даже так
 

Все это будет притормаживать за счет дефаултного конструктора. И на хорошей кратности это быстро становится ощутимым. Тут не UI где на такие вещи можно спокойно забивать. Поэтому грамотная реализация - пустой конструктор по умолчанию.

Ну это еще цветочки. Что еще плохо в QVector3D ?

[Old]

Не люблю неожиданностей и неопределенности.

Вы переживаете, что изменится внутреннее устройство?

Но если идет речь о приложении, где производительность превыше всего - хочется иметь больше контроля над процессом.

Что это значит? Вам не хватает функционала, вы хотели бы, что-бы он был более наворочен? Тогда с производительностью это может быть не совместимо.

Не обижайтесь, но пока это похоже на капризы, основанные на страхе.
Ну и да, я не призываю использовать QVector3D.

[Racheengel]

"Сам по себе" QVector3D не является чем-то ужасно плохим
Просто, скажем так, все зависит от области применения.
Если надо посчитать несколько десятков 3д-векторов в пространстве - то не проблема. Сами юзаем иногда.
Но когда речь о высокопроизводительном приложении с большими объемами данных - то для подобных целей считаю данный класс неуместным.
Раньше приложение у нас использовало массивы из QVector3D. Когда перешли на plain float array - производительность выросла, а расход памяти уменьшился. Плюс стало возможно "напрямую" юзать всякие там sse-интринзики

[Igors]

"Сам по себе" QVector3D не является чем-то ужасно плохим

Является

производительность выросла, а расход памяти уменьшился. Плюс стало возможно "напрямую" юзать всякие там sse-интринзики

производительность - верю. Но расход памяти и, особенно, "sse-интринзики" - ой заливаете 

[Racheengel]

Является

Почему?

производительность - верю. Но расход памяти и, особенно, "sse-интринзики" - ой заливаете 

"вай, мамай клянус!"
А как прикажете применить интринзики к QVector3D