Заполнение массива Опции

[PunX]

Заполняю двумерный массив x[n][m] и xt[m][n] (xt по идее после заполнения будет являться транспонированной матрицей) слудующим образом:

QSqlQuery qx;
    QString str = "SELECT c.x, c.y "
                  "FROM fe_coord c, \"Z\" z "
                  "WHERE c.fe_number = z.fe_number;";
    if(!qx.exec(str)){
        QMessageBox::warning(0,"warning","error of query!");
    }
    QSqlRecord recx = qx.record();

    int n = qx.size();
    int m = 3;
    int i=1;
    double x[n][m];
    double xt[m][n];
    while(qx.next()){
        double x2 = qx.value(recx.indexOf("x")).toDouble();
        double x3 = qx.value(recx.indexOf("y")).toDouble();

        x[i][1]=1;
        x[i][2]=x2;
        x[i][3]=x3;

        xt[1][i]=1;
        xt[2][i]=x2;
        xt[3][i]=x3;

        i++;
    }

может конечно это и как-то не правильный метод, но всё же если я далее хочу просмотреть что же у меня там лежит в x[1][2] c помощью:

QString xi = QString("%1").arg(x[1][2]);
    QMessageBox::information(0,"t",xi);

и при запуске приложения оно вываливается с ошибкой ("завершился с кодом -1073741819")
не совсем понимаю что не так, подскажите пожалуйста.

[Iron Bug]

ты на си вообще программировал хоть раз в жизни? почему у тебя индексация с единицы? понятное дело, что в массиве размерностью 3 нет элемента с индексом 3.

[wolf.diesel]

Айрон прав.

Эта ошибка классифицируется как Out of Range - За границами выделенной памяти.

Непонятно, правда, почему компилятор выдал такое число, да еше и отрицательное, но суть проблемы, думаю, ясна?
Вся индексация в СИ и СИ++ начинается с 0.

К примеру, если массив объявлен как

int x[500];

То первый элемент будет звучать так:

int c;
c = x[0];

следовательно, последний элемент будет звучать как:

с = x[499];

если написать так:

с = x[500];

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

[Алексей1153]

Первый раз программировать на чём-либо - это не позор, что ж вы так сразу накинулись

Лучше надо было написать, как C/C++ работает с оператором [] доступа к элементу массива, а именно:

выражение
name[N];

эквивалентно следующему
*(name+N);
---------------
выражение
name[N][M];

эквивалентно следующему
*(*(name+N)+M);
---------------

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

Непонятно, правда, почему компилятор выдал такое число, да еше и отрицательное

Неизвестно, что именно "подправлено" неверной записью - ругаться мог любой объект )))

А ещё неожиданностью для меня вот что стало

    int n = 4;
    int m = 3;
    double x[n][m];

то есть, что Qt позволяет использовать в объявлении статического массива не константы. В C/C++ такого нет )
То есть, насколько понимаю, массив создаётся даже не на стеке, а динамически?


Сообщение отредактировал Алексей1153 - 10.7.2010, 17:41

[Litkevich Yuriy]

что Qt позволяет использовать в объявлении статического массива не константы. В C/C++ такого нет )

ну Qt здесь, точно не причём. А вот компилятор GCC, видимо, позволяет

[Алексей1153]

Litkevich Yuriy, ну, я в эти тонкости ещё не вник )) Для меня оно всё Qt ещё пока

[Iron Bug]

А ещё неожиданностью для меня вот что стало

int n = 4;
int m = 3;
double x[n][m];

это странно. я просто не вгляделась в детали. начала копать, нашла вот что:

C99 standard supports variable sized arrays on the stack

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

Сообщение отредактировал Iron Bug - 11.7.2010, 10:08

[Алексей1153]

такое в кроссплатформенности лучше не юзать

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

Кстати, студия тоже хавает, но в таком виде:

const int n = 4;
const int m = 3;
double x[n][m];

а лично для меня const TYPE и TYPE - это одно и то же, ибо

const TYPE t=7;

((TYPE&)t)=3;

или

*((TYPE*)&t)=3;

то есть const - лишь напоминалка компилятору, чтобы тот напомнил программисту о "неправильном" присваивании

Сообщение отредактировал Алексей1153 - 11.7.2010, 10:19

[Iron Bug]

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

Сообщение отредактировал Iron Bug - 11.7.2010, 13:40

[Алексей1153]

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

Ну а что может быть проще:

enum
{
   n = 4,
   m = 3,
};

double x[n][m];

А насчёт участия const в оптимизации - что-то сильно сомневаюсь. Компиляторы сейчас и без const могут тааак заоптимизировать )) То есть они и так увидят, что переменная не меняется в коде

Сообщение отредактировал Алексей1153 - 11.7.2010, 16:08