Есть типы в Delphi; Code: type PTochka = ^TTochka; TTochka = record X,Y: single; end; type PGlobal = ^TGlobal; TGlobal = record Count: longword; X,Y: Single; Points: array of TTochka; end; и процедура: Code: procedure Mnogo( Points : array of TTochka; Count : Integer); использую все это дело так: Code: var Bot: TGlobal; SetLength(Bot.Points, 4 ); Bot.Count := 3; Bot.Points[0].X := 0; Bot.Points[0].Y := 0; Bot.Points[1].X := 0; Bot.Points[1].Y := 0; Bot.Points[2].X := 0; Bot.Points[2].Y := 0; Bot.Points[3].X := 0; Bot.Points[3].Y := 0; Mnogo(Bot.Points,3); Самое важное как раз таки вызов функции Mnogo, т.к. она зарыта в dll. На Delphi все прекрасно работает. Подскажите как это будет выглядеть на С++.
чето типа Code: typedef single // найди аналог, но она точно 32 бита struct TTochka { single X; single Y; } *PTochka; struct TGlobal { unsigned long longword; // хз single X; siggle Y; PTochka Points; // хз } * PTGlobal; TGlobal bot; bot.Points=new (sizeof(TTochka)*4); // дальше вроде так... bot.Points[0]->X=3;
а не могли бы вы описать как будет тогда выглядеть procedure Mnogo( Points : array of TTochka; Count : Integer); и как ее вызывать. пробовал и через указатель и через ссылку ексепшен и все. И Большое спасибо за код выше. С меня плюсы.
все те же проблемы с использованием с++ версии процедуры: Code: procedure Mnogo( Points : array of TTochka; Count : Integer); void Mnogo( PTochka Points, int PCount); объявляю так: Code: TGlobal GC; GC.Points = (TTochkaf*)malloc( 7 * sizeof( Tochka ) ); GC.Count = 6; GC.Points[0].x = 400; GC.Points[0].y = 100; .... заполняется на данном этапе все нормально, но при вызове: Code: Mnogo(GC.Points,6); приложение падает и дело именно в передачи массива. как все таки правильно это обвязать, подскажите.
Delphi: sizeof(GC) = 16 CPP: sizeof(GC) = 16 Delphi: sizeof(GC.Points) = 4 CPP: sizeof(GC.Points) = 4 Пробовал и выравнивать через "packed record" все равно креш на вызове функции.
ну и тем более что в структуре чисто single а он и там и там 4 байта и выравнивать там собственно компилятору ни сишному не борляндскому нечего. Обращение к функции и от туда и от туда идет через cdecl; Может все таки ошибка с объявлением или с вызовом. Code: 00427E55 test esi,esi 00427E57 jl 00427E77 00427E59 inc esi [B][COLOR=Red]00427E5A fld dword ptr [ebx+4] ; ebx = 2310140[/COLOR][/B] 00427E5D fadd dword ptr ds:[427EC8h] 00427E63 add esp,0FCh 00427E66 fstp dword ptr [esp] 00427E69 wait 00427E6A push dword ptr [ebx] 00427E6C call 004143FC 00427E71 add ebx,8 падает на сдвиге, выделено красным.
лично меня там ничего не смутило т.к. размер структур одинаковый,каким он собственно и должен быть, выравнивания блоков в памяти не происходит так как все переменные по 4 байта. На массив ему глубоко по душе т.к. в обоих случаях уходит указатель размером в 4 байта на массив, собственно для этого и второй параметр в функции, т.к. указываем сколько элементов в этом массиве. struct TGlobal { unsigned long longword; // 4 байта single X; // 4 байта siggle Y; // 4 байта PTochka Points; // 4 байта } * PTGlobal; =16 собственно меня как то это не настораживает.
набиваете посты???? По теме и так понятно с чего на что я переписываю, если знаете причину ошибки или даже как ее исправить то скажите пожалуйста, а если нет то к чему этот флуд? (на последний вопрос можете не отвечать, т.к. к дискуссии не относится)
их там не будет естественно не понял смысла Code: Действие 3. Переписывайте код на использование статических массивов, динамическое выделение памяти и нормальную передачу явных указателей. Дельфийские magic-типы в виде длинных строк и дин. массивов могут себе позволить передавать из/в DLL только олени. Если была бы возможность использовать статический массив то юзал бы. Но хиддеры четко описывают передачу динамического массива. Будь моя воля, я бы выделял память не посредственно внутри самой библиотеки, а потом по указателю уже передавал бы все нужные параметры. Олени эти, были явно под мухоморами, однако с делфийскими хиддерами все канает собственно, как по под фрипаскалем, однако под gcc, как раз таки траблы с этими передачами. вообще то я уже писал что вызов через cdecl а вот собственно текущий вид структуры: 100% можно обойти этот косяк. Но это длиннохвостая компиляторозависимая зараза выедает мозг.