Добавление элементов в список <T>/ защитное программирование

Question

Явная проверка / обработка того, что вы не достигли максимального числа записей 2 ^ 31 - 1 (?) При добавлении в список C # - это сумасшествие, верно ли значение false?

(Предполагается, что это приложение, в котором средний размер списка меньше 100).

Answer 1

1. Пределы памяти

Что ж, размер System.Object без каких-либо свойств составляет 8 байтов (указатели 2x32 бит) или 16 байтов в 64-битной системе. [РЕДАКТИРОВАТЬ:] На самом деле, я только что проверил в WinDbg, и размер x 12 на 32-разрядной (x) (x64).

Таким образом, в 32-битной системе вам потребуется оперативная память 24 ГБ (чего не может быть в 32-битной системе).

2. Дизайн программы

Я твердо верю, что такой большой список должен храниться не в памяти, а на каком-то другом носителе. Но в этом случае у вас всегда будет возможность создать класс cached , обертывающий List, который будет обрабатывать фактическое хранилище под капотом. Таким образом, тестирование размера перед добавлением является неправильным местом для проведения тестирования, ваша реализация List должна делать это сама, если вам это понадобится однажды.

3. Быть на безопасной стороне

Почему бы не добавить счетчик повторного входа в каждый метод, чтобы предотвратить переполнение стека? :)

Так что, да, это безумие, проверять это. :)

Answer 2

Кажется чрезмерным. Разве вы не превысите лимит памяти машины в первую очередь, в зависимости от размера объектов в вашем списке? (Я предполагаю, что эта проверка выполняется пользователем класса List, и не выполняется ли проверка в реализации?)

Возможно, обнадеживает то, что коллеги думают о будущем? (Сарказм!)

Answer 3

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

Посмотрите на риск, посмотрите на усилие и сделайте суждение (иначе известное как обоснованное предположение! :-)). Я бы не сказал, что в этом есть какое-то жесткое или быстрое правило.

Answer 4

Да, это безумие.

Подумайте, что происходит с остальной частью кода, когда вы начинаете набирать эти цифры. Можно ли использовать приложение, если в списке будут миллионы элементов?

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

Answer 5

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

См. это обсуждение о куче больших объектов (LOB). Как только вы наберете около 21500 элементов (вдвое меньше, чем в 64-битной системе) (при условии, что вы храните ссылки на объекты), ваш список станет большим объектом. Поскольку LOB не сжимается так же, как обычные кучи .NET, вы в конечном итоге достаточно сильно его фрагментируете, чтобы не выделить достаточно большую область непрерывной памяти.

Так что вам вообще не нужно проверять этот лимит, это не реальный лимит.

Answer 6

Только что попробовал этот код:

List<int> list = new List<int>();
while (true) list.Add(1);

Я получил исключение System.OutOfMemoryException. Так что бы вы сделали, чтобы проверить / обработать это?

Answer 7

Правда

(ну, вы спросили, верно или нет ..)

Answer 8

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