Блог

Это простой на вид вопрос:

Учитывая, что целые числа собственного размера лучше всего подходят для арифметики, почему C # (или любой другой язык .NET) не поддерживает арифметику с помощью IntPtr и UIntPtr собственного размера?

В идеале вы могли бы написать код, подобный:

 for (IntPtr i = 1; i < arr.Length; i  = 2) //arr.Length should also return IntPtr
{
    arr[i - 1]  = arr[i]; //something random like this
}
  

чтобы это работало как на 32-разрядных, так и на 64-разрядных платформах. (В настоящее время вам приходится использовать long .)

Редактировать:

Я не использую их в качестве указателей (слово «указатель» даже не упоминалось)! Их можно просто рассматривать как C # аналог native int в MSIL и intptr_t в C stdint.h , которые являются целыми числами, не указателями.

В .NET 4 IntPtr поддерживается арифметика между левым операндом типа int и правым операндом целочисленных типов ( long , и т.д.).

[Редактировать]: Как говорили другие пользователи, они предназначены для представления указателей на родных языках (что подразумевается под названием IntPtr). Можно утверждать, что вы используете их как собственные целые числа, а не указатели, но вы не можете упускать из виду, что одна из основных причин, по которой собственный размер целого числа когда-либо имеет значение, заключается в использовании в качестве указателя. Если вы выполняете математические операции или другие общие функции, независимые от архитектуры процессора и памяти, на которых выполняется ваш код, возможно, более полезно и интуитивно понятно использовать такие типы, как int и long , где вы знаете их фиксированный размер и верхние и нижние границы в любой ситуации, независимо от аппаратного обеспечения.

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

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

Лично я ненавижу программирование с целочисленными типами, размеры которых я не знаю, когда сажусь, чтобы начать печатать (я смотрю на вас, C ), и я определенно предпочитаю спокойствие, которое дают типы CLR, очень сомнительному и, безусловно, условному выигрышу в производительности, который может предложить использование инструкций процессора, адаптированных к платформе.

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

Я полагаю, что я не одинок в этом мнении, так что это может иметь значение по какой-то причине.

На самом деле я могу назвать одну причину, по которой IntPtr (или UIntPtr) был бы полезен: для доступа к элементам массива требуются целые числа собственного размера. Хотя собственные целые числа никогда не предоставляются программисту, они внутренне используются в IL. Что-то подобное some_array[index] в C # фактически скомпилируется до some_array[(int)checked((IntPtr)index)] в IL. Я заметил это после дизассемблирования моего собственного кода с помощью ILSpy. ( index Переменная в моем коде 64-разрядная.) Чтобы убедиться, что дизассемблер не допустил ошибки, собственный инструмент ILDASM от Microsoft показывает наличие conv.u и conv.i инструкций в моей сборке. Эти инструкции преобразуют целые числа в собственное представление системы. Я не знаю, как влияет на производительность наличие всех этих инструкций преобразования в IL-коде, но, надеюсь, JIT достаточно умен, чтобы оптимизировать снижение производительности; если нет, то следующая лучшая вещь — разрешить манипулировать собственными целыми числами без преобразований (что, на мой взгляд, может быть основной мотивацией для использования собственного типа).

В настоящее время язык F # допускает использование nativeint и и его аналога без знака для арифметики. Однако массивы могут быть проиндексированы только с помощью int в F #, что nativeint означает, что это не очень полезно для целей индексации массивов.

Если это действительно вас так беспокоит, напишите свой собственный компилятор, который снимает ограничения на использование собственных целых чисел, создайте свой собственный язык, напишите свой код на IL или настройте IL после компиляции. Лично я думаю, что это плохая идея выжимать дополнительную производительность или экономить память, используя собственный int. Если вы хотите, чтобы ваш код идеально подходил системе, вам лучше всего использовать язык более низкого уровня с поддержкой встроенных функций процессора.

.Net Framework пытается не вводить операции, которые невозможно объяснить. Т.е. нет DateTime DateTime, потому что нет такого понятия, как сумма двух дат. То же самое рассуждение применимо к типам указателей — нет понятия суммы двух указателей. Тот факт, что IntPtr хранится как зависящее от платформы значение int, на самом деле не имеет значения — существует множество других типов, которые хранятся внутри как базовые значения (опять же, DateTime может быть представлен как long).

Потому что это не «безопасный» способ обработки адресации памяти. Арифметика указателей может привести ко всевозможным ошибкам и проблемам с адресацией памяти, которых C # явно призван избегать.