Нужны ли в современном C# такие коллекции, как "двумерный нативный массив/список" или "нативный массив/список строк"?

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

0

Сообщение от golosalex это как-то убрать ограничение на длину индекса

При этом было бы не плохо ещё определиться "зачем")

0

Сообщение от Usaga При этом было бы не плохо ещё определиться "зачем")

например для справочника простых чисел) чем больше тем лучше...

0

golosalex, а существующими средствами справочник простых чисел не делается?)

0

Сообщение от Usaga а существующими средствами справочник простых чисел не делается?)

Какой-нибудь список умеющий в индексацию по long думаю нет-нет, да и требуется. Скажем для того же блокчейна, где нужно максимально быстро иметь доступ к информации по адресу, если использовать обычный словарь, то очень быстро упрёшься в лимит int.MaxValue.

Я правда не уверен что с такими требования C# в целом удачный выбор.

0

Сообщение от Usaga golosalex, а существующими средствами справочник простых чисел не делается?)

чем больше простых чисел под рукой тем лучше)))

вот другой пример: сериализация в массив байт для передачи по сети. вот тут точно время от времени получаются огромные составные объекты и приходится что-то изобретать.

с другой стороны имеются скорее всего препятствия на уровне ассемблера чтобы массивы с лонг индексами работали быстро, так что имеем что имеем)

0

Сообщение от golosalex вот другой пример: сериализация в массив байт для передачи по сети. вот тут точно время от времени получаются огромные составные объекты и приходится что-то изобретать.

По сети предавать long-list? Зачем?!

0

Сообщение от golosalex с другой стороны имеются скорее всего препятствия на уровне ассемблера чтобы массивы с лонг индексами работали быстро, так что имеем что имеем)

Единственное препятствие - наличие памяти под этот массив.

0

Сообщение от Etyuhibosecyu или вам нравится, что сборщик мусора решает за вас?

Если поискать по интернету (самому лень сейчас), то можно найти тесты различных способов управления памятью.
Для обычного компа (на микроконтроллерах, например, это может оказаться не так) сборщик мусора .Net в общем случае показал наилучшую эффективность.
Кроме того, для уникальных случаев, когда требуется более тонкий контроль, есть слабые ссылки, есть таблица со слабыми ссылками, есть финализаторы и интерфейс IDisposable (и рекомендации по его реализации).

Я О-О-О-О-О-О-Очень сомневаюсь, что можно что-то кастомное создать более эффективное чем всё это.

Добавлено через 1 минуту

Сообщение от Etyuhibosecyu Нативный список основан на простых указателях (не управляемых), а не на массиве, а указатели могут быть освобождены моментально, не дожидаясь, когда заведется сборщик мусора.

Зачем?
В среднем, для общего случая, это приведёт к замедлению приложения.

Добавлено через 1 минуту

Сообщение от Etyuhibosecyu как справляетесь с утечками памяти, если, например, нужно выполнить сложные преобразования одной коллекции в другую, более сложные, чем LINQ-методы?

А как они там, вообще, могут возникнуть?
Для этого надо очень сильно постараться и задаться такой целью.

Добавлено через 1 минуту

Сообщение от Etyuhibosecyu Конкретный пример: разбить изображение на пикселы,...

А утечки памяти причём здесь?
Такое ощущение, что вы под ними подразумеваете нечто иное чем другие разработчики.

Добавлено через 2 минуты

Сообщение от Etyuhibosecyu Если да, то некоторые объекты он упорно не желает удалять - это разве не ошибка?

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

Добавлено через 5 минут

Сообщение от Etyuhibosecyu либо разрабатывать двумерный список, самоуничтожающийся сразу при вызове Dispose(), либо, если это никому не нужно, я не буду разрабатывать.

Что такое "самоуничтожающийся"? Даже если он никому не нужен (нет сильных ссылок на него) он всё равно будет висеть в памяти.
Чтобы это пространство "скинуть" в пул свободного места системы, для распределение по новым запросам, то мало просто отправить ссылку на него.
Надо ещё сдвинуть все объекты используемые процессом, а это приводит в переписыванию всех ссылок на них.
Это очень затратно.
Поэтому пусть висит в памяти, пока их не наберётся много и потом одним разом Сборщик Мусора всё это сделает.

Добавлено через 10 минут

Сообщение от Etyuhibosecyu двумерный нативный массив

Кстати, в .Net простые массивы типа T[,,..] независимо от от размерности - все нативные.
.Net оболочка этих массивов просто предоставляет доступ к нативному коду этих массивов.

2

Сообщение от Элд Хасп Что такое "самоуничтожающийся"?

У ТС-а все еще проблемы с мат.частью, ведь IDisposable ничего общего не имеет с полным освобождением памяти объекта.

0

Сообщение от Элд Хасп Кстати, в .Net простые массивы типа T[,,..] независимо от от размерности - все нативные. .Net оболочка этих массивов просто предоставляет доступ к нативному коду этих массивов.

Etyuhibosecyu, вот исходники метода создания массива:
Это из Framework. В Core аналогично, но не стал искать ссылку сейчас на них.
Массив создаётся нативной функцией, которая экспортируется в 65-66 строках.

0