Гы, гы, гы. Знакомо до безобразия. Но через определенное время, почему-то, позиция менется обратно[/flood]

nesco, и нада-же, только Вы написали свой пост как БАЦ!!! И Язык стал, напрочь, не пригоден лля работы!



Размеры измерений многомерного массива - только фиксированные!
В топку такой язык, зря столько времени потратил

---

------------ Дoбавленo в 17.12:



Установил, протестил (FPC v2.4)

Итераций	Purebasic(ms)	Delphi(ms)	FPC(ms)
100 000	1	2	8
200 000	3	6	17

Протестировал в FPC 2.6 ,родной среде Lazarus(Win32) результаты те-же: 8 и 17ms.
Короче, победа! После долгих мучений с FPC, была найдена команда оптимизации для компилятора -O3 с которой код начал выполняться точно так-же как у Delphi, в таблице, 3 и 6ms соответственно.
Размер файла с формой и кнопкой, без упаковки 1,44 мб.

[offtop]Я кстати, тоже подумываю перейти на FPC + Lazarus (ООП + RTCG = Love)...
Обработка событий (да и не только) в PB убивает мой мозг
Особенно, когда я решил посмотреть на реализацию динамических гаджетов... да ещё потом с час думал, как это засунуть в RTCG

В общем, после тестов различных ЯП, решил остановиться на FPC + Lazarus, т.к.:
1) + ~1.8 мб.(0.5 с жатием) не особо критично для нашего времени.
2) Поддерживаемые для компиляции ОС: Linux, Microsoft Windows (Win32, Win64), Mac OS X, FreeBSD, WinCE, OS/2 и вроде для Андроида >2.x можно собирать.
3) ООП
4) FPC и LCL активно обновляются.
5) GNU GPL
6) Lazarus Documentation/ru wiki.
7) Inline Assembler
8) Довольно высокая производительность.
9) Небольшой размер дистрибутива и гибкий IDE, не жрущий кучу ОЗУ
...[/offtop]

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

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

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

login, [flood]
а можно по подробнее как именно, заинтересовался в проверке аналогичной функции в java[/flood]

login, в java для таких целей есть Vector() или ArrayList().
Различие - методы класса Vector синхронизированы, в то время как ArrayList - нет, что означает, что ArrayList быстрее по скорости.

В Lazarus есть утилита для чистки мусора в созданом им exe, которая сделает тебе из 1.44мб кбайт 200-300. Ищите и обрящите (с).
Вот вроде так (по памяти)

hitman249, подобные функции и в С++(их там штук шесть), и в сумме, их работа не гарантирует вообще ничего.. Тупо, так в справке и написано "Всё зависит от программиста". Еще там написано, что если надо увеличить массив на 1 элемент, подобные функции могут:

1. Создает в памяти еще один массив
2. Копируют туда каждый элемент + 1
3. удаляют старый массив. Плюс работа с "выделением блоков памяти нужного размера не гарантируется" надо своим кодом проверять, и всё такое..

А List типа у них работает только с адресами на ячейки памяти, а не их данными(поэтому работает быстрее) отсюда сложность кода растет соответственно. (и ошибки тоже )

Не знаю как в Java, но дело не в том, какой инструментарий есть в языке для создания мультимассива, а в том есть там готовый, правильно работающий, мультимассив или нет. В С и С++ - готового, якобы, нет(нужно делать скидку, что я могу не знать, это только то, что я смог понять прочитав всё то, что я смог найти про массивы).

Другими словами, hitman249, покажите мне как будет выглядеть код из поста 30 Mar 2012 07:33 на Java, чтобы он работал, так-же.
[offtop]В делфи всего две функции необходтмые для работы с массивом "создать" и "изменить размер" а в Java я насчитал 41
.
А вот и ответ: [/offtop]

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

login, вот про linux мануалы встретились полезные команды
и описание файловой структуры
вообще для программиста linux удобнее, в плане того что у него всё уже собрано в кучке, сиди и работай, не так как под windows

- по причине "язык не закончен". Это по сути полуфабрикат. Его еще нужно допиливать у себя в коде. "Вечная стройка".

------------ Дoбавленo в 10.55:
nesco, вы мне не поверите, но я прочитал вообще страшную вещ, массив копируется заново, потому, что он должен быть какими-то непрерывными блоками (память выделяется блоками из кучи), и может неоказаться блока нужной длинны, тогда программа получит отказ и слетит.
(Возможно я ошибаюь, не точно пересказываю)

Чтобы не брать на себя ответственность(типа чтобы не говорили что С++ отстой и он слетает, они тупо кпируют массив, для гарантий, зато предоставляют обширный инструментарий, чтобы программер сам совершил эту ошибку и виноват был он, а не язык )
(Возможно я ошибаюь)

login, а чего вы ожидали от языков, оптимизированных под максимально близкий (для высокоуровневого) к машинному код? Вы много видели процессоров, аппаратно поддерживающих динамические массивы? Массивы удобно применять при обучении ничего не смыслящих в физической организации памяти студентов-первогодок, по-этому они так популярны в учебных языках типа бейсика и паскаля. Потом некоторые студенты не захотели учить особенности железа и в угоду им были придуманы "взрослые" версии учебных языков. C и C++ изначально были сугубо профессиональными и подразумевали профессиональный контроль за всем, что делает результирующий код, с минимумом отсебятины со стороны компилятора.

Это напоминает чудика, который идёт покупать зеркальную фотокамеру за $50 000, а потом жалуется, что нихрена не фотографируется, в комплекте нет универсального объектива, слишком много ручек и кнопок, и инструкция в трёх томах.

1nd1g0, мы живем в физическом мире и наберется 2-3 наиболее удачных варианта работы с памятью применительно к массивам, в Delphi это понимают, они выбрали лучший - и реалиовали его. Язык обязан давать как простые инструменты так и сложные. А если даны 41 сложная операция а простая сделана с коммунистическим ограничением ("менять нельзя!") это переводится на человеческий язык как "мы не знаем как сделать такой массив, отстаньте от нас!"

Если в документации Java написано, что массивы "менять нельзя", то никакими инструментами вы их не поменяете так, чтобы не получать периодические рантаймы и экраны смерти. Если только вы не гений, или разработчик Delphi

"Я купил профессиональную камеру с 41 ручной настройкой и всего одной автоматической. Производитель камеры был ОБЯЗАН сделать автоматическую настолько крутой, чтобы мне нахрен не нужны были ручные (но для понту пусть будут), а раз он не знает, как сделать всепогодную универсальную кнопку "Снять круто!", то он - лох! "