» Вопросы по Embarcadero RAD Studio XE2 (Pulsar)

Цитата:

Ну если вы такой крутой аналитик, что можете заранее определить успешность различных инвестицый, то почему же вы сейчас сидите на этом форуме, вместо того, чтобы общатся по телефону со Стивом Балмером?

Не обязательно быть поваром чтобы ценить вкус блюд.

Цитата:

Попытки идти на соседние платформы я очень понимаю - на базе общей платформы (RAD Studio) сделать продуктов для разных платформ и расширить круг покупателей!

Попытки расширения я понимаю, но все они провалились. У них не получается создать что-либо достойное для других фреймворков/языков/платформ, а ресурсы отнимаются от основного продукта. Достаточно вспомнить x64. Первый раз обещали сделать в 2006-м году. Сделали в 2011-м. Сколько они теперь ARM будут делать?
В то же время усилия разработчиков распалялись на .net (c# builder/delphi.net), 3rd rail (ruby/rails), c++ builder X, rad php - все они провалились. А усилия разработчиков, деньги, время были затрачены. Вместо того чтобы развивать native разработку под windows они несколько лет баловались с .net, теперь разгребают последствия этого.
.net и cocoa touch полностью контролируется microsoft/apple. У embarcadero просто не хватает усилий чтобы успевать реагировать на изменения. C дотнетом они уже завязали. Теперь заигрывает с cocoa touch. По тому что я видел в xe 2 beta - это какое-то убожество.
Arioch1. Чего-то я не понял ваших рассуждений.

Цитата:

Когда они писали первые JBuilder в те же годы - было разумно и естественно использовать эти наработки и reuse как минимум работу специалистов по GUI, а возможно и прямо переписать код на Яву.

Тогда это были абсолютно независимые проекты и кроме ярлычка borland их вообще ничего не связывало. Jbuilder - проект изначально кроссплатформенный и об использовании поделок Microsoft с надписью java и речи быть не могло. В свое время я довольно плотно работал с jbuilder 9 (начинал с jbuilder 7). В 2003-м году эта среда была образцом удобства. Хоть и была тормозная и требовала кучу RAM для хоть какой-то работы. В появившемся чуть позже delphi 2005 cписок рефакторингов и их формы был практически одинаковы с джейбилдеровскими. Плюс требования j# для работы bds. jbuilder 2007 вообще никакого отношения к старым версиям не имеет. Это всего лишь набор сторонних плагинов для эклипса.

Цитата:

Вероятно, когда стало ясно что J# 2008 не будет, борланды решили что надо убить и Delphi for .Net и Delphi 2007 был последним в этой серии.

Вообще не вижу никакой связи. CodeGear (тогда оно так называлось) просто понял что их поделки под дотнет никому не нужны, не окупаются и они их не тянут. Вышел .net 3.0 с кучей новинок, которые эта фирма просто не в состоянии была отобразить в языке. jbuilder в той форме тоже никому уже не был нужен. Появились и набирали силу idea, eclipse (в том числе и платные сборки вроде myeclipse), netbeans, jdeveloper.

Arioch1

Цитата:

Когда выходит новая версия читать, что в ней изменили

Читайте читайте, у меня не всегда хватает времени прочитать что было в очередном апдейте моей онлайн игры, где я мастер клана в котором 200 человек, так что неудачно пристыдили.


Цитата:

оооочень стоит во избежаине сюрпризов.

Так сюрприз то в том что XE2 не является математическим аппаратом высокой точности, именно в роадмапе сказано что XE2 это только превиювка для 64, в следующей версии наверно вообще отменят ассемблерную инструкцию LOOP - щас она не работает. По сути не написан ещё асм для совместимости 32-64.


Цитата:

Кстати, раз если для вас обратная совместимость - абсолют, то ведь 10-байтный Extended вам никтo не отменял, он как был доступен, так и остаётся. Можете им пользоваться в точности как и раньше.

Поясните. Статью я прочитал. Полный бред - Extended80, который имеет 10 байт но имеет арифметику 8 байт. Совместимости никакой. Я бы поржал если бы астраномы или астрологи захотели перейти на 64 разрадную Delphi в данной реализации.


Цитата:

Вообще - ваши претензии в Интелу с AMD, пусть уже отменяют SSE.

Тут я тоже ничего не понял - при чём сдесь это? Они вообще решили отказаться от более точных чисел чем Double 8 байт? Если они задумали Extended128 найдутся умельцы которые перегонят свои данные через строковое представление без всяких потерь. У Embarcadero выхода просто не было и они попытались разрулить ситуацию, моё мнение - не очень удачно, однако приемлемо.

Добавлено:
Почему не очень удачно - есть уже написанный ассемблер работающий на процессоре intl286 без использования математического сопроцессора (тогда не у всех оно было), но этот ассемблер в лёгкую работал с Extended числами. Поленились передрать для совместимости.

Цитата:

В появившемся чуть позже delphi 2005 cписок рефакторингов и их формы был практически одинаковы с джейбилдеровскими.

Вот-вот. Ещё один аргумент, что чтобы написать новую среду для Delphi.Net использовали не команду Native Delphi, а команду Джавистов. Managed -> Managed. Потому и выбор J# вместо C# или Delphi.Net.


Цитата:

что было в очередном апдейте моей онлайн игры

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


Цитата:

асм для совместимости 32-64

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


Цитата:

Я бы поржал если бы астраномы или астрологи захотели перейти на 64 разрадную Delphi в данной реализации.

Именно астроном - точнее человек, изучающий структуру Солнце - не плакался в форуме, а написал тот самый юнит для работы x87 в x64.

А с какой стати вы заговорили о x64 ? вам совместимость же нужна - так и компилируйте *точно так же* как в прошлой версии - в x86. И будет вам родной Extended. Повторяю: Можете им пользоваться в точности как и раньше. Но только - в точности.

Хотите пользоваться новым компилятором под другую платформу - пользуйтесь, только изучите его сначала. Это другой компилятор, родственный - но другой.


Цитата:

но этот ассемблер в лёгкую работал с Extended числами

и с какой скоростью ? и как это будет сшиваться с SSE ?
пердставляю, что будет на форумах твориться, если скорость программы будет падать в сотни раз только из-за другого на два байта отличающегося типа.

В новой Delphi x64 решили ускорить плавающую точку - за счёт использования SSE.
SSE работает только со стандартными типами, single и double. Для 99% этого достаточно, получили халявный прирост скорости. Кому не повезло - или остаются на стандартной 32-разрядной Delphi, или пишут свои юниты.

Arioch1

Цитата:

Хотите пользоваться новым компилятором под другую платформу - пользуйтесь, только изучите его сначала.

Изучать Превиюхи (в роадмапе вполне понятно написано что это не полноценный вариант, и следующая версия тоже не называется у них полноценнойй), боже упоси изучать превиюхи, заглядываю туда исключительно чтобы меньше было сюрпризов с полноценной версией. Мои юниты поддерживают D3 - D_XE2, это не значит что я ношусь как угорелый с очередными апдейтами и сижу только на последних. Если Вы не сидели на карявой Delphi8 for .NET и не вычёсывали багу сотнями то не спешите с советами.


Цитата:

И будет вам родной Extended.

В том то и дело что его не будет. У меня клиентдатасет собственный поддерживает локальное индексирование в лёгкую открывает по две таблицы с тремя миллионами записей которые лукопятся между собой. Позволяет хранить все таблицы в одном файле, ну почти что база данных, у которой есть уже несколько пользователей и у кажного по нескольку баз. "База" поддерживает хранение double single BCD FmtBCD currency и extended. И кто то может плачется а у меня просто будет задача ВЫДРАТЬ данные в те типы которые обеспечивают точность в 64 версии.


Цитата:

пердставляю, что будет на форумах твориться, если скорость программы будет падать в сотни раз только из-за другого на два байта отличающегося типа.

Да ничё страшного не будет, так или иначе перейдут на новые типы данных (pointer который отличается от int32 и так далее). А если программа сможет конвертировать базу данных в 64 битную версию не потеряв точности данных, так тут я полагаю всем плевать на скорость.


Цитата:

ускорить плавающую точку - за счёт использования SSE.

Вы серьёзно считаете что в новой Delphi x64 решили угробить данные? И что совершенно точно известно что Extended128(TExtended80Rec) такого оператора не будет?

Добавлено:
ЗЫ
тезис о том что скорость шипко низкая (в статье) не был аргументирован ни сравнительными таблицами не был аргументирован описанием проблемы, так что оснований больше отнести сиё к рыночным технологиям, а не научным.

вы наверное в прошлом живёте, что у вас всё роадмапы и превьюхи.

Delphi XE2 уже зарелизился, и даже 4 апдейта выпустили.
И ms-help://embarcadero.rs_xe2/rad/Delphi_Compiler_Changes_for_XE2.html давно уже не роадмап (т.е. гадание на кофейнйо гуще), а свершившийся факт.

На Delphi 8 не сидел. И даже на Delphi 7 не сидел.
Ибо не в рейды бегал, а читал справку. И понял, что D8 даром не нужен, а D7 ничего мне сильно нового не даст.

> В том то и дело что его не будет.
Уэто ещё почему ? он уже есть и работает. Только не надо мечтать и рыбку и ёлку сразу. Плачешься по Турбо-Паскалю - а сам в Win64 норовишь. Используй x86 и там ничего не "сломано", все как тебе нравится.
Хочется новых рюшечек - у них есть своя цена.


Цитата:

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

А большинству - ровно наоборот. Во многих практических задач вообще результат округляют до 2-3 значащих цифр и как-то хватает. Вам 12 цифр не хватает - так используйте BigNum или другую аналогичную библиотеку, если вам скорость не нужна.

В Delphi x64 ничего не угробили, там нестандартного Extended просто никогда не было!
А что такое Extended128 ? этo Quad Float, который пока ни процессоры ни видеокарты не реализовали (ну кроме м.б. крайне редкого AVX)? Или что-то другое, с ним не совместимое ?
И при чём тут Extended80 - это разные типы?

Насчёт
Цитата:

совершенно точно известно

- начните с
Цитата:

они задумали Extended128

, где это они задумали тип, которого в железе нет пока нигде ? И когда они его задумали, через 10 лет ? С чего вы взяли что такой тип будет ?


Добавлено:
Вот FreePascal сделали поддержку x87 и SSE2 одновременно - получили совершенно неожиданные падения скорости
http://wiki.lazarus.freepascal.org/Improving_language_shootout_results

Ну и нафига такое счастье ?

Цитата:

С чего вы взяли что такой тип будет ?

Я думаю вы хотите перевести беседу в "срачь" и непонятно зачем. Зачем нужно институту метрологии и математике точность вычислений этому учат в школе. И так же правилам округления и точности данных. В википедии очень приличная статья по этому поводу только там нет антибанковского округления, для вычисления возможных потерь.


Цитата:

В Delphi x64 ничего не угробили, там нестандартного Extended просто никогда не было!

Вы хотите сказать что метрологическое оборудование будет работать на 64 битной шине? Вы издеваетесь, не ранее чем через 10 лет и не ранее чем появятся
Цитата:

Quad Float

и WideDouble.


Цитата:

нестандартного Extended

Вполне стандартный тип для платформы 32, все Math операторы используют именно этот тип. Вы слышали звон не знаете где он. Пытаясь ускорить Extended сделали такую каку - что если в Extended присвоить Double(1,777777) то получим 1,777778000019. Из за етого деиствительно много народу пополакало а вот так
VExtended:=StrToFloat(VarDataToStr(LSource)) - всегда точное присвоение, и кто знаком с этим способом давно забыли что он не такой быстрый. Далее использование Float-a в 32 extended арифметике без каких либо преобразований вообще.


Цитата:

нестандартного Extended

Да и тогда число Pi нестандартное - не такое круглое как в Double


Цитата:

так используйте BigNum

Ещё раз молодой человек, я решил не использовать DelphiXe2(64). Но изучаю исключительно для того чтобы меньше потом переделывать всё скопом. Похоже:


Цитата:

Ибо не в рейды бегал, а читал справку.

Зря читаете, почитайте Изотерику, что такое Наука ради Науки. (вполне с онанизмом совместимо). Лучше побегайте, - развивает коммерческую жилу.

> Зачем нужно институту метрологии и математике точность вычислений
а зачем им нужно именно 80, и ни битом меньше ни битом больше ?
и какую долю покупателей Delphi составляют институты метрологии ?

> метрологическое оборудование будет работать на 64 битной шине?
вопросы аппаратной совместимости к Delphi отношения не имеют.

> для платформы 32
ага, местечковый стандарт. За пределами "платформы 32" (точнее "платформы IA-32", ибо 32-разрядных платформ много) стандартом не является и никому не интересен. Не более стандарт, чем одно-байтовые float в видеокартах.


Цитата:

я решил не использовать DelphiXe2(64).

слава богу. Тогда вам и дела нет никакого, что там нет 80-bit float.


Цитата:

Да и тогда число Pi нестандартное - не такое круглое как в Double

вы не отличаете констант от типов данных ? вы снова меня удивили.


Цитата:

Изотерику

угадывать что вы имели в виду не хочу.


Цитата:

такое Наука ради Науки. (вполне с онанизмом совместимо)

80 бит и ни одним битом меньше - именно оно и есть.


Цитата:

развивает коммерческую жилу

Вот и скажите, какой коммерческий смысл Эмбу усложнять компилятор ради вас одного?

Arioch1

Цитата:

ага, местечковый стандарт. За пределами "платформы 32"

Я не платформу имел ввиду а Delphi, которая не пишет никаких платформ когда я компилирую с extended. По отношению к Delphi32 - Delphi64 и есть местячковое никому не известное поле деятельности.


Цитата:

вопросы аппаратной совместимости к Delphi отношения не имеют.

Вы похоже по диагонали читали. Я уже всё объяснил. Ещё раз, - имеется база данных в ней хранятся данные. Данные предварительно расчитанные но не окончательные, необходима их точность. База данных на Delphi, ПО разработанное на Delphi, заданная точность прописана в метрологических требованиях к ПО. ПО работает с аппаратурой в которой уже зашито 10 байт и прошивки пока не меняли. Моя задача хранить 10 байт - передавать 10 байт и давать возможность реализовать именно средствами Delphi именно продиктованную заранее точность без округлений продиктованных Эмбой или ещё кем-то.


Цитата:

и какую долю покупателей Delphi составляют институты метрологии ?

А что покупать то? ПО на Borland Pascal а не Delphi их вполне устраивает, а детский сад Delphi64 вызвал такой же шок у препода метролога. У него отбирают наносекунды за которые он может забраковать систему и потребовать взятку.


Цитата:

Вот и скажите, какой коммерческий смысл Эмбу усложнять компилятор ради вас одного?

Вы живёте в своих фантазиях. Лезете с советами BigNum, чтобы я свою библиотеку поставил на колени перед другой библиотекой. Решаете кому чем заниматься и что делать Эмбу если Intel наваяет новые инструкции то типа Эмб их отошлёт во всех версиях. Вобщем дальнейший разговор не имеет смысла, так как Вы уже за всех всё решили и без разницы о чём тут собеседник пытается растолковать.

Цитата:

delover

Одного не понял, к чему спорить если всё давно сделано и используется, зачем переходить на 64 бита и перекомпилировать программу с возможной потерей точности - что бы взять с заказчика доп. деньги? Ну не нравится - не пользуй

vez
Кто-то и не будет переходить вообще, а я то сам пользуюсь себя не похоронил ещё и собираюсь со временем переписать свой архиватор с асм32 на асм64. Да и доп деньги тоже хорошо, иногда раскручиваются...

Проект XE2 Win64

Код: function TIBCustomDataSet.Lookup(const KeyFields: string; const KeyValues: Variant;
const ResultFields: string): Variant;
var
fl: TList;
CurBookmark: TBytes;
begin
DisableControls;
fl := TList.Create; -- Не используется нигде, перекочевал в InternalLocate
CurBookmark := Bookmark;
try
First;
if InternalLocate(KeyFields, KeyValues, []) then
begin
if (ResultFields <> '') then
result := FieldValues[ResultFields]
else
result := NULL;
end
else
result := Null;
finally
Bookmark := CurBookmark;
fl.Free;
EnableControls;
end;
end;

Инструкции SSE2 введены оооочень давно. Плохо не то, что Дельфи их начал использовать, а то, что он не начал это делать намного раньше.


Цитата:

Вы уже за всех всё решили

Особенно за Интел, АМД и Эмбов, ага. Я им приказал, они сделали.
Это вы тут бунтуете, недовольны сложившимся порядком вещей.
Для меня 8-байтный Extended это гипотетическая неприятность, поморщился, учёл и всё.
Я согласен с рещением Эмбов, а вы - нет, вы и пытаетесь за них решить.


Цитата:

У него отбирают наносекунды

У него отобрали купленнуюю ранее Delphi ?
Или у него оттбрали 32-битный компилятор в XE2 ?

Не путайте "у меня отобрали" с " не сделали всех подарков по желанию моей левой пятки".
То что у вас было - то в точности у вас и осталось.
Никто вам не обязан что-то новое делать специально под ваши запросы.


Цитата:

Вы похоже по диагонали читали

Я читал как написано. Шина - значит шина. Если вы пишете одно, а имеете в виду что-то совсем другое, тут не я виноват.


Цитата:

чтобы я свою библиотеку поставил на колени перед другой библиотекой

Ой бида-бида. Перед компилятором ставить можно, перед Delphi RTL/VCL можно. А перед BigNum просто лучше на костёр пойти.!
А зачем вам BigNum, я уже два раза вам сообщал, о наличии библиотеки x87 для XE2/Win64 ?
Она наверное медленнее компилятора, но всяко быстрее целочисленной эмуляции.
Впрочем, тогда пожаловаться будет меньше поводов.


Цитата:

Delphi, которая не пишет никаких платформ когда я компилирую с extended

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


Цитата:

Delphi64 и есть местячковое никому не известное поле деятельности.

Так не лезьте туда и будьте счастливы! Зачем вам этот кактус ?


Цитата:

реализовать именно средствами Delphi именно продиктованную заранее точность без округлений продиктованных Эмбой

Пользоваться Delphi, только Delphi, и при том быть полностью свободными от ограничений Delphi - прекрасная идея!

может хватит уже спамить ни о чем? мы вам всячески сочувствуем, но тут не кабинет психологической разгрузки.

Цитата:

срань надо нести к мусорным ящикам

Прекрасное сравнение. Вам весь подъезд заставили коробками Delphi XE2, что пройти нельзя ?
Или что угодно лишь бы за уши притянуть ?


Цитата:

Либо программисты лентяи

Либо извращения типа Master-detail на SQL нужны только маргиналам и всем остальным давно наплевать.
А пересечение этого множества с IBX-пользователями и того меньше.


Цитата:

наслать на всех уважаемых русских электронщиков

Насылайте, насылайте.
Интересно, они все вам дали право что-то заявлять от их лица ?


Цитата:

не своих пророков

Ух, высоко взлетели! Стал-быть вас Господь посетил ? :-D

ХВАТИТ

Перевожу проект с 2007 на XE2. В проекте через xmlMapper + xmlTransform, xmlTransformProvider загружаю из xml файла инфу в ClientDataSet. После редактирования делаю ApplyUpdates(-1). Вылетает ошибка "Record not found or changed by another user". Нашел такую ошибку при сохранении в базу, лечиться UpdateMode у DataSetProvider на KeyOnly (я его не использую). Но у меня записывает обратно в xml. На 2007 работало все отлично, как это вылечить на XE2, спасибо.

Может проблемы с кодировками?

Цитата:

Может проблемы с кодировками?

Если ничего не менять в таблице (датасете), то сохраняется нормально. Если поменять, то из под делфы вылетает вышеописанная ошибка. Если просто экзешник запустить и поменять записи то сохраняется, но при следующем открытии из русского шрифта получаются кракозяблы. Такое ощущение что по лишнему байту дописали. Пробовал и string, и widestring, и ansistring. Кодировка везде стоит windows-1251.

кстати народ...а кто то может сказать почему из года в года такие свойства как width height и тд имеют тип integer? хз чего это именно ща мне так свербит...раньше просто беспокоило а вот сейчас прям засвербело...смысл этого типа в этих свойствах?минусовое значение не имеет смысла..проще visible изменить а вот ширину допустим формы в 2147483647 я себе представляю с трудом...на лицо явная избыточность и конец которой не виден...может я всей глубины задумки не понимаю?

а в чём избыточность-то ?

значения больше 32K все равно использовать нельзя, ведь Top, Left, TPoint.X & .Y - знаковые.
Так пусть лучше у них будет такой же тип, как у Left/Top, чем получать бесконечные варнинги.

x.Top := y.Top + y.Height; -> Warning: mixing signed and unsigned, extended values to 64-bit

Arioch1
ну так топ и лефт тоже изменить...я просто не понимаю смысла позиционирования объекта в диапазоне -2147483648..2147484647...тем более периодически диапазон этого типа увеличивается..

так ты что предлагаешь, Int16, -32K .. +32K ?

а зачем ? быстрее это не будет.
Скорее наоборот, на преобразованиях типов будешь лишнee время терять.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633545(v=vs.85).aspx

Памяти тоже не сэкономишь, учитывая сколько других свойств есть в TForm. Один юникодный Caption во много раз больше тратит.

Зачем ?

Arioch1
хз..просто свербит))) есть куча свойств тип которых мне непонятен..тем более переход с integer на smallint ровно в 2 раза урезало бы память на каждом свойстве....а с учетом что таких свойств у компонента 5-10...и компонентов на форме ~50-80...и форм в нормально проекте столько же... то была бы экономия

