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

[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

(http://stackoverflow.com/questions/737240/...tion-is-allowed)
так что это новый стандарт, который, однако, ещё не все компиляторы поддерживают. кстати, на стеке создаётся!
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