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

[__Heaven__]

Racheengel,

Код

C++ (Qt)
#include <QVector>
#include <QtDebug>
 
struct A{
    A(){
        qDebug() << "Constructed";
        a_ = 0;
    }
    A(const A &other) {
        qDebug() << "Copied";
        a_ = other.a_;
    }
    float a_;
};
 
 
int main()
{
    QVector<A> vec;
    vec.reserve(3);
    vec.append(A());
 
    qDebug() << sizeof(A);
    return 0;
}
 

Constructed
Copied
4

Вроде, ничего лишнего

[Old]

А как прикажете применить интринзики к QVector3D 

В памяти вектор QVector3D это последовательность float: x, y, z, x, y, z, ...
С помощью плохих кастов можно получить float*

[Old]

Вроде, ничего лишнего

Имеется ввиду:

Код

C++ (Qt)
QVector3D vec[ 100 ];
 
// или
 
QVector<QVector3D> vec( 100 );
 

В этих случаях 100 раз будет вызываться дефолтный конструктор QVector3D.

[Racheengel]

В памяти вектор QVector3D это последовательность float: x, y, z, x, y, z, ...
С помощью плохих кастов можно получить float*

Или x,y,z, [gap], x,y,z, [gap]

Кто гарантирует, что на разных платформах не появится никакого чудо-выравнивания, например?

[__Heaven__]

Код

C++ (Qt)
#include <QVector>
#include <QVector3D>
#include <QtDebug>
#include <QTime>
 
 
int main()
{
    QTime time;
    time.start();
    QVector<QVector3D> vec(9999999);
    qDebug() << time.elapsed();
    return 0;
}

30

Насчёт гапов тоже интересуюсь. Только не нашёл ссылок на стандарт. В c99 они возможны. А что насчёт c++11?

[Old]

Кто гарантирует, что на разных платформах не появится никакого чудо-выравнивания, например?

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

Код

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

что для:

Код

C++ (Qt)
float v[ 3 ];
 

[Igors]

Является

Почему?

Здесь заклинивает Qt "идеология", которая на первое место ставит "удобство использования". Это конечно хорошо, но в случае QVector3D это просто идет в ущерб качеству кода. Плохо просто все, начиная с имени класса. QVecоr3D - оказывается "3D" надо понимать как  "трехмерный", а не "3 double ". Напр QVec3f было бы уместнее. Имена методов не лучше, напр

QVector3D::dotProduct
QVector3D::crossProduct

Эти операции настолько ходовые что часто их делают даже операторами. А тут длинные static портянки которые задолбают через неделю работы.

Ладно, не будем придираться к именам, содержательная часть

Код:

QVector3D QVector3D::normalized() const
{
    // Need some extra precision if the length is very small.
    double len = double(xp) * double(xp) +
                 double(yp) * double(yp) +
                 double(zp) * double(zp);
    if (qFuzzyIsNull(len - 1.0f)) {
        return *this;
    } else if (!qFuzzyIsNull(len)) {
        double sqrtLen = sqrt(len);
        return QVector3D(float(double(xp) / sqrtLen),
                         float(double(yp) / sqrtLen),
                         float(double(zp) / sqrtLen));
    } else {
        return QVector3D();
    }
}

Отак от! Оказывается выбор между normalize() и normalize_safe() (нормализация с проверкой) Qt пользователю не нужен. Будем просто сами всегда проверять (удобство использования), а не удается нормировать - вернем нулевой, пусть будет Nan на следующей операции. Перлы с fuzzy  из той же оперы. Как можно было накосячить в том что прекрасно известно десятки лет - хз.

Идиотское setX(Y, Z) - нет слов

distanceToXXX - на мой взгляд, просто оскорбление. Типа "ты ничего в геометрии не рубишь, записать 1 строку тебе тяжело. Не беда - мы вот сделали такой чудесный класс что и без всяких познаний (чисто на букваре) все сделаешь! Кормись, лошок, кормись!". Зачем же так плохо думать о пользователе? 

SSE нет и намека, хотя люди его уже лет 10 имеют. По нынешним временам это просто неприлично. Кстати, именно поэтому не спешите городить свой класс.

Зато да, для человека с этим никогда не работавшего - все прекрасно, просто отлично. Но ведь это надувательство.  Ладно, будем надеяться что таких классов в Qt немного, и на солнце есть пятна

[__Heaven__]

У вас очень тонкая грань между "удобство использования" и "Кормись, лошок"

[Racheengel]

Насчет "одинакового выравнивания везде и всегда", увы, не соглашусь.

http://stackoverflow.com/questions/5397447/struct-padding-in-c

Да и практика иное показывает.

[__Heaven__]

А для float, float, float такие примеры есть?

[Old]

Насчет "одинакового выравнивания везде и всегда", увы, не соглашусь.

http://stackoverflow.com/questions/5397447/struct-padding-in-c

Да и практика иное показывает.

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

[gil9red]

/offtop

"reinterpret_cast класса в массив"
Из-за подобных хитростей программист с++ и может цитирую

...стрелять себе в ногу, стрелять себе в ногу с выдумкой, в другую ногу, одной ногой стрелять в другую ногу...

Продолжайте срач

[Igors]

У вас очень тонкая грань между "удобство использования" и "Кормись, лошок"

А почему Вы думаете она вообще существует?

Отважный разведчик - подлый шпион
Опытный профессионал - продажная сука
и.т.п.

Очень разная эмоциональная окраска - но смысл-то одинаков

Насчет "одинакового выравнивания везде и всегда", увы, не соглашусь.

Ах как мы блещем знанием хабровских статеек! Пусть вопрос не стоит выеденного яйца (всегда можно использовать stride) - но не напрасно же читал!  

[Old]

/offtop

"reinterpret_cast класса в массив"
Из-за подобных хитростей программист с++ и может цитирую

...стрелять себе в ногу, стрелять себе в ногу с выдумкой, в другую ногу, одной ногой стрелять в другую ногу...

Продолжайте срач

Ну на самом деле это действительно очень гадкий хак и я бы им не пользовался.

[__Heaven__]

Old, а что бы вы сделали?