mdid
VCL - это вообще одна сплошная трата памяти, одни dfm-ки в ресурсах с их парсингом чего стоят. Добавьте сюда еще RTTI и выравнивание полей обьектов, массивов... Поэтому для тру программеров есть альтернатива: KOL, WinAPI, асемблер и т. д. Вот только это жутко неудобно.
Кстати в FM эти типы вообще Double - сплошная векторность одним словом.

Man_Without_Face
)nosmileyo)2dont

Добавлено:
Хорошая задача. КУуул.

mdid на каждом из целых 4-х свойств! ценой замедления работы. Сколько это в процентах пусть даже не у TCustomForm, а у TWinControl ?
Уж лучше пофантазируй за замену boolean'ов 1-битовыми переменными, или DFM без текстовых названий свойств - ещё и ускорение м.б. получишь

Нет, я понимаю, что 640КБ хватит на всех, это въедается.
Когда появидись 2-гигабайтные AnsiString я думал, ну да, 256 - это млаовато. Но лучше бы сделали строки по 32К - съэкономили бы два байта на счётчике. А строки длиннее 32К вменяемым людям не нужны...

А потом я смотрел на 4-кб DLL'ку и думал "многовато это дял простого плагина!". Убрал почти всё, что Дельфи добавила после Турбо Паскаля. Исключения, оптимизированный heap, варианты (вот чего не жалко было), ещё что-то. Yt помню, можно ли было вырезать AnsiString.
В общем, переписал серьёзно! - и D5 подарила мне прелестное дитя: DLL'ку размером 2КБ. 50% экономии на размере, не мелочь.
Вот только оказалось, Win2K не умеет загружать такие маленькие DLLки


