@hSpek

Есть ли способ сделать свой класс, где в Конструкторе можем задавать длину каждого блока под массива. Наподобие :
И уже автоматически, по заданным параметрам, строить нужный нам многомерный массив.

Я пробовал сделать поля класса самого класса (Как тока и не пробовал: использовал массив типа самого класса для поля _array, использовал обычный тип класса для поля _array ):
Но я не знаю, как именно подойти к нужному блоку под массива и там определить данные.
Это прототип, так что сильно не бейте...

0

@Элд Хасп

Непонятно.
Поясните и желательно с примерами.

0

@hSpek

По стандарту у нас задаются массивы на подобие :
Мне бы хотелось прописывать свой массив примерно так:
То есть, в скобках указывается размер каждого блока многомерного массива и многомерность этого массива определяется количество
Думаю установку элементов сделать через Set-метод вида:
где position - это indx-ы нашего значения в многомерном массиве.

Просто в разных проектах используются разные виды стандартных многомерных массивов (другие Коллекции типа Array, List и методы присущие им лучше избегать. Я понимаю, что они гораздо лучше будут вести себя в этой задаче) и чтобы постоянно не писать один и тот же код, хочу создать отдельный класс (или Библиотеку классов, еще не решил) с определенными метода, и в дальнейшем ими пользоваться.

0

@Элд Хасп

То есть, по сути, вы хотите сделать универсальный инициализатор для массивов любой размерности?
Тогда придётся работать с ним через методы Array, а не индексаторы.

0

@hSpek

Если я правильно понял, то скорее всего вы имели ввиду метод CreateInstance(...) в классе Array.
А можно как-то обойтись без него?

Хотелось бы увидеть что-то типа BinTree, где каждый узел имеет поля своего же класса.

0

@Элд Хасп

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

Использование массива, с точки зрения ООП, подразумевает, что все его элементы функционально равны.
Например в математической матрице СЛАУ или трансформации - все элементы это коэффициенты переменных измерений.
А например представить данные Person string массивом это уже неверно. Так как ФИО это хоть и стринги, но заменить фамилию на имя нельзя. То есть они функционально различны.

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

1

@wizard41

Если, например, приложения работают с некими внешними ВС, требующими инициализации по некоторым переменным, то матрицы значений (читай двумерные массивы) используются только шум стоит... )
Очень удобно, вместо описания списков значений, плюс скорость доступа выигрывает. У меня так эти 2Dim массивы почти в каждом приложении, работающим с ПЛК по сети.

Добавлено через 3 минуты
Вот для 3D-массивов пока не находил применения на практике. Это факт.

0

@Элд Хасп

Что такое BC ? Не понял.

И я не писал что многомерные матрицы не используются.
Они используются, но крайне редко, для каких-то специфических задач.
Одной из таких задач являются различные API и не .Net библы.
Но в целом в Шарпе стоит избегать многомерных массивов по многим причинам.
Одна из основных, что очень часто их использование нарушает ООП и SOLID.
А если вам (условно) не нужно ООП, то практически со 100% вероятностью вам не нужен и Шарп.

Ну, скорость - это, вообще, не к Шарпу.
Шарп решает совсем иную задачу в программировании.
Думаю, вы сами это прекрасно знаете.

Если этого требует API, оборудование - то что поделаешь.
Если же это ваша личная практика решения задач, то это плохая практика.
БЛ работает с нормальными сущностями.
Если Сущность нужно передать по сетке и для оптимизации трафика её нужно конвертировать в матрицу, то такое допустимо. Фактически подобное - это требование оборудования. И выделятся в отдельный слой по типу репозитория для БД.

Добавлено через 3 минуты
wizard41, опять же я не пишу TC'у, что многомерные матрицы нельзя ни в коем случае использовать.
Я просто предполагаю, что возможно он неверно выбрал способ решения задачи, и чтобы прояснил своё задание в целом.
Возможно есть более оптимальный способ его решения.
Тем более в свете необходимости создания универсальных методов работы для массивов любой размерности.
Как-то уж очень нереально такое требование звучит.

0

@wizard41

Вычислительные Системы
Не нахожу связи. Можете привести примеры таких нарушений?
Чем, например, переменная int[,] отличается от просто int в свете шаблона проектирования SOLID приложения?
Не согласен. Проводились многократные тесты по скорости извлечения тех или иных данных из структур разного типа. 2-мерные массивы выиграли во всех случаях.
Ну и потом, представление и работа с ним легче в плане писанины кол-ва строк кода. Допустим, таблица масштабирования некоторого значения (ломанная) выгоднее представляется именно в 2-м массиве.
Не нужно. Речь идет не о передаче массива по сети, а о представлении и извлечении хранимых значений внутри приложения.

Элд Хасп, я понимаю, что вы не можете охватить все возможные сферы, где Шарп сожительствует рядом с другим оборудованием, поэтому сложно приводить конкретные примеры для сравнения.

Добавлено через 2 минуты
На счет ТС'а - уж очень специфичное задание. Я на 99,9% считаю, что его требования можно выполнить более "гуманными" способами, конечно. А не садить козу волка и зайца в одну лодку.

0

@Элд Хасп

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

Ну, я об этом написал, что в математике такое встречается: графика, трансформация, СЛАУ и т.д. и т.п.
Где в науке может используются и массивы с большим количеством измерений.
Вполне, возможно, что моделирование струнной теории требует 10-11 мерных массивов.

Тоже об этом писал.

И что?
Если нужна оптимизация по скорости обработки информации, как в вычислительных системах, то с большой вероятностью лучше использовать другой ЯП. В большинстве таких задач даже старый, проверенный Фортран даст фору Шарпу.
Если же массивы нужны не для БЛ, то переход в Шарпе только из-за ускорения на них вряд ли будет оправдан. В целом для работы всего приложения это даст минимальное ускорение.

Опять таки, я не имею ввиду задачи, где многомерные массивы это естественное решение для БЛ требуемого задания.
Например, часто матрицы используются в БЛ аркадных игр для представления поля игры.

Поэтому и вопрос к ТС, чтобы он рассказал подробнее о своём задании.
Когда расскажет подробнее, то можно будет делать выводы о том действительно ли нужны для его реализации многомерные массивы.
Но, судя по его ответу что-то типа BinTree - массивы там "ни к селу, ни к городу".

0

@wizard41

Жесть. И кто-то так делает реально?

0

@Элд Хасп

У начинающих подобное встречается.

0