Procurando Memory Leaks no Knowledge Tester em C++ com o Memcheck da Valgrind:<\/p>\n\n\n\n
Hoje partilho isto mais para amigos, para mostrar que o C++, apesar de ser super poderoso enquanto linguagem de programa\u00e7\u00e3o, tem algumas dificuldades que j\u00e1 todos conhecem, como a gest\u00e3o manual de mem\u00f3ria.<\/p>\n\n\n\n
E isto porque tenho andado super ocupado, sem tempo para outros projectos, por isso vou dando retoques finais \u00e0 vers\u00e3o nova (com GUI) do meu software de forma\u00e7\u00e3o “Knowledge Tester” (que original o nome!).<\/p>\n\n\n\n
Isto faz com que, mesmo que tentemos usar o menos poss\u00edvel a cria\u00e7\u00e3o de objectos na mem\u00f3ria heap (exemplo: com keywords \u201cnew\u201d), \u00e9 normal ao programarmos r\u00e1pido, termos algumas memory leaks a serem corrigidas.<\/p>\n\n\n\n
Eu n\u00e3o tenho tido tempo para nada hoje em dia, e programo \u00e0 pressa, e por vezes tenho mesmo de criar objectos na mem\u00f3ria heap, e quando isso acontece, no fim, acabo por usar programas como o Memcheck da Valgrind, para varrer o programa e ver onde ocorrem as falhas de mem\u00f3ria.<\/p>\n\n\n\n
Normalmente, deixamos o execut\u00e1ver ter todos os s\u00edmbolos, para que o programa nos ajude a identificar onde (em que ficheiro, linha, c\u00f3digo, etc), ocorre uma determinada leakage de mem\u00f3ria.<\/p>\n\n\n\n
O GDB n\u00e3o basta para isto, esse \u00e9 usado por vezes por alguns para fazer debugging ao programa (eu normalmente nem o uso, trabalho de outra forma), mas o Memcheck da Valgrind, ou como eu lhe chamo: \u201cO Valgrind\u201d, \u00e9 excelente neste sentido.<\/p>\n\n\n\n
Aqui estava eu a ver se existiam memory leaks graves por eu ter feito isto \u00e0 pressa, e corrigi tudo o que aparecia de importante, e o resto deixo para o Futuro.<\/p>\n\n\n\n
Aten\u00e7\u00e3o que h\u00e1 ali coisitas para corrigir hahaha, mas deixo isso para o ano que vem, pois quero estar um ano e meio sem voltar a mexer nisto, e elas n\u00e3o s\u00e3o graves.<\/p>\n\n\n\n
E notem que o possibly lost n\u00e3o \u00e9 s\u00e9rio, deve-se tamb\u00e9m a eu brincar com pointers de tal maneira que o programa n\u00e3o consegue ter certezas sobre se algo foi perdido ou n\u00e3o, mas n\u00e3o escapou ao meu controlo. E relembro que h\u00e1 sempre alguma fragmenta\u00e7\u00e3o n\u00e3o grave de mem\u00f3ria neste caso que \u00e9 aceit\u00e1vel dada a natureza do programa. E j\u00e1 agora, os 69% do CPU quando usado, com 8 cores, corresponde apenas a 8.6% do CPU quando em esfor\u00e7o, num port\u00e1til apenas I5 e com v\u00e1rios anos. \ud83d\ude42<\/p>\n\n\n\n
Pois relembro que programar em C++ ou C, n\u00e3o \u00e9 t\u00e3o f\u00e1cil quanto nas linguagens mais simples como Java, C#, Python, etc, \u00e9 bastante mais complexo, e tudo \u00e9 mais complexo, n\u00e3o apenas a gest\u00e3o da mem\u00f3ria (que nas outras \u00e9 autom\u00e1tica), como a detec\u00e7\u00e3o de erros (que nas outras indicam onde est\u00e1 o erro ao vez de vos darem potenciais milhares de linhas de c\u00f3digo de erro que n\u00e3o dizem nada, por faltar uma simples chaveta), a abstrac\u00e7\u00e3o do c\u00f3digo, o ter de saber como o hardware funciona, o lidar com hardware (low-level), a sintaxe, a complexidade, etc, e neste caso, podemos ver como \u00e9 o processo de busca de memory leaks, coisa que n\u00e3o teriam nunca de se preocupar muito se usarem C# ou Java ou outros.<\/p>\n\n\n\n
Tinha no canto inferior direito o Bubble Bobble, pois tenho adorado jogar a isto nos \u00faltimos tempos (vers\u00e3o PC neste caso), e o meu programa Knowledge Tester, que est\u00e1 mais r\u00e1pido e sem crashes poss\u00edveis.<\/p>\n\n\n\n
Isto tudo com o maravilhoso sistema operativo Linux (Fedora 35 neste caso, que ainda n\u00e3o me dei ao trabalho de fazer upgrade ao mesmo).<\/p>\n\n\n\n
Um dia partilho algo mais, quando tiver tempo. ?<\/p>\n\n\n\n
Hasta!<\/p>\n\n\n\n
2023-06-11.<\/p>\n\n\n\n
Partilhado no mesmo dia no LinkedIn, no mesmo dia, em:<\/p>\n\n\n\n