После компиляции портятся/теряются данные

[pronto]

Доброго времени суток, уважаемые форумчане!
Столкнулся с проблемой некорректного копирования? данных. Эффект наблюдается только после компиляции проекта.
Имеется:
— обычный модуль с кучей функций и процедур;
— в модуле объявлен UDT;

Код: Выделить всё

Private Declare Sub CopyMemory Lib "KERNEL32" Alias "RtlMoveMemory" (ByVal Dest As Long, ByVal Source As Long, ByVal Length As Long)
Private Type INDEX_STATISTICS
   statKeys As Long
   statMaxLen As Long
   statMemUsage As Long
   statBytesPerKey As Single
   statTblUsage As Long
End Type
Private StatInfo As INDEX_STATISTICS


— на вызывающей стороне (форме) тоже объявлен этот UDT;
— из формы идёт обращение к функции получения статистики;
— эта функция возвращает указатель на заполненый UDT (Module1.Statistics = VarPtr(StatInfo));
— на вызывающей стороне, функцией CopyMemory, данные копируются в такой же UDT (пробовал объявление RtlMoveMomory, но оно и в режиме отладки даёт «пургу»);
— поля UDT, с применением форматирования строки (Format()), распихиваются по лейблам.

Данные проверялись — на стороне функции Statistics корректные. Не могу понять, где зарыт косяк?

[Jack Ferre]

Можно пример без "кучи функций и процедур"?

— эта функция возвращает указатель на заполненый UDT

А что мешает возвращать UDT?

[pronto]

Можно пример без "кучи функций и процедур"?

Долго выколупывать...

А что мешает возвращать UDT?

Ничего не мешает. Такой вариант работает, но мне хочется понять/решить проблему с CopyMemory (т.к. иногда нельзя обойтись UDT).

[Jack Ferre]

Не могу понять, где зарыт косяк?

А как должны понять остальные, если нет кода?

[bon818]

— на вызывающей стороне (форме) тоже объявлен этот UDT;
— из формы идёт обращение к функции получения статистики;
— эта функция возвращает указатель на заполненый UDT (Module1.Statistics = VarPtr(StatInfo));
— на вызывающей стороне, функцией CopyMemory, данные копируются в такой же UDT (пробовал объявление RtlMoveMomory, но оно и в режиме отладки даёт «пургу»);

— на вызывающей стороне, что там? CopyMemory VarPtr(StatInfoForm), FunctionStatistics(), Len(StatInfoForm)

[pronto]

Да, почти так:

Код: Выделить всё

RetVal = Statistics(id_Type)
CopyMemory VarPtr(IndexInfo), RetVal, LenB(IndexInfo)

[Хакер]

— эта функция возвращает указатель на заполненый UDT (Module1.Statistics = VarPtr(StatInfo));

Что гадаем?
Исходя из описания ситуая, структура StatInfo объявлена как локальная переменная в рамках вызываемой функции.
После того, как происходит возврат из вызываемой функции, указатель на локальную переменную из её стекового фрейма перестаёт иметь какой-либо разумный смысл.

При всём при этом, иметь две декларации одной и той же UDT и присваивание делать с помощью CopyMemory — крайне дурной тон и криминимальная практика.

[pronto]

Хакер, ты в очередной раз подтвердил своё звание телепата! Уважаю!
Но. Почему в режиме отладки это работает, и вылазит только после компиляции? Остаётся загадкой.

При всём при этом, иметь две декларации одной и той же UDT и присваивание делать с помощью CopyMemory — крайне дурной тон и криминимальная практика.

Выход? Объявлять UDT в модуле публично? Отказаться от CopyMemory при работе с UDT?

[alibek]

Используй для хранения данных байтовый массив, например.

[Хакер]

Почему в режиме отладки это работает, и вылазит только после компиляции?

Немного другая модель управления памятью под временные данные. На стеке, очевидно, размещается только указатель на UDT, сама UDT живёт в куче (heap), после соответствующего вызова HeapFree старые данные структуры не зануляются, поэтому данные структуры на правах мусора остаются в памяти.

Выход? Обявлять UDT в модуле публично? Отказаться от CopyMemory при работе с UDT?

