Forum.iFiction.Ru

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 написал:

Извиняюсь, я имел в виду тот же пример, но с адресацией через формулу m[row*row_width + column]. Невнимательно посмотрел.

Различия минимальны.

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

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

Кстати, инициализация всех элементов данного массива производится одной строчкой: m[max_row * row_width + max_column] = 0. После этого указывать какую-либо верхнюю границу диапазона вообще нет надобности — все 100 (в приведённом примере) элементов массива теперь реально существуют (ARRSIZE('m')=100) и заполнены пустыми значениями.

Nex написал:

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

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

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

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

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

Nex написал:

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

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

Nex написал:

Авторы "А" - используют один способ, авторы "B" - другой.

Если бы всё было действительно так, но:

Nex написал:

Минус первого варианта для авторов A и B - им придется …
Минус второго варианта для авторов A…

То есть в своих пояснениях ты допускаешь, что авторы обоих типов могут пользоваться обоими вариантами, что изрядно путает. Впрочем, это уже к делу не относится…
Мы пришли к определённому консенсусу — что действительно славненько.