1nd1g0, вы делаете некорректные сравнения. Я знаю что такое фотоаппарат. Мы осуждаем вещи с "дискретным колличеством критериев качества". Количество дискретных качеств у массива не более пяти. У фотоаппарата на порядок больше.

Наример почему нельзя сравнивать Сахар и Кинофильм. Потому что у сахара 3 критерия качества (сладость, степень очистки, влажность)
А у кинофильма их около 100 000. (реиссерская работа, игра главного актера, игра второго актера, музыка, сюжет, монтаж, декорации, бюджет и т д..)

Так вот, массив в нашем случае как Сахар. У него есть конечное состояние в котором он должен находится, (создать, изменить размер, удалить)
И сравнивать можно только то, можно ли достичь этого состояния в языке. (в книжке по C++ вообще написано что этого состояния нельзя достичь, с некоторой вероятночтью всегда есть RunTime Error в будущем) разработчикам java не удалось сделать вероятность наступления ошибки минимальной, поэтому они заблокировали смену размера. Delphi снизили вероятность до приемлимого минимума. PB снизили вероятность до минимума заблокировав только первые измерения массива. Это и есть реальная квалификация и уровнь возможностей всех этих разработчиков.

---

Это была ось X - "количество критериев". А есть еще ось Y!

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

login, кто тебе мешает сделать свой массив по принципу, как я указал выше. Ошибок быть не должно, если правильно все сделать и копирований одного массива в другой не будет, тк принцип совершенно другой. Если хочешь, то я могу описать тебе концепцию кластерного динамического структурного массива.

PS И все же я склонюсь к мысли, что у дядюшки Бормана сидели гениальные программисты

отмазка всегда найдется(шутка)
кроме лени и отсутсвия желания, как минимум мешает FTCG, это сложный код в целевом коде(внутри элемента) такие сложные элементы ниразу не делал, проще язык сменить

А кто такой дядюшка Борман?

login, метафора как раз была правильная и демонстрировала сомнительность целесообразности сравнений вообще. Вы не сравниваете мыльницу и "ручную" профессиональную камеру без автофокуса и автоэкспозиции потому, что вторая появилась гораздо раньше самих этих понятий. Так вот и не сравнивайте учебные языки с придуманными для ОБУЧЕНИЯ понятиями и сущностями и языки сугубо профессиональные, в которых самих этих понятий по началу не было. Парадигма МЫШЛЕНИЯ программиста совершенно другая подразумевалась: "Массив? Что такое "массив"? У меня есть память, регистры и порты, нет у меня никаких таких "массивов"!"

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

andrestudio, спасибо, понял, замолкаю.

1nd1g0, не надо скатываться до такого уровня. Задачи бывают разные, в том числе и такие, где нужно оперировать не только несколькими регистрами, но и развитым математическим аппартом. В конце концов, не мы созданы для компьютера, а компьютер создан для нас. И пора бы уже компьютер подстраивать под нас, а не нас под компьютер

nesco, никто не пропагандирует отказ от высокого уровня (мы таки на форуме сверхвысокоуровневой среды ), но, пока компьютеры и среды разработки для других людей делают такие же люди, знание того "откуда растут ноги" будет определяющим фактором различения степеней профессионализма в этой сфере. Людям свойственно вытворять такие вещи, что порою только прослеживание всей логической цепочки, отдо самого низа позволяет выявить истинные причины проблемы. Вон с теми же динамическими массивами : если не знаешь, что они работают на разбросанных по оперативке кусочках памяти и указателях, будешь долго думать, от чего именно вылетает критическая ошибка при попытке работать с массивом по указателю как с линейным блоком памяти (как подсказывал предательски здравый смысл).

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

Из цикла "Встретил рационализатора - убей его".

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

В C (C++) память выделяется непрерывным блоком не из-за лени авторов языка, а исключительно для быстродействия. "Массивов" в C вообще говоря нет - есть лишь "арифметика указателей". Поэтому получение i-го элемента массива в таком случае сводится к двум арифметическим операциям и одному обращению к памяти. Вычисление размера одного элемента (sizeof) происходит в compile-time, и в конечном коде является константой. Арифметика (сложение и умножение, в нашем случае) - это очень быстрая операция. А если компилятор хотя бы минимально умный, то эти промежуточные вычисления будут использовать регистры процессора (а не опреативную память). Все эти ухищрения становятся понятны, если вспомнить, что язык C был создан для написания операционных систем. Однако платой за быстрые чтение/запись является медленное расшириение массива: n чтений из памяти, n записей в память, n сравнений, 4*n арифметических операций (примерно, я мог чего-то и не учесть).

Однако не всё так плохо - в C++ есть STL (Standard Template Library - стандартная библиотека шаблонов), которая позволяет работать с "массивами" примерно с такой же лёгкостью, как в Pascal-е. Платой за это будет бОльший размер программы (ибо тащим за собой код, обеспечивающий ту самую простоту) и меньшее быстродействие (ибо ООП).

Если, как предлагает nesco, организовывать память в виде списка (если я правильно помню, то наш MT - это классический односвязный список), то получаем медленный (относительно) произвольный доступ: для получения i-го элемента мы обязаны прочитать все предшествующие элементы - это i обращений к памяти. Зато изменение размера такого массива происходит достаточно быстро (выделение места + запись одного указателя).

Короче говоря, holy war тут разводить бесполезно: каждый язык хорош для своих целей.

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

nesco, я не про кластерный метод говорил, а про классический односвязный список.

Теперь про твой "кластерный список" (если что не так понял, просьба больно не пинать).

Ну, как ты сам заметил, память будет использоваться неэффективно - мало того, что даже 1 элемент будет занимать целый кластер, да ещё нужна память для хранения таблицы этих кластеров. Таблица - это N*sizeof(pointer) (в случае кластеров фиксированного размера). Затраты на чтение: одно деление (а оно чуть медленнее, чем остальные операции; можно заранее посчитать 1/размер_кластера, тогда можно использовать умножение), две арифметических операции (вычисление адреса), чтение. То есть как всегда - теряем в памяти, выигрываем в скорости. Кстати, гибридный подход (выделение памяти кластерами, но с линейной адресацией) используется во многих классах-контейнерах из STL.

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

nesco, может создашь такой компонент?

Насчёт кластерности. Память сама по себе кластерная, хоть и кажется линейной. Как с точки зрения менеджеров памяти разных уровней, так и физически, для контроллеров и процессорных ядер. Это я к тому, что оптимизированный иили выравненный по реальным страницам памяти алгоритм будет иметь существенное скоростное преимущество и меньшие накладные расходы (перевыделение из-за "хвостиков", заступающих на соседние страницы).