_Expand versus new versus GNU

Question

Recientemente, hice un nuevo amigo. Su nombre es _expand, y hemos tenido algunas conversaciones agradables, e incluso he salido con él algunas veces. Pero cuando comencé a preguntar, nadie había oído hablar de mi expansión. Comencé a sospechar Llamé a algunos amigos completamente no metafóricos en Microsoft, y algunos amigos en otros lugares del negocio. Nada. Nadie lo había usado nunca. Rodee varios buscadores y fuentes de árboles. Nada excepto una breve mención aquí y allá. Ciertamente, no hay suficiente información sobre el rendimiento y la compatibilidad para que yo pueda introducir _expand en el código de producción o, de forma más pertinente, las bibliotecas genéricas.

Peor aún, no hay una función equivalente que pueda encontrar en ninguna de las bibliotecas gnu, así que cualquier cosa que hackea con mi nuevo amigo no va a ser portátil en lo más mínimo. Lo cual es una pena, porque es realmente una capacidad fascinante y emocionante de tener. Ciertamente, podría profundizar en realloc y separar cómo funciona, pero el problema es que gran parte de la implementación es muy variable en * nixes. Así que tendría que codificar una versión tras otra para intentar obtener un _expand portátil. Aún así, parece ridículo que no exista nada similar en el glib o en las gnu libs expandidas.

1. ¿Existe alguna función similar que deba conocer para el hack de linux? Respondido en su mayoría
2. ¿Hay un gancho estándar en el que pueda construir una función similar? Respondido
3. ¿Alguien sabe qué tipo de rendimiento ofrece _expand?
4. ¿Cómo interactúa con los objetos asignados en el LFH?

Para aclarar mis intereses, estoy tratando de construir un acumulador de enlace único que se expanda en un intento de minimizar la fragmentación mientras se asignan bloques de elementos múltiples a lo largo de las líneas de la implementación tradicional deque. Al restringir los casos de uso para la adición y eliminación de elementos, espero optimizar el tiempo para eliminar para toda la estructura, así como la inserción e indexación de elementos. Como resultado, la "falla fuerte" de _expand me permite hacer que la estructura piense inteligentemente sobre cuándo y si se puede cambiar el tamaño en el lugar, y qué significa eso sobre dónde puede poner datos.

Answer 1

Que C++ se ha salido con new y delete sans cualquier equivalente de realloc muestra la poca atención que reciben estas cosas. No sorprende _expand se ignora en gran medida cuando ni siquiera está disponible de forma constante en el nivel del sistema operativo. Si desea lanzar el suyo propio, existen muchos precedentes para las versiones de malloc definidas por el usuario, y un rápido vistazo a /usr/include/malloc.h en mi cuadro de Linux muestra los ganchos explícitamente para esto ...

/* Called once when malloc is initialized; redefining this variable in 
    the application provides the preferred way to set up the hook 
    pointers. */ 
extern void (*__malloc_initialize_hook) __MALLOC_PMT ((void)); 
/* Hooks for debugging and user-defined versions. */ 
extern void (*__free_hook) __MALLOC_PMT ((__malloc_ptr_t __ptr, 
             __const __malloc_ptr_t)); 
extern __malloc_ptr_t (*__malloc_hook) __MALLOC_PMT ((size_t __size, 
                __const __malloc_ptr_t)); 
extern __malloc_ptr_t (*__realloc_hook) __MALLOC_PMT ((__malloc_ptr_t __ptr, 
                size_t __size, 
                __const __malloc_ptr_t)); 
extern __malloc_ptr_t (*__memalign_hook) __MALLOC_PMT ((size_t __alignment, 
                 size_t __size, 
                 __const __malloc_ptr_t)); 
extern void (*__after_morecore_hook) __MALLOC_PMT ((void)); 

Parece que no podrá interceptar la implementación existente de realloc en ese punto de decisión particular, ni comprender fácilmente si cambiará de tamaño en el lugar, por lo que podría tener que volver a implementar todo (o adaptar cualquiera de los muchos existentes implementaciones de montón).