valgrind обнаруживает «все еще достижимую утечку» в пустой программе, скомпилированной с помощью gcc5.1, g++ ./a.cpp,
int main () {}
валгринд говорит, valgrind ./a.out,
==32037== HEAP SUMMARY:
==32037== in use at exit: 72,704 bytes in 1 blocks
==32037== total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
==32037==
==32037== LEAK SUMMARY:
==32037== definitely lost: 0 bytes in 0 blocks
==32037== indirectly lost: 0 bytes in 0 blocks
==32037== possibly lost: 0 bytes in 0 blocks
==32037== still reachable: 72,704 bytes in 1 blocks
==32037== suppressed: 0 bytes in 0 blocks
==32037== Rerun with --leak-check=full to see details of leaked memory
==32037==
==32037== For counts of detected and suppressed errors, rerun with: -v
==32037== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 5)
Для программ на языке C valgrind не сообщает об утечках памяти и выделении памяти. Кроме того, для gcc5.0 и gcc4.9.2 valgrinds не сообщает об утечках памяти и выделении памяти. Тогда я предполагаю, что причиной является новый libstdc++ gcc5.1.
Мой вопрос в том, как уменьшить это огромное выделение памяти, которое может быть в libstdС++. Действительно, время выполнения этой пустой программы на C++, скомпилированной с помощью -O3, больше, чем у пустой программы на C, на несколько миллисекунд (без системного времени).
int main () {}? или у него есть включения и тому подобное? - person Eregrith schedule 22.05.2015int main () {}— это именно содержимое, аg++ ./a.cpp— это команда компиляции, которую я использовал. - person akakatak schedule 22.05.2015int main () {}... вау gcc... вау.... - person Eregrith schedule 22.05.2015gcc -E a.cpp? Как выглядит.o? - person Eregrith schedule 22.05.2015g++ -E a.cppговорит: # 1 test.cpp # 1 ‹встроенный› # 1 ‹command-line› # 1 test.cpp int main() {} Мне кажется, что это обычный .objfile Нет незнакомых символов. Во всяком случае, ссылка, предложенная пользователем 657267, может что-то сказать по существу. - person akakatak schedule 22.05.2015