Выход из чего?
Чтобы не иметь две UDT, нужно саму переменную в одном месте. Это должно быть единственное авторитетное объявление UDT, исключающее вероятность, что в одном объявлении захотят добавить новое поле, а во втором объявлении это забудут. (Это основная причина, почему это плохо и криминально)
Это может быть как публичное объявление в модуле, так и объявление в TLB (что особенно хорошо, если предполагается взаимодействие со сторонним кодом на уровне передачи ему указателей на нашу UDT или приёма таких указателей от него).

Выход из описываемого бага — заполнять не локальную переменную, а глобальную, и возвращать указатель на неё. Или выделять память в самой процедуре и заполнять выделенный фрагмент данными и возвращать указатель на него, а не вызывающую сторону возложить обязанность по освобожению памяти. Это конечно не очень хорошо, потому что заставляет прибегать к ручному управлению памятью, что может не сработать из-за забывчивости программиста или недальновидности программиста (если есть вероятность, что до вызова free-функции дело не дойдёт из-за ошибки и ухода выполнения на error handler). Если подумать в сторону автоматического управления памятью — то мы приходим к очень простой вещи — к идеи использовать вместо UDT класс.

[Хакер]

Используй для хранения данных байтовый массив, например.

А как это изменит ситуацию?

Если байтовый массив будет объявлен локально, то он так же перестанет существовать, как его локальная переменная.
Если использовать глобальный байтовый массив, то это ничем не лучше использования глобальной объявленной переменной As UDT, но больше геморроя.
Если изменить саму семантику взаимодействия, убрав необходимость копирования на стороне вызывающей стороны, то придётся делать интерфейс для освобождения регионов байтового массива и контролем его фрагментации.

[alibek]

ЕМНИП публичный UDT требует тип проекта ActiveX EXE.
А публичный массив не требует.

[Хакер]

Публичный UDT в модуле класса, форме или контролле — требует проекта типа ActiveX EXE или ActiveX DLL или ActiveX Control.
Публичный UDT в обычном модуле не требует особого типа проекта.

[pronto]

Самый простой вариант
В модуле:

Код: Выделить всё

Private Type INDEX_STATISTICS
   statKeys As Long
   statMaxLen As Long
   statMemUsage As Long
   statBytesPerKey As Single
   statTblUsage As Long
End Type
Public StatInfo As INDEX_STATISTICS

В форме никаких копирований:

Код: Выделить всё

lblStat(0).Caption = StatInfo.statKeys

[ger_kar]

Этот код странен тем, что структура объявляется приватной, а переменная с этим типом публичной.
По идее это противоречие.

[bon818]

— эта функция возвращает указатель на заполненый UDT (Module1.Statistics = VarPtr(StatInfo));

Что гадаем?
Исходя из описания ситуая, структура StatInfo объявлена как локальная переменная в рамках вызываемой функции.

Хорошая догадка, если учесть что Private StatInfo As INDEX_STATISTICS и находится в поле объявлений.

[pronto]

В том то и дело, что в проекте переменная была объявлена на уровне процедуры!.. А когда писал в форум, то безсознательно привёл одно из решений проблемы... Конечно, было бы приятней самостоятельно додуматься, ведь про уничтожение локальных переменных при выходе из процедуры усваивается сызмальства. Повторение — мать учения.

[ger_kar]

pronto писал(а):Почему в режиме отладки это работает, и вылазит только после компиляции? Немного другая модель управления памятью под временные данные. На стеке, очевидно, размещается только указатель на UDT, сама UDT живёт в куче (heap), после соответствующего вызова HeapFree старые данные структуры не зануляются, поэтому данные структуры на правах мусора остаются в памяти.

А зачем понадобилось так изменять модель управления памятью? Так лучше для отладки?

[Хакер]

Хорошая догадка, если учесть что Private StatInfo As INDEX_STATISTICS и находится в поле объявлений.

В том то и дело, что в проекте переменная была объявлена на уровне процедуры!.. А когда писал в форум, то безсознательно привёл одно из решений проблемы...

Телепатия — страшная сила.