Было бы это возможно?Да.Но с ним много проблем.
Например, рассмотрим, что Java хранит ссылки на BigInteger, который фактически размещен в куче, но хранит int литералы ,Разницу можно прояснить в C:
int i;
BigInt* bi;
Теперь, чтобы автоматически переходить от литерала к ссылке, нужно обязательно как-то аннотировать литерал.Например, если был установлен самый старший бит типа int, то другие биты можно было бы использовать в качестве некоторого вида поиска в таблице для получения правильной ссылки.Это также означает, что вы получите BigInt** bi всякий раз, когда он переполнится.
Конечно, этот бит обычно используется для знака, и аппаратные инструкции в значительной степени зависят от него.Что еще хуже, если мы это сделаем, то аппаратное обеспечение не сможет обнаружить переполнение и установить флаги для его указания.В результате каждая операция должна сопровождаться каким-либо тестом, чтобы увидеть, произошло ли переполнение или произойдет (в зависимости от того, когда оно может быть обнаружено).
Все это добавит много накладных расходов к базовымцелочисленная арифметика, которая на практике сводила бы на нет все преимущества, которые вам приходилось начинать.Другими словами, предполагать, что BigInt быстрее, чем пытаться использовать int и обнаруживать условия переполнения, одновременно совмещая проблему со ссылкой / литералом.
Итак, чтобы получить какое-либо реальное преимущество, нужнопришлось бы использовать больше пробел для представления целых.Таким образом, вместо того, чтобы хранить 32 бита в стеке, в объектах или в любом другом месте, где мы их используем, мы храним, например, 64 бита и используем дополнительные 32 бита, чтобы контролировать, хотим ли мы ссылку или литерал.Это может сработать, но есть очевидная проблема - использование пространства.:-) Мы могли бы видеть больше этого с 64-битным оборудованием, однако.
Теперь вы можете спросить, почему бы не просто 40 бит (32 бита + 1 байт) вместо 64?В основном, на современном оборудовании предпочтительно хранить данные с шагом 32 бита из соображений производительности, поэтому мы все равно добавим от 40 до 64 бит.
EDIT
* 1026Давайте рассмотрим, как можно это сделать в C #.Теперь у меня нет опыта программирования на C #, поэтому я не могу написать код для этого, но я ожидаю, что смогу дать обзор.
Идея состоит в том, чтобы создать структуру для него.Это должно выглядеть примерно так:
public struct MixedInt
{
private int i;
private System.Numeric.BigInteger bi;
public MixedInt(string s)
{
bi = BigInteger.Parse(s);
if (parsed <= int.MaxValue && parsed => int.MinValue)
{
i = (int32) parsed;
bi = 0;
}
}
// Define all required operations
}
Итак, если число находится в целочисленном диапазоне, мы используем int, в противном случае мы используем BigInteger.Операции должны обеспечивать переход от одного к другому по мере необходимости / возможности.С клиентской точки зрения это прозрачно.Это просто один тип MixedInt, и класс позаботится об использовании того, что подходит лучше.
Обратите внимание, однако, что этот вид оптимизации вполне может быть частью BigInteger C #, учитывая его реализацию в виде структуры.
Если бы в Java было что-то вроде структуры C #, мы могли бы сделать что-то подобное и в Java.