Во-первых, тебе надо добиться, чтобы компиляторы использовали одинаковое выравнивание. Проверить это проще всего, сравнив sizeof (TPerson). В дельфе можно отменить выравнивание, сказав packed record, в C++ для этого кажется соответствующая прагма.

Во-вторых, тебе нужно, чтобы для выделения и освобождения использовался один и тот же менеджер памяти. Это можно сделать несколькими путями, например:

- подключить в DLL дельфовые функции GetMem/FreeMem
- использовать для выделения и освобождения функции Win API
- по завершении работы со структурой передать ее функции "освободить", также расположенной в DLL.

Последний путь - пожалуй, наиболее правильный.

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

White OwlЭто не простая структура.
Хм.

White OwlЛучше положить внутрь структуры массив char'ов.
И начать очередную серию идиотских проблем вида "в нашей системе имя может быть максимум 20 символов"?

ErVПо-моему, лучше тогда будет, если эти структуры будут жить внутри
библиотеки, и создавасться/уничтожаться ей же.
Я назвал этот вариант как предпочтительный.

ErVТ.е. мендежеры памяти будут раздельные.
Но в целом тут вопрос. Имхо, правильный ответ зависит от архитектуры решения в целом. Если это "маленький плагин к большой системе", то пусть он лучше будет замкнутым и самодостаточным. А если система в целом плагинная, лучше опубликовать общее API в том числе менеджера памяти.

White OwlЕсть такое правило для коммуникационных протоколов: все данные для сообщения должны хранится в самом сообщении. Нарушение этого правила приводит к необходимости организовывать общую память для отправителя и получателя, и организовывать систему управления этой общей памятью. В твоем первом сообщении в этом топике ты уже предлагал несколько решений как сделать эту самую разделяемую память.
Извини, но тебя куда-то понесло. Попробую ответить тебе в твоей терминологии: "самим сообщением" в данном случае является указатель на массив структур. И именно адресованный массив хранится в общей памяти итп. Модификация предложенного тобой типа в данном случае никак не влияет на необходимость организации общей памяти и применения названных мной (или других) методов.

Надеюсь, ты не пытаешься намекнуть на желательность передачи массива структур по значению. Это, конечно, решит задачу освобождения памяти, но это единственное достоинство такого решения....

White Owlлибо пересортировать структуру - элементы с фиксированым размером в начало, массивы с изменяем размером в конец и добавить в начало элементы - размер_такого_то_массива.
И мы придем к нарисованному мной куску памяти.

ErVно только тогда придется по нему гулять адресной арифметикой,
что под дельфей будетт не совсем удобно.
Под дельфей это не менее удобно, чем под си, но смысла в этом в данном случае нет. Точнее, он может быть в том случае, если алгоритм формирования массива окажется неудобен для формирования структуры наподобие нарисованного мной куска памяти.

ErVа вместо PChar будет смещение к нужной строке, в байтах,
И получим лишний геморрой на пустом месте. Буфер нам все равно потребуется освобождать, а раз так, эта конструкция по сравнению с моей имеет единственное "достоинство" - усложненный доступ к строкам.

ErVМожно даже просто банально сохранить все строки в конце блока памяти, и использовать PChar вместо смещений.
Странным путем пришли к моей конструкции :) Очень странным путем :))

ErVТогда, возможно, потребуется меньше выкрутасов для освобождения памяти для строк.
Тогда потребуется ноль выкрутасов.

White OwlА вот когда дело касается строк - есть тенденция забывать про это...
И при этом писать на сях? В этом случае можно уже не заботиться о передаче информации между модулями :)

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

White OwlНе на сях, а на дельфях и сях
Ты так говоришь, словно для "супа с грибами и картошкой" поганки отфильтровывать необязательно.

White OwlТе же самые - с одним куском работать проще.
И кто мешает работать с одним куском, не влезая в описанный тобой геморрой?

White OwlА какой геморрой я описывал?
Структуру хранения, не обеспечивающую произвольный доступ к элементам.

White OwlПодытожу - лично для меня, при писании в нескольких средах, намного удобнее будет вставлять строки в структуру целиком а не класть в структуру указатель на внешнюю строку. Проще работать потому что.
Следует ли понимать так, что при работе в одной среде структура таки будет нормальной?

White OwlТакую фигню я никак не мог описывать! Либо кто-то плохо читает... либо кто-то плохо пишет :)
Однако, описал: http://www.sql.ru/forum/actualthread.aspx?tid=471697#4652211 , последняя строка.

Представь себе, что тебе надо уложить, например, 10 строк. Ты "пересортировал структуру" - то есть сделал сначала 10 int-ов с "размерами каждого массива", затем сами символы. Каким образом ты выполнишь операцию "вернуть шестую строку" не делая цикла по предыдущим индексам?