@Nubzilo:
Если лезет в память - отлично, делайте всё в памяти: используете библиотечную сортировку.
Финальный проход по времени исполнения - O(n) и по сложности написания - проще некуда.
Можно поменьше обращений к диску: гибридная сортировка.
Кусками (по 1гигу, например,) сортируем в памяти, эти куски выгружаем на диск и сливаем.
vilgeforce:
Вы путаете тёплое с мягким.
Язык C допускает возможность применения адресной арифметики.
ptr(i+j*4) - валидный?
Эксплойт, устраивающий переполнение буфера, не выделяет под этот буфер память.
И, уж если на то пошло, под DOSом NULL успешно разыменовывался.
Все эти доводы - к тому, что NULL - условность, програмистское соглашение, и, разумеется, нужно его по возможности придерживаться. Но некоторая свобода в рамках этих условностей есть.
vilgeforce:
В вопросе речь шла об индексах массива (int).
NULL - абсолютно валидный указатель, раз его можно присвоить переменной типа указатель.
Всё, о чем идёт речь, не стоит и выеденного яйца. В разных языках, в разных экосистемах исторически выработались вполне элегантные способы отсигналить вызывающей програме о неуспехе без привлечения лишних сущностей.
Сергей:
Механизм учета обычно называется програмной моделью.
Вы можете написать её на доступном вам языке програмирования,
детализируя желаемое поведение, например:
если "на персонаже бронежилет" и "с близкого расстояния пуля":
то "пуля должна его пробить"
и т.д.
Виталий, вам очень не хочется думать. Ну напрягитесь же.
Вот 3 первых простых - 2, 3, 5
Их произведение - 30
Для них можно построить такой массив steps: [2, 6, 4, 2, 4, 2, 4, 6]
Сумма всех этих шагов - тоже 30
Если мы стартуем, скажем, с 29(или 59, или 89, или...), прибавляя каждый раз по шагу, мы получим такой набор кандидатов в простые не больше 100:
29+2->31+6->37+4->41+2.....
[31, 37, 41, 43, 47, 49, 53, 59, 61, 67, 71, 73, 77, 79, 83, 89, 91, 97]
Все эти кандидаты взаимно просты с 2, 3 и 5.
Составные, которые туда затесались - 49, 77 и 91 - делятся на 7, 11 и 13