Вот я не понимаю, столько нафлудили, кучу геморроя себе придумали... Что мешает, например, предусмотреть инициализационную функцию в DLL, вызываемую при её загрузке, принимающую значение MemoryManager из приложения и устанавливающее его себе в качестве рабочего? При выгрузке операция обратная. Раз сборка с BPL-ами не подходит как решение. ;)

ИМХО, HeapMM © Владимир Кладов, встроенный в замену системных модулей, прозрачен к использованию в DLL, благодаря функции GetProcessHeap. На практике пока не проверял.

Ищите да обрящете.

> Freeman ©   (15.07.08 05:06) [20]

> Вот я не понимаю, столько нафлудили, кучу геморроя себе
> придумали...

У человека был конкретный вопрос; как могли подробно разъяснили, почему так, как он делал, сделать нельзя (попутно затронув string-и вообще и вскользь про менеджеры памяти). Проще один раз все подробно обсудить, и проблем не возникнет в последующем.


>Что мешает, например, предусмотреть инициализационную
> функцию в DLL, вызываемую при её загрузке, принимающую значение
> MemoryManager из приложения и устанавливающее его себе в
> качестве рабочего? При выгрузке операция обратная. Раз сборка
> с BPL-ами не подходит как решение. ;)
Возвращаясь к тому, что уже сказано: не вижу смысла вообще тащить менеджер памяти из хост-приложения в ДЛЛ. Я уж не говорю о том, что такой подход ограничивает в использовании средств разработки, и получается тот самый геморрой, о котором вы говорите.

Отвязка от "сложных" типов данных решает проблему на корню - не надо задумываться об особенностях конкрентого менеджера, - используйте в хост-приложении и в дочернем модуле любой менеджер памяти по своему желанию, и передавайте любые данные через указатели (PChar, Pointer etc..) или фиксированной длины (Boolean, Word, DWord etc.). Этот способ универсален. Тем более, в случае string'a, никаких манипуляций даже не потребуется, чтобы скопировать данные из переданного PChar'a в локальный string (преобразование идет прозрачно).

ЗЫ. Оказывается, тема еще актуальна...