Sunter, В бинарном виде. У вас массив интов. Каждый инт хранит от 0 до 2^32 - 1. Фактически, число записано в 2^32-ичной системе счисления.
При выводе такого числа, надо делить его на короткие вроде 1000000000. Остатки выводить. Все, кроме последнего с ведущими нулями до 9 цифр. И в обратном порядке.
При сдвиге у вас есть перенос с младших разрядов. Сдвигаете текущую "цифру" влево, OR-ите с переносом. 32 младших бита в текущую цифру, оставшиеся - в перенос.
Складывать как обычно, только смотреть, чтобы переполнения не было - надо использовать int64 для промежуточных значений.
С умножениями чуть сложнее - надо или промежуточный массив из int64 завести, или базу уменьшать, чтобы аккумуляторы не переполнялись.
Sunter, У вас нет умножения длинных чисел, у вас есть умножение длинного на короткое (2^64). Если за раз не помещается, можно 2 раза домножить на 2^32.
Вообще, если база не степень двойки, то все плохо. Я так понял, у вас в строке цифры хранятся, так что база у вас 10. Сдвиги можно реализовать только умножением на 2 в какой-то степени.
ValdikSS, Сергей П, Да, не подумал об этом. Но это надо какую-то особо ключевую и сложную функциональность вынести в донгл. Если что-то простое выносить, можно отреверсинженирить. Да даже сложное тоже в общем-то можно. Донгл-то он не у вас на сервере код крутит, а у пользователя на столе лежит. Его и расковырять можно. Нужно что-то весьма криптостойкое и под заказ.
Это точно не "простой способ защиты", как хочет автор вопроса.
Без кода stack1 ничего сказать нельзя. Скорее всего у вас непонимание, как работают сишные строки char*. Если вы присвоите перемунную вот этого типа куда-то, то вы не скопируете значение строки, а лишь скопируете указатель на начало. Сама строка осталась неизменной.
Note regarding the c specifier: it takes an int (or wint_t) as argument, but performs the proper conversion to a char value (or a wchar_t) before formatting it for output
TyHoPoGO, Почему так понимаете? Это была подсказка, что вы, помимо ошибки в бинпоиске, пытаетесь искать корень вне области определения функции. Даже правильный бинпоиск там начнет выдавать фигню. А функция задана правильно.
Maksim Ivanov, Там, похоже перевод строки, который вы ввели после числа. Первые printf их из ввода не поглощают.
Попробуйте читать числа с переводом строки: "%d\n".
Марат Нагаев, Ну да, удаляйте только внутри Imgs. Снаружи указатель a надо не удалять. Можно после передачи его занулить. Можно вместо укзателя использовать unique_ptr, тогда все само удалится. Кстати, мешать C++ и malloc - плохая идея. Используйте new[] (и не забудьте тогда использовать unique_ptr<int[]>
iskateli, У вас все уравнения линейные. Если переменных не очень много, то можно решать графически. Но с 7 переменными остается только "метод пристального взгляда". Иначе говоря, угадывание. Как в вашем случае, решение 1,1,1,0,1,0,0 - очевидно.
floppa322, Комбинаторика сама по себе ответа никакого не даст. Она лишь поможет посчитать элементарные исходы. Условная вероятность тоже в итоге считает элементарные исходы, но иногда через нее проще рассуждать. Но по сути это все одно и то же: чтобы подсчитать вероятность события, надо взять количество благоприятных исходов и поделить на общее количество исходов.
Вот как есть у вас геометрическая задача и вам надо подсчитать площадь заштрихованной области. Можно разными способами пилить искомую область на части. Но итог один.
Вот в задачах на вероятность у вас тоже есть картинка - только многомерная и дискретная - где какая-то область заштрихована и вы тоже ищите ее "площадь". Условная вероятность - это вы берете и считаете площать фигуры как площадь какой-то другой фигуры минус лишнее. Комбинаторика - это как бы интеграл для подсчета площади. Классическая формула - это разбить на удобно считаемые части и отдельно каждую подсчитать.
Это в коде одна проверка. Не многословно и не забыть никак, если обертку использовать.
Ее в стандартной библиотеке, кажется, нет. Ибо, если, например, использовать unique_ptr, (который нужен по причине управления временем жизни объекта, а не вот этой вот), то нулевые указатели вообще никогда не придется разыменовывать. Также есть много разных случаев, где ваша проблема решается по-другому.
Lexluter20, 6 миллионов итераций - это не так много. на с++ это 10-50мс на современном железе.
Возможно, автор задачи подразумевал, таки, суммирование пока слагаемое не станет меньше епсилон. В этом случае итераций будет на порядок меньше, программа будет работать на порядок быстрее. Правда, сумма будет не такая точная.