Короче, действительно, напиши что-нибудь заметного размера на KOL-MCK, после этого свербит азметно меньше

Добавлено:

Цитата:

с учетом что таких свойств у компонента 5-10...и компонентов на форме ~50-80...и форм в нормально проекте столько же... то была бы экономия

Возьмём по максимуму. 2*10*80*80 = 128 000 байт < 128KB.
Уменьши стeк на 128КБ и успокой свой зуд :-D
Поменяй иконку и освободи в 2,5 раза больше!


Вот есть ещё менее радикальный подход, чем KOL-MCK: http://bouchez.info/lvcl.html

off-topic
Мне бы ваши проблемы, нашли что обсуждать, блин ... Каждый раз заходя сюда, надеюсь встретить интересный вопрос/ответ/солюшон ... узнать что-то новое. Но нет, каждый раз я здесь и каждый раз какие-то непонятные тёрки/потоки сознания/прочая дурь. Прямо базар какой-то, простите;

Eternal_Shield
Вам прямая дорога на StackOverflow.

не надо! он там был! с вопросами из справки...

лучше на http://hashcode.ru/

Приветствую всех!
Есть одна проблема. Подключаю стороннюю библиотеку (написана была на СИ-подобном) и в функцию передаю структуру как параметр

если делаю вот так, то все работает.

Код: TLevel = record
iValue1: Integer;
iValue2: Integer;
iValue3: Integer;
end;

TMainLevels = record
iSize: Integer;
iReserved: Integer;
aLevels: array[0..2] of TLevel;

Никак. Динамический массив - всегда указатель, потому что длина неизвестна.

Какой размер в байтах у твоей TMainLevels ? компилятор его должен знать заранее.

ЗАчем тебе это вообще нужно, чтобы была переменная длина ?

Добавлено:
TMainLevels = TList<TLevel>