Asignación de memoria glib VS std * alloc y libre

Tiendo a usar funciones std * alloc/free para asignar/liberar memoria dinámica en mis programas C. Me pregunto si hay buenas razones para usar el GLIB Memory Allocation functions en lugar de los estándar.Asignación de memoria glib VS std * alloc y libre

Agradecería que la comunidad pudiera señalar situaciones en las que cualquiera de estas soluciones sea ganadora/laxa. También me interesan los problemas de rendimiento que podría afectar en caso de que utilice uno u otro.

Gracias!

Editado para plataformas estatales

Estos programas normalmente se ejecutan en todo tipo de distribuciones de Linux/Unix, normalmente de 64 bits de Archs compilan utilizando gcc 4.2.

Fuente

2010-10-28 Manuel Salvadores

En mi opinión, la diferencia más valiosa entre las funciones de GLib y las de la biblioteca estándar es que las funciones de GLib abortan el programa si falla la asignación. No más control para ver si el valor de retorno de malloc() es NULL! Aparte de eso, no hay ninguna diferencia en la estrategia de asignación: g_malloc() llama al malloc() internamente, aunque como una de las otras respuestas aquí indica, es posible cambiar eso.

Otra diferencia es que las funciones de GLib le permiten tener una (rudimentaria) comprobación de fugas de memoria usando g_mem_profile().

GLib también tiene un slice allocator, que es más eficiente si está asignando muchos trozos de memoria de igual tamaño. Esto no utiliza el sistema malloc() y free(), pero de nuevo, es posible cambiarlo para fines de depuración.

Fuente

2010-10-28 12:09:29 ptomato

En Linux, la asignación nunca falla de todos modos. (Con la configuración predeterminada del kernel). Por lo tanto, aunque siempre controlo el valor de retorno de malloc, me sentiría sucio de lo contrario, esa ruta de código nunca se usa de todos modos. –

Dejé de revisar los valores de devolución de malloc hace mucho tiempo. ¿Qué vas a hacer si te has quedado sin memoria? Lo más probable es que ni siquiera puedas escribir un mensaje a stderr. Parece apropiado abortar el programa que ocurrirá de todos modos tan pronto como se quite la referencia del puntero nulo. – JeremyP

@JeremyP, ¡exactamente!Es por eso que preferiría abortar el programa. Puedo imaginar un caso de uso para probar si hay memoria suficiente para asignar algo, pero para esos casos siempre hay 'g_try_malloc()'. – ptomato

depende de la arquitectura subyacente. Bajo SCO Unix f.e. el malloc sigue la estrategia de "mejor ajuste", que está optimizada para la memoria pero que delimita la velocidad.

Así que si su programa depende de una suposición especial en diferentes sistemas/plataformas, siempre es bueno tener el control de la estrategia malloc.

Fuente

2010-10-28 09:30:20

Mis programas siempre se ejecutan en plataformas Linux/Unix y supongo que las implementaciones std glibc malloc en todos estos sistemas deben seguir la misma estrategia. ¿Estoy en lo cierto? (pregunta editada a la arquitectura del estado). Gracias por tu respuesta. –

@msalvadores, a la derecha. Casi TODAS las distribuciones de Linux usan glibc (no confundir con GLIB) malloc. Aquellos que probablemente nunca habrán oído hablar de ellos. –

Si por algún motivo desea controlar la estrategia de asignación subyacente usted mismo, puede usar g_mem_set_vtable() para usar sus propias funciones en lugar de malloc()/free().

Esto es posible con malloc/free también a través de opciones de enlace mágico, pero GLIB expone una API explícita para eso, así como la posibilidad de agregar su propia asignación y registro libre con un mem-profiler-table.

Fuente

2010-10-28 12:00:30

Es bueno tener en cuenta un perfilador incorporado. Gracias. (+1) –

Asignación de memoria glib VS std * alloc y libre

Respuesta

Cuestiones relacionadas