Выделение малых фрагментов памяти в dll

[Антон Ю.Б.]

Перешел на PChar, StrAlloc, StrCopy, SetString, StrDispose. Все работает без ошибок.

PString (а теперь соответственно PChar) я использовал только потому, что почему-то при приеме строки типа String из dll она обрезалась до первого перевода строки. Но это пояснение к причине вопроса отношения не имеет.

А к причине вопроса имеет отношение все-таки то, что если у меня есть базовый тип (пусть string сам по себе и не самый простой тип), и я имею право образовывать тип ссылочный от него, то при выделении памяти на мне лежит задача указать полезную нагрузку (размер, зависящий от длины строки), а вот выделение вспомогательных вещей со сдвигом влево от полезной нагрузки - это задача компилятора, если описание GetMem не имеет предупреждений об особых случаях. Я могу ошибаться, но вроде бы не имеет. Поэтому я не вижу ошибки в коде вопроса, и пока снята для меня проблема, а не вопрос.

[Vapaamies]

Сообщение от Антон Ю.Б.

        Res^:=TempS;

Вот эту строчку я воспринимаю как сомнительную -- с возможной утечкой памяти.

Сообщение от Антон Ю.Б.

Перешел на PChar, StrAlloc, StrCopy, SetString, StrDispose. Все работает без ошибок.

Даже не видя кода, предполагаю, что решение все же костыльное.

Попробуй описать изначальную задачу. Например, какого типа ModemWork.GetModemResponse? Что вообще нужно сделать в общем случае?

[Slym]

100 костыльно
яж ему почти готовый код (с маленькой ошибкой) по всем правилам винапи (сдернуто с ReadFile)
в коде только результ правильный вернуть и все готово
а он перешел на пичар... фу фу фу... @Быков

[Vapaamies]

Сообщение от Slym

яж ему почти готовый код (с маленькой ошибкой)

Тот код тоже костыльный. StrPLCopy -- костыльная функция, для обратной совместимости с теми, кто не осилил новые. А вот это вообще утечка:

Сообщение от Slym

  s2^:=S1^+'76543210';

Я согласен с Антоном в его недоверии к таким советчикам. И постановка "пока снята для меня проблема, а не вопрос" -- это по-нашему, это правильно.

[Slym]

Сообщение от Vapaamies

Тот код тоже костыльный. StrPLCopy -- костыльная функция, для обратной совместимости с теми, кто не осилил новые. А вот это вообще утечка:

StrPLCopy костыльная в D7? прув в студию
Новые? показывай...
Свой вариант в студию... будем сравнивать костыльность...

Сообщение от Vapaamies

Я согласен с Антоном в его недоверии к таким советчикам. И постановка "пока снята для меня проблема, а не вопрос" -- это по-нашему, это правильно.

Эта утечка намеренно тут продемонстрирована для раскрытия стиля автара, этот пример стабильно выдает AV на D7 и показан для того чтоб так не делали

[Антон Ю.Б.]

Коллеги, я рад за ваши познания, но все же дословно правильный ответ на мой вопрос был бы "In case of a typed pointer, you should consider the New and Dispose procedures, which respectively initialize and finalize the memory block accordingly".

При этом ответе сохранялись бы исходные типы переменных и используемые процедуры в своей прежней логике.

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

Второй пример не будет в общем случае работать и при перестановке строк местами.

При использовании New-Dispose строки, названные вами утечками, вовсе не являются таковыми, да и собственно подаются разработчиками как образец правильной работы.

[Slym]

Сообщение от Антон Ю.Б.

Коллеги, я рад за ваши познания, но все же дословно правильный ответ на мой вопрос был бы "In case of a typed pointer, you should consider the New and Dispose procedures, which respectively initialize and finalize the memory block accordingly".
При этом ответе сохранялись бы исходные типы переменных и используемые процедуры в своей прежней логике.

и при этом нельзя делать New и Dispose в разных модулях -где создал там убил
что автоматом накладывает ограничения на использование типов с магией автоуничтожения к которым относится String

Сообщение от Антон Ю.Б.

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

Обычно так и делается... Память тебе дается менеджером памяти, и вернуть ты должен память тому же менеджеру у которого взял. В приложении свой менеджер, а в длл другой менеджер, кроме того dll может быть скомпилена другим компилятором
почему в приложении?
а вот почему (псевдокод динамически загружаемой библиотеки)
неправильный код:
lib:=LoadLibrary(lib.dll)
Proc:=GetProcAddres(Lib,'Proc');
Pointer:=Proc(GetSomeData);//память выделена в длл
FreeLibrary(lib);
Caption:=Pointer; // AV т.к. менеджер памяти в длл все за собой зачистил

правильный код:
lib:=LoadLibrary(lib.dll)
Proc:=GetProcAddres(Lib,'Proc');
GetMem(Pinter,DataSize);//память выделена в exe
Proc(GetSomeData,Pointer,DataSize);
FreeLibrary(lib);
Caption:=Pointer;
FreeMem(Pointer);

Сообщение от Антон Ю.Б.

Второй пример не будет в общем случае работать и при перестановке строк местами.

РАБОТАТЬ? Не выдавать явно (AV) ошибку... Явная ошибка себя не проявит при перестановке...

Сообщение от Антон Ю.Б.

При использовании New-Dispose строки, названные вами утечками, вовсе не являются таковыми, да и собственно подаются разработчиками как образец правильной работы.

образец дают в автономном приложении, распределенное приложение накладывает дополнительные ограничения.
например либа на сях ничего о дельфевом PString не знает

[Антон Ю.Б.]

То, что память создается и выделяется в одном месте - это понятно. Я перенес это в библиотеку для большего удобства (сейчас по памяти не воспроизведу аргументов) работы с библиотекой из DotNet.

А второй пример у меня выдает AV при любом порядке GetMem'ов