Я использую ++ библиотеки C, которая предоставляет объект, который, для простоты, более или менее, как это:Отладка большой двойной массив
class ExampleSO {
public double* narray;
};
У меня есть экземпляр ExampleSO
которого narray
о 200. Некоторые другие методы ExampleSO::method()
делает много арифметических функции с этим массивом и присваивает его к различным элементам массива:
ExampleSO::method() {
// a lot of operations
narray[50] = narray[1] * narray[2]/narray[40];
// and so on
Этот код генерируются другой программой, и он использует кучу Определяет для обработки элементов массива, Итак Код выглядит следующим образом:
#define A narray[0]
#define X narray[1]
#define Y narray[2]
// ...
#define Z narray[40]
// ....
#define U narray[50]
// ... more, until narray[199]
ExampleSO::method() {
// a lot of operations
U = X * Y/Z;
// and so on
}
Моя проблема заключается в том, что в конечном итоге некоторые элементы массива являются NaN, и я пытаюсь отлаживать код, чтобы понять, почему. Я уже выяснил некоторые из них, которые в основном вызваны делениями на ноль, другие - экспоненциацией очень маленькими числами (малыми, как между 0 и +/- 0,1).
С моим небольшим знанием магии gdb мне удалось увидеть элементы массива на display *(this->narray) @ 200
, но этот массив очень большой и, следовательно, нечитабельный.
Так что отладка этого фрагмента кода оказалась сложной задачей, потому что #defines
спрятать мне позицию элемента, массив слишком велик и потому, что многие элементы становятся NaN, что я теряюсь.
Мой вопрос: какие идеи/предложения у вас есть, чтобы помочь мне отладить этот код? Возможно, полезна условная точка останова, когда первый элемент массива станет NaN? Как я мог сделать это с такой структурой?
Спасибо!
Я не могу переписать его, потому что код генерируется программой, а не мной. Генератор кода тоже не мой, но я буду принимать любые предложения о том, как легко управлять большим количеством двойных переменных, которые хранятся в массиве, таком как этот пример. +1 для сигнализации, я начну с этого – YuppieNetworking
Ну, это устранило вариант 1, но не 2, 3 или 4. 5, безусловно, поможет вам, в любом случае. – bmargulies
Нашел мою ошибку. Спасибо за ваши идеи. 5 был самым полезным, реализованным в любом случае в будущем. – YuppieNetworking