LINUX.ORG.RU

Что делать, если поле класса внутри и снаружи отличается?

 , ,


1

2

Не знаю, что и думать

Есть класс

class evolve                                                                    
{
    public:                                                                     
        float global_time;                                                      
}
Кроме этого есть другие поля и методы, конечно. Однако никакие другие поля не завязаны на global_time, а обращаются к этому полю лишь два метода: конструктор и operator(). Вот, как это происходит:
evolve::evolve(...): ..., global_time(0.0)
{
...
}

void evolve::operator()(float d_time)
{
...
global_time += d_time;
}       

Я создаю экземляр класса (назовём его ev), пытаюсь им пользоваться, но в ev.global_time находится какая-то каша: случайные данные, меняющиеся от запуска к запуску. Но не всё так просто: когда я изнутри класса вывожу для отладки global_time, то там правильное значение!

И это именно то самое поле, а не какая-то локальная переменная или иная путинца в именах, потому что

  • если изнутри класса печатать this->global_time, то точно так же всё ок, значение правильное
  • прошерстил весь проект с помощью grep по слову global_time — ничего лишнего нет.

Была гипотеза, что в каком-то месте в global_time записывается НЁХ, но и она не сработала - потому что в this->global_time лежат правильные данные всё время работы программы, в т.ч. и намного позже инициализации. А ev.global_time во внешнем коде выдаёт фигню сразу же после инициализации ev, и далее.

Все оптимизации отключил, толку 0.

Как такую дичь отлаживать вообще? И почему такое может быть, есть предположения?

★★★★★

Ответ на: комментарий от anonymous

В общем выяснилось, что nvcc идёт со своим компилятором, который лежит в

$ ls /usr/lib/nvidia-cuda-toolkit/bin
cicc  crt  g++  gcc  libcuinj64.so  nvcc  nvcc.profile  nvprof

Версия этого g++ равна 4.9

Когда я пишу -ccbin=g++, nvcc сначала смотрит в /usr/lib/nvidia-cuda-toolkit/bin, находит совпадение, и в итоге останавливается на 4.9 версии.

Если я передаю что-то другое, nvcc не находит совпадения в /usr/lib/nvidia-cuda-toolkit/bin, он смотрит дальше, в /usr/bin, и в итоге берёт версию оттуда.

Как всегда, надо было тщательнее читать маны :( Вопрос закрыт.

Crocodoom ★★★★★
() автор топика
Ответ на: Это залёт от Crocodoom
printf("%ld\n", sizeof(foo));
printf("%zd\n", sizeof(foo));
anonymous
()
Ответ на: комментарий от quester

Если сделал все уроки — собери портфель на завтра. Или посуду помой.

anonymous
()
Ответ на: комментарий от anonymous

Это паттерны головного мозга.

это java метастазы в c++

quester ★★
()
Ответ на: комментарий от Crocodoom

Valgrind создаёт модель памяти, библиотек и прочего, а затем запускает программу в ней. Соответственно, он может следить, была ли выделена память, в которую сейчас пишут, была ли она освобождена в конце работы, были ли чтения из неинициализированных участков памяти…

evilface ★★
()
Ответ на: комментарий от quester

на кой ему знать размер объекта который может быть по разному упакован? тред не читал

Суть вообще-то в этом и есть. Странно пытаться исправлять «ошибку», если ты не знаешь, чего автор кода хотел добиться.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

ok, я прочитал топик. но все равно какой смысл знать размер объекта? чем это поможет в этой проблеме? он же не объекты/структуры упакованные/не упакованные на диск пишет

quester ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.