Очень длинная арифметика
2. Непонятно, с какими числами ты работаешь, с целыми или вещественными. Если с целыми, то непонятно, как для них в принципе возможен различный вариант вычислений. А если с вещественными, непонятно, зачем им нужна различная длина, т.к. после первого же умножния длина результата будет равна длине наименьшего.
3. Прверять надо не сравнением с результатом работы других программ, а на специально подобранных примерах, которые не мешает просчитать ручками. Ты ведь не знаешь, как происходят вычисления в используемых тобой программах.
4. Никаких проблем с выводом в зависимости от основания не вижу. Для чего ты вообще пишешь библиотеку, если при ее помощи нельзя даже составить программу форматного преобразования?
5. Что такое плавный вывод чисел/символов я не знаю.
2. Тогда откуда разница в результатах?
3. А что, разве это еще не сделано?
5. А на банальное умножение затрат памяти и времени нет?
2. Еще раз: просчитай ручками и сравни.
3. См.п.2.
5. Ты пишешь модуль работы с длинными числами. Идеологически верно одно единтсвенное решение - именно при помощи этого модуля и делать форматное преобразование. Если модуль поддерживает различные системы счисления, для него должно быть безразлично, в какой из них хранятся данные. Форматное преобразование - частный случай вычислений, не следует относиться к нему как к чему-то особенному. Оно должно реализовываться посредством стандартных обращений к модулю.
И вы говорите об оптимизации вычислений не понимая, что компьютер работает исключительно с двоичной системой счисления.
Кстати, вы вообще можете представить, где может использоваться 8413184-битное число (а оно занимает ровно 1 мегабайт памяти) ?
З.Ы. Оно неизмеримо больше чем теоретическое число атомов во вселенной.....
1. Сделайте нормальный констуктор для структуры digit. Или обнуляйте после создания нового экземпляра.
2. После операции delete p, использовать p->next нельзя. Вы же уже память освободили.(longint.cpp:392 и много где ещё)
3. Пропущен return *this; (longint.cpp:130)
Вот только некоторые из них.
Поведение глючащей программы логическому объяснению не поддаётся. То есть это поведение по-своему логично и корректно, но в терминах и понятиях исходной задачи оно зачастую необъяснимо. Вот и здесь, вроде бы основание роли не должно играть, а оно играет! Скорее всего, если основание системы счисления меньше некоторого значения, то элементов в списке становится больше - и вуаля.
А почему массив больше 2 Гб нельзя?
Так вот, по той же самой причине: ограничение на адресное пространство.
При этом это ограничение касается всего: нельзя сделать один массив больше 2 Гбайт, нельзя сделать два масива суммарным объемом больше 2 Гбайт, нельзя сделать список объемом больше 2 Гбайт, нельзя сделать массив и список, чтобы их суммарный объем был болше 2 Гбайт и т.д.
Это свойство, как ты совершенно правильно отметил, 32-разрядной ОС.
Я вам про арбузы, а вы мне про помидоры. Что за цирк?
Я не понимаю как реализовать конвертацию из одной системы счисления в 10ричную, при БОЛЬШИХ числах, чтобы это было оптимизировано.
А вы мне пишете что я должен сделать. Я знаю что я должен сделать, это написано в первом посте еще.
Проблема в следующем:
любая программа делается в следующей последовательности:
1. Анализ задачи.
2. Проектирование.
3. Написание кода.
4. Отладка.
5. Тестирование.
6. Использование.
Так вот, твои вопросы относятся в основном к пункту 3, в то время как я вижу у тебя ошибки на этапах 1-2.
А твой вопрос по поводу систем счисления вообще относится к пункту 6. Об этом сейчас вообще говорить преждевременно.
Что же касается "Я знаю что я должен сделать, это написано в первом посте еще", то, поверь, это не совсем так. Ты пока еще достаточно плохо представляешь, что нужно сделать, и как. И твои попытки применить список там, где от него явно больше вреда, чем пользы (строго говоря, в твоем случае пользы от применения списка вообще нет никакой. Один вред), об этом красноречиво говорят. И то, что ты задаешь совсем не те вопросы, которые бы следовало, говорят о том же.
Так что если тебя интересует исправление УЖЕ допущенных тобой ошибок, я готов их с тобой обсудить. Если же ты хочешь продолжать делать программу явно неправильно, не взирая на имеющиеся ошибки, то я вряд ли захочу тебе здесь что-то советовать.
Длинные числа, насколько я понимаю, это числа, для хранения которых необходимо более 8 байт (т.к. 8 байт - длина самого длинного из стандартных типов). Так вот, реши сначала, каков максимальный объем памяти необходимый для записи чисел, с которыми ты хочешь работать:
1. Более 8 байт, но менее нескольких сотен Мбайт.
2. От нескольких сотен Мбайт до 2 Гбайт.
3. 2 Гбайта ровно.
4. От 2 до 4 Гбайт.
5. 4 Гбайта ровно.
6. Более 4 Гбайт, но менее 2^63 - 2^64.
7. 2^63 или 2^64 ровно.
8. Более 2^63 или 2^64, но ограниченное сверху число.
9. С любыми числами никак не ограниченными по длине.
Автор, ты представляешь себе что такое число, запись которого в 10-чной, скажем, системе координат, занимает 50, например, мегабайт?
Для чего поддержка таких случаев? Ты можешь назвать хотя бы одну область теоретической или прикладной науки, которая плотно работает с числами таких порядков?
Кроме того, операция например, умножения двух чисел, в каждом из которых, например, 10 миллионов знаков?
Теория чисел? Криптография? Олимпиадные задачи?
И у меня еще один вопрос, вы здесь говорите о производительности.
Вы уже столкнулись с проблемами такими?
Программы, использующие эту библиотеку, работают недопустимо медленно? Сколько занимает времени умножение двух чисел, в каждом из которых по миллиону знаков, в случае, когда числа представлены по основанию 2? По основанию 10? По основанию, скажем, 1000?