Есть ли любая другая причина около производительности и readiblity почему Система. Строка является ссылочным типом вместо типа значения?
Почему Строка была разработана как ссылочный тип вместо типа значения?
С точки зрения моделирования я смоделировал бы его как тип значения, так как это представляет что-то без идентификационных данных. Это не имеет различения атрибутов. (Например, я не могу иметь никакого значения между одной строкой и другой строкой),
Я знаю, что у меня были бы серьезные проблемы производительности при хранении длинных строк на стеке. Вероятно, это невозможно, поскольку строки становятся очень длинными, потому что стек ограничен в размере.
Если бы не производительность, почему Вы разработали бы Систему. Строка как ссылочный тип? (Предположите, что любая возможная строка самое большее 16 байтов длиной),
6 ответов
Структуры должны быть фиксированного размера. Вспомните, например, string[]. Единственный способ иметь string в качестве типа значения - хранить только указатель. Это по сути то, чего мы добиваемся, используя ссылочный тип.
Конечно, это также чрезвычайно выгодно тем, что мы не копируем строку каждый раз, когда присваиваем ее.
Насколько я понимаю, строки - это неизменяемые классы, а не структуры , только только для увеличения производительности.
Строки, как правило, создаются и затем передаются многим объектам для визуализации пользователю или передачи в другие системы. После создания строки, как правило, не изменяются, поэтому копирование всего массива символов в качестве уникального значения в каждом объекте имеет небольшую практическую ценность и создает множество временных объектов.
Как вы указываете, наличие типа значения, который может стать очень большим, может быть недопустимым из-за ограниченного пространства стека и семантики типов значений «копирование при использовании».
Кроме того, способ реализации строк в .NET добавляет к уравнению несколько элементов. Строки - это не только ссылочные типы, они также неизменяемы (в любом случае за пределами пространства имен System), а среда выполнения использует интернирование, чтобы делать изящные трюки со строками.
Все это дает несколько преимуществ: повторяющиеся строковые литералы сохраняются только один раз, и сравнение таких строк становится чрезвычайно эффективным, поскольку вы можете сравнивать ссылки вместо потоков символов Unicode. Эти параметры были бы невозможны для типов значений.
Просто - потому что я не хочу делать копии строк каждый раз, когда передаю их в метод. Требуется больше памяти и больше времени.
- ~ Отредактировано для более точного ответа на вопрос.
Один момент заключается в том, что тип String, как и во многих языках, закодирован как Unicode, и поэтому нелогично рассматривать их как примитивные типы (например, int ), как там нет прямого соответствия между его двоичной кодировкой и формой чтения человеком.
Уровень Unicode автоматически квалифицирует строковые типы, которые нужно абстрагировать от двоичных, тогда как числа относительно легко взаимозаменяемы между основанием 2 (двоичным) и основанием 10 (десятичным) .
Причина того, что примитивные переменные могут находиться в стеке, заключается в том, что для большого количества чисел доступно достаточно места. Это не относится к типу с большим объемом данных String .
Типы операций, выполняемых со строками, на самом деле не являются арифметическими, но в большей степени основаны на логической логике (за исключением подсчета строк, когда они обрабатываются как вектор или массив), поэтому имеет смысл оптимизировать структуру данных для ее основного использования, через пространство имен System.String.
С точки зрения equlity, у вас все еще есть возможность рассматривать его как тип значения с ==
оператор.
Так что, если что, то иметь его в качестве справки будет просто и выгодно?