_ Расширить против нового против GNU - PullRequest
8 голосов
/ 06 декабря 2010

Недавно у меня появился новый друг.Его зовут _expand , и у нас было несколько приятных разговоров, и я даже встречался с ним несколько раз.Но когда я начал расспрашивать, никто никогда не слышал о моем расширении.Я стал подозрительным.Я позвонил нескольким совершенно не метафорическим друзьям в Microsoft и нескольким друзьям в других сферах бизнеса.Ничего такого.Никто никогда не использовал это.Я копался в различных поисковых системах и исходных деревьях.Ничего, кроме краткого упоминания здесь и там.Конечно, мне недостаточно информации о производительности и совместимости, чтобы ввести _expand в производственный код или, что более важно, в общие библиотеки.

Хуже того, нет эквивалентной функции, которую я могу найти ни в одной из библиотек gnu, так что все, что я взломаю с моим новым другом, не будет переносимым.Это позор, потому что это действительно захватывающая и захватывающая способность.Конечно, я мог бы углубиться в realloc и разобрать, как он функционирует, но проблема в том, что большая часть реализации сильно зависит от * nixes.Так что мне нужно будет указывать версию кода за версией, чтобы попытаться получить переносимый _expand.Тем не менее, кажется смешным, что ничего подобного не существует в glib или расширенных библиотеках gnu.

  1. Есть ли подобная функция, о которой я должен знать для взлома linux? Чаще всего ответил
  2. Есть ли стандартный хук, на котором я мог бы создать аналогичную функцию? Ответил
  3. Кто-нибудь знает, какую производительность предлагает _expand?
  4. Как он взаимодействует с объектами, расположенными на LFH?

Чтобы прояснить свои интересы, я пытаюсь создать односвязный аккумулятор, который расширяется в попытке минимизировать фрагментациювыделяя многоэлементные блоки вдоль линий традиционной реализации deque.Ограничивая варианты использования для добавления и удаления элементов, я надеюсь оптимизировать время удаления для всей структуры, а также вставку и индексирование элементов.В результате «громкий сбой» _expand позволяет мне разумно продумать структуру о том, когда и может ли она изменить размер на месте, и что это означает о том, где она может хранить данные.

1 Ответ

3 голосов
/ 06 декабря 2010

То, что C ++ обходится с new и delete без всякого эквивалента realloc, показывает, как мало внимания уделяется этим вещам.Не удивительно, что _expand в значительной степени игнорируется, когда он даже не всегда доступен на уровне ОС.Если вы хотите свернуть свой собственный, есть много прецедентов для пользовательских версий malloc, и быстрый просмотр в /usr/include/malloc.h на моем Linux-боксе показывает зацепки для этого ...

/* 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));

Не похоже, что вы сможете перехватить существующую реализацию realloc в данном конкретном моменте принятия решения или легко получить представление о том, будет ли она изменяться на месте, поэтому вам, возможно, придется переопределить все (или адаптироватьлюбая из множества существующих реализаций кучи).

...