Forum.iFiction.Ru

Nex написал:

Как раз в QSP-то, в отличие Бэйсика, размер массива и не задается!
Я писал об этом в предыдущем сообщении.
Массив считается теоретически бесконечным. Автор при использовании просто пользуется любыми ячейками массива на свое усмотрение.

Ну так я говорю не про указание максимальной размерности массива, а про то, каким этот массив представляет себе автор.

Даже если он учитывает нюансы автоматического заполнения интервалов в массиве, то после выполнения такой конструкции:

probe[3]=30

то есть ручного заполнения четвёртого элемента массива (и первых трёх — в автоматическом режиме), он ожидает, что размер массива будет равен 4. Если же он потом заполнит первые три элемента ненулевыми значениями, размер будет всё также равен 4. Но если он после этого поищет в массиве (ВСЕ элементы которого он же заполнил ненулевыми значениями) значение "0" — QSP вернёт ему позицию несуществующего с точки зрения автора пятого элемента.

Nex написал:

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

Перечитал. В своём описании порядка работы с массивами в QSP ты как-то всё усложнил, смешав как есть и как могло бы быть.

С точки зрения автора всё организовано просто (я не буду говорить про строковые индексы — они не влияют на суть):

1. Размер массива в QSP определяется максимальным индексом, значение которому было явно присвоено.
2. При присвоении любого значения элементу массива с числовым индексом, превышающим размер массива, массив увеличивается на соответствующее число элементов. При этом элементы, создаваемые автоматически, заполняются пустыми значениями и становятся "полноправными" элементами массива.
3. Считывание значения массива с любым индексом, даже выходящим за пределы текущего размера, никак не влияет на размер. При обращении к "несуществующему" элементу возвращается пустое значение.
4. Как правило, авторы организуют работу так, чтобы манипулировать значениями внутри диапазона, однако пункт 3 обеспечивает нормальное функционирование, даже если авторы выходят за пределы диапазона при считывании значения: и значение (пустое) возвращается, и массив остаётся нетронутым.

Однако, несмотря на "свободную расширяемость" массива, в каждый конкретный момент времени он (массив) имеет вполне определённый фактический размер (который можно получить функцией ARRSIZE), и этот размер автору либо уже известен, либо он его может получить. Так вот, возвращать функцией поиска значение индекса массива, который лежит вне этого диапазона, — на мой взгляд некорректно.

Отсюда и предложение — на уровне платформы ограничить верхний предел обработки массива функцией ARRPOS его фактическим размером, то есть тем значением, которое можно получить функцией ARRSIZE.

Nex написал:

Что интересно, KILLVAR не поддерживает строковые индексы. Недоработка. Приходится явно указывать соответствующий числовой индекс.

На эту "недоработку" я давно уже пытался обратить внимание.

Пока же для реализации удаления элемента по строковому ключу я пользуюсь такой функцией:

#УдалитьИзМассиваПоКлючу
    ! Параметры
        ! 1. 0 - Имя массива (тип: строка)
        ! 2. 1 - Строковый ключ удаляемого элемента (тип: строка)
    !----------
    dynamic "$<<$ARGS[0]>>[$ARGS[0]] = '!@#$%^del^%$#@!'", $ARGS[1]
    killvar $ARGS[0], arrpos('$' + $ARGS[0], '!@#$%^del^%$#@!')
    !----------
    --- УдалитьИзМассиваПоКлючу

Суть работы функции:

1. По искомому строковому индексу присваиваем элементу какое-нибудь уникальное строковое значение, которое точно не встречается в массиве.
2. Ищем индекс элемента массива по этому уникальному строковому значению.
3. Удаляем элемент массива по найденному индексу.

Nex написал:

Повторяю, есть два способа работы с массивами. Один из них опирается на "реальный размер массива", всегда известный через ARRSIZE, другой - на заданный автором диапазон.
Твое решение подходит только для тех, кто работает по первому способу.

А можно привести код с примером работы по второму варианту (где автор задаёт диапазон), чтобы понимать, чем же это отличается от "реального размера массива"?

Nex написал:

См. тему "Как сделать?", последнюю страницу. Я там привел пример работы с двумерным массивом с размерностью, определенной автором(10x10).

Ладно, скопируем пример оттуда:

i = 0
:loop_i
    j = 0
    :loop_j
        IF $карта[j+","+i] = "":
           *P " "
        ELSE
           *P $карта[j+","+i]
        END
        j = j + 1
    IF j<10:
      JUMP 'loop_j'
    END
    *NL
    i= i + 1
IF i < 10:
  JUMP 'loop_i'
END

и попробуем разобрать отличия в подходах применительно к изначально поднятой в данном топике теме.

Автор в своём коде использует массив "карта" со строковыми значениями элементов и индексов. При этом изначально массив никак не инициализируется — пустое значение, возвращаемое QSP при обращении к незаполненному явно автором элементу, вполне устраивает. Подразумевается, что в данном массиве хранится 100 элементов, хотя возвращаемое функцией ARRSIZE значение будет по мере заполнения массива (как значимыми, так и пустыми значениями) меняться от 0 до 100.

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

Но влияют ли эти отличия в описанных подходах к работе с массивом на работу функции ARRPOS (с ограничением диапазона поиска реальным размером массива) или приведённой функции удаления элемента по строковому ключу?

Нет, не влияют.

Рассмотрим работу этих функций применительно к примеру Некса.

ARRPOS в случае поиска возвращает числовой (и только числовой!) индекс массива. В данном примере смысла от числового индекса нет никакого — автор адресует ячейки строковыми индексами, и соответствие строковых и числовых индексов может быть довольно хаотичным. Если же эта функция используется просто для определения наличия в таком массиве (с подразумеваемым размером в 100 элементов), то всё равно автору нужно сравнивать возвращаемую позицию со своим предполагаемым размером массива, поскольку при его полном заполнении функция вернёт позицию 101 элемента, что некорректно. Однако подобное применение функции ARRPOS скорее исключение из обычного применения. И именно для таких исключительных ситуаций можно в функцию ARRPOS добавить параметр, определяющий верхнюю границу поиска, — но никак не делать это основным методом.

Функция удаления элемента по строковому ключу прекрасно удалит элемент, сдвинув "коллекцию" элементов. Однако, поскольку используются строковые индексы, то на работу автора с этим массивом это никак не повлияет — остальные элементы сохранят свои значения. Особенности же подхода к работе с данным массивов просто делает использование данной функции ненужным — проще будет просто присвоить нужному элементу пустое значение.

Вот я и говорю, что ты, Некс, как-то всё усложняешь, уходя от своего любимого "общего" подхода.

Nex написал:

Как раз об этом я и говорил. Приятно видеть, что пытаясь меня переспорить ты пришел в итоге к тому же выводу.

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

Olegus t.Gl. написал:

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

И в этот момент я как раз и имел в виду твоё предложение, поданное в довольно путаной манере:

Nex написал:

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

Особенно если учесть, что в своих объяснениях помимо "первого" и "второго" варианта различного использования массивов ты ещё вводишь понятия авторов "A" и "B", собирающихся использовать массивы каждый по-своему. Пиши яснее — и тогда на твои предложения можно будет сразу ссылаться.