Да, проблема с указателями. Скорее всего, вы используете тот, который не инициализирован должным образом, но также возможно, что вы испортили управление памятью из-за двойных освобождений или чего-то подобного.
Чтобы избежать неинициализированных указателей в качестве локальных переменных, попробуйте объявить их как можно позже, желательно (а это не всегда возможно), когда они могут быть инициализированы значимым значением. Убедите себя в том, что они будут иметь ценность, прежде чем они будут использованы, изучив код. Если у вас возникли трудности с этим, инициализируйте их константой нулевого указателя (обычно обозначаемой как NULL
или 0
) и проверьте их.
Чтобы избежать неинициализированных указателей в качестве значений членов, убедитесь, что они правильно инициализированы в конструкторе и правильно обрабатываются в конструкторах копирования и операторах присваивания. Не полагайтесь на init
функцию для управления памятью, хотя вы можете для другой инициализации.
Если вашему классу не нужны конструкторы копирования или операторы присваивания, вы можете объявить их как частные функции-члены и никогда не определять их. Это вызовет ошибку компилятора, если они используются явно или неявно.
По возможности используйте умные указатели. Большим преимуществом здесь является то, что если вы будете придерживаться их и использовать их последовательно, вы можете полностью избежать записи, delete
и ничего не будет дважды удалено.
По возможности используйте строки и классы контейнеров C ++ вместо строк и массивов в стиле C. Рассмотрите возможность использования .at(i)
вместо [i]
, потому что это приведет к принудительной проверке границ. Посмотрите, можно ли настроить ваш компилятор или библиотеку для проверки границ на[i]
, по крайней мере, в режиме отладки. Ошибки сегментации могут быть вызваны переполнением буфера, которое приводит к записи мусора по совершенно исправным указателям.
Выполнение этих действий значительно снизит вероятность ошибок сегментации и других проблем с памятью. Они, несомненно, не смогут исправить все, поэтому вам следует использовать valgrind время от времени, когда у вас нет проблем, и valgrind и gdb, когда они есть.
g
в контекстеCMake
?