CriDos, FPC + Lazarus, да, полностью Вас поддерживаю. Я тоже на нем и остановился. Такой выбор далается сам, если достатьчно внимательно изучать другие варианты(их не так много) которые есть. Но я по прежнему считаю этот язык(обязательный синтаксис) неудобным. Просто ничего не поделаешь.

CriDos, я немного почитал о С и С++, и оказывается, работа с памятью(мои динамические мультимассивы) это считается чуть ли не самой сложной и самой главной проблемой(по этому их нет в PB). В этих двух языках не только не решена проблема работы с памятью, а наоборот, проблема выпячивается на ружу(торчит из языка), и программисты всё еще ищут решения в этом месте.
То, что Delphi, по умолчанию, умеет динамически изменять размеры мультимассивов это просто разработчики постарались. В С и С++ такого нет и в помине(только ввиде библиотек энтузиастов(хуже делфи)), там есть запчасти от этого, и ты, не только должен сам этот велосипед собирать, но и явным образом дано понять, что это у тебя толком не получится сделать по аппаратным причинам. (говорю простым языком, как понял, уж извините )

На фоне вышесказанного то, что мы с Вами, выбрали FPC еще не гарантирует нам нормальную работу с памятью(выделение, распределение, очистка, утечки, скорость работы именно области данных(ее сложнее протестировать), а не логики(которую я там выше проверял)).
Именно поэтому штатный FPC HiAsm вылетает с 8 ошибками дотупа к данным, в процессе работы моей проги, в ней нет ничего кроме несложной логики и Opengl полигонов, она слетает из-за мультимассивов. Ошибок у меня нет, там все просто, все дело в реализации работы с памятью в языке.
Поэтому нет гарантии, что FPC 2.6 будет работать так-же стабильно как делфи, в принципе.
p/s
Еще я пока не могу сразу перейти на FPC потому, что самый важный элемент MIDI от Ivаnn, написан под KOL