C: pointeurs, destructions
Répondre à la discussion
Affichage des résultats 1 à 5 sur 5

C: pointeurs, destructions



  1. #1
    inviteead871d5

    Lightbulb C: pointeurs, destructions


    ------

    Bonjour à tous,
    j'ai une question simple:
    je dispose d'une structure qui comporte des pointeurs de différents types. Dans mon prog principal, j'ai des pointeurs qui pointent sur la structure que j'initialise par un malloc. lorsque je détruis le pointeur sur ma strucutre (free) est-ce que je détruis les pointeurs qui sont à l'interieur de la structure?

    A+

    -----

  2. #2
    invite74a6a825

    Re : C: pointeurs, destructions

    Bonjour

    Non si ces pointeurs pointent sur une mémoire alloué par un malloc
    c'est pour ça qu'en c++ les classes on souvent une méthode appelé automatiquement par le système lorsqu'un de leur objet est détruit par un free

  3. #3
    invite1fb4554e

    Re : C: pointeurs, destructions

    En général, en C, lorsque l'on a des pointeurs dans une structure, le plus simple est de se créer une fonction qui va se charger de tout désallouer, et l'appeler quand on veut libérer.

  4. #4
    inviteead871d5

    Re : C: pointeurs, destructions

    merci pour les réponses,
    en fait j'utilise la lib GTK+ (2.0 je crois), vous connaissez?
    de toute façon je pense que c'est pareil

  5. A voir en vidéo sur Futura
  6. #5
    invite4ad25ccf

    Re : C: pointeurs, destructions

    Pour la GLib, c'est la même chose, tu dois tout te farcir à la main niveau désallocation.

    C'est pour ca qu'en général, j'aime bien créer mes propres fonctions malloc/free pour faire une désallocation plus sécurisée, au pris d'une légère baisse de performances (donc a eviter si l'on fait énormément de malloc / free).

    De même, je redéfinit free et malloc pour faire mes propres traces et stats sur l'utilisation mémoire (savoir exactement qui l'a allouée, à quelle ligne, etc...) ce qui peut être utile quand on utilise la GLib, celle-ci ayant recours à des méthodes de gestion de mémoire qui font gueuler Valgrind et Memgrind

    Ex de code tout bête ne libérant pas 3 pointeurs selon memgrind :
    Code:
    int main(void)
    {
        GNode *node = g_node_new((gpointer)NULL);
        g_node_destroy(node);
        return 0;
    }
    Voici la sortie produite :
    Code:
    G_SLICE=always-malloc valgrind -v --leak-check=full --show-reachable=yes --leak-resolution=high --num-callers=40 ./a.out
    
    ==5467== Memcheck, a memory error detector.
    ==5467== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
    ==5467== Using LibVEX rev 1732, a library for dynamic binary translation.
    ==5467== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
    ==5467== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
    ==5467== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
    ==5467==
    --5467-- Command line
    --5467--    ./a.out
    --5467-- Startup, with flags:
    --5467--    -v
    --5467--    --leak-check=full
    --5467--    --show-reachable=yes
    --5467--    --leak-resolution=high
    --5467--    --num-callers=40
    --5467-- Contents of /proc/version:
    --5467--   Linux version 2.6.25-gentoo-r7 (root@gritche) (gcc version 4.1.2 (Gentoo 4.1.2 p1.1)) #4 SMP Sat Aug 9 20:45:02 CEST 2008
    --5467-- Arch and hwcaps: AMD64, amd64-sse2
    --5467-- Page sizes: currently 4096, max supported 4096
    --5467-- Valgrind library directory: /usr/lib64/valgrind
    --5467-- Reading syms from /home/towl/libs/a.out (0x400000)
    --5467-- Reading syms from /lib64/ld-2.6.1.so (0x4000000)
    --5467--    object doesn't have a symbol table
    --5467-- Reading syms from /usr/lib64/valgrind/amd64-linux/memcheck (0x38000000)
    --5467--    object doesn't have a symbol table
    --5467--    object doesn't have a dynamic symbol table
    --5467-- Reading suppressions file: /usr/lib64/valgrind/default.supp
    --5467-- Reading syms from /usr/lib64/valgrind/amd64-linux/vgpreload_core.so (0x4A1C000)
    --5467--    object doesn't have a symbol table
    --5467-- Reading syms from /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so (0x4C1E000)
    --5467--    object doesn't have a symbol table
    --5467-- Reading syms from /usr/lib64/libglib-2.0.so.0.1600.3 (0x4E26000)
    --5467--    object doesn't have a symbol table
    --5467-- Reading syms from /lib64/libc-2.6.1.so (0x5103000)
    --5467--    object doesn't have a symbol table
    --5467-- REDIR: 0x5176ED0 (rindex) redirected to 0x4C21F60 (rindex)
    --5467-- REDIR: 0x5176AC0 (strlen) redirected to 0x4C22110 (strlen)
    --5467-- REDIR: 0x5176D40 (strncmp) redirected to 0x4C22170 (strncmp)
    --5467-- REDIR: 0x5176E30 (strncpy) redirected to 0x4C22710 (strncpy)
    --5467-- REDIR: 0x5172F50 (calloc) redirected to 0x4C202F0 (calloc)
    --5467-- REDIR: 0xFFFFFFFFFF600000 (???) redirected to 0x38027723 (???)
    --5467-- REDIR: 0x51732C0 (malloc) redirected to 0x4C211E0 (malloc)
    --5467-- REDIR: 0x5177DD0 (memset) redirected to 0x4C223C0 (memset)
    --5467-- REDIR: 0x5171720 (free) redirected to 0x4C20D60 (free)
    ==5467==
    ==5467== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
    --5467--
    --5467-- supp:    4 dl-hack3
    ==5467== malloc/free: in use at exit: 1,260 bytes in 3 blocks.
    ==5467== malloc/free: 4 allocs, 1 frees, 1,300 bytes allocated.
    ==5467==
    ==5467== searching for pointers to 3 not-freed blocks.
    ==5467== checked 76,064 bytes.
    ==5467==
    ==5467== 252 bytes in 1 blocks are still reachable in loss record 1 of 3
    ==5467==    at 0x4C2035C: calloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
    ==5467==    by 0x4E64BB2: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.1600.3)
    ==5467==    by 0x4E77544: (within /usr/lib64/libglib-2.0.so.0.1600.3)
    ==5467==    by 0x4E78574: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.1600.3)
    ==5467==    by 0x4E78CB5: g_slice_alloc0 (in /usr/lib64/libglib-2.0.so.0.1600.3)
    ==5467==    by 0x4E67F7D: g_node_new (in /usr/lib64/libglib-2.0.so.0.1600.3)
    ==5467==    by 0x400BC6: main (memory_management.c:165)
    ==5467==
    ==5467==
    ==5467== 504 bytes in 1 blocks are still reachable in loss record 2 of 3
    ==5467==    at 0x4C2035C: calloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
    ==5467==    by 0x4E64BB2: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.1600.3)
    ==5467==    by 0x4E7758C: (within /usr/lib64/libglib-2.0.so.0.1600.3)
    ==5467==    by 0x4E78574: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.1600.3)
    ==5467==    by 0x4E78CB5: g_slice_alloc0 (in /usr/lib64/libglib-2.0.so.0.1600.3)
    ==5467==    by 0x4E67F7D: g_node_new (in /usr/lib64/libglib-2.0.so.0.1600.3)
    ==5467==    by 0x400BC6: main (memory_management.c:165)
    ==5467==
    ==5467==
    ==5467== 504 bytes in 1 blocks are still reachable in loss record 3 of 3
    ==5467==    at 0x4C2035C: calloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
    ==5467==    by 0x4E64BB2: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.1600.3)
    ==5467==    by 0x4E77525: (within /usr/lib64/libglib-2.0.so.0.1600.3)
    ==5467==    by 0x4E78574: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.1600.3)
    ==5467==    by 0x4E78CB5: g_slice_alloc0 (in /usr/lib64/libglib-2.0.so.0.1600.3)
    ==5467==    by 0x4E67F7D: g_node_new (in /usr/lib64/libglib-2.0.so.0.1600.3)
    ==5467==    by 0x400BC6: main (memory_management.c:165)
    ==5467==
    ==5467== LEAK SUMMARY:
    ==5467==    definitely lost: 0 bytes in 0 blocks.
    ==5467==      possibly lost: 0 bytes in 0 blocks.
    ==5467==    still reachable: 1,260 bytes in 3 blocks.
    ==5467==         suppressed: 0 bytes in 0 blocks.
    --5467--  memcheck: sanity checks: 0 cheap, 1 expensive
    --5467--  memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
    --5467--  memcheck: auxmaps: 0 searches, 0 comparisons
    --5467--  memcheck: SMs: n_issued      = 14 (224k, 0M)
    --5467--  memcheck: SMs: n_deissued    = 0 (0k, 0M)
    --5467--  memcheck: SMs: max_noaccess  = 524287 (8388592k, 8191M)
    --5467--  memcheck: SMs: max_undefined = 0 (0k, 0M)
    --5467--  memcheck: SMs: max_defined   = 162 (2592k, 2M)
    --5467--  memcheck: SMs: max_non_DSM   = 14 (224k, 0M)
    --5467--  memcheck: max sec V bit nodes:    0 (0k, 0M)
    --5467--  memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)
    --5467--  memcheck: max shadow mem size:   4368k, 4M
    --5467-- translate:            fast SP updates identified: 1,109 ( 86.3%)
    --5467-- translate:   generic_known SP updates identified: 113 (  8.8%)
    --5467-- translate: generic_unknown SP updates identified: 62 (  4.8%)
    --5467--     tt/tc: 3,279 tt lookups requiring 3,300 probes
    --5467--     tt/tc: 3,279 fast-cache updates, 2 flushes
    --5467--  transtab: new        1,631 (36,593 -> 649,807; ratio 177:10) [0 scs]
    --5467--  transtab: dumped     0 (0 -> ??)
    --5467--  transtab: discarded  0 (0 -> ??)
    --5467-- scheduler: 29,441 jumps (bb entries).
    --5467-- scheduler: 0/1,707 major/minor sched events.
    --5467--    sanity: 1 cheap, 1 expensive checks.
    --5467--    exectx: 30,011 lists, 9 contexts (avg 0 per list)
    --5467--    exectx: 9 searches, 0 full compares (0 per 1000)
    --5467--    exectx: 0 cmp2, 6 cmp4, 3 cmpAll

Discussions similaires

  1. C : Pointeurs, chaines de caractères et affichage
    Par invitef1d0ad93 dans le forum Logiciel - Software - Open Source
    Réponses: 3
    Dernier message: 14/08/2008, 10h24
Dans la rubrique Tech de Futura, découvrez nos comparatifs produits sur l'informatique et les technologies : imprimantes laser couleur, casques audio, chaises gamer...