Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова

Я смог въехать, когда ИИ попросил представить, что есть три человека. И тебе надо найти самого высокого. Сперва ты сравниваешь одного с другим, и того, который низкий - отсеиваешь, он тебе больше не нужен. А потом сравниваешь оставшихся двоих. И тогда оно в голове сложилось, как это работает.

Это ещё может так работать, что не надо пытаться сразу писать или понимать программу, а для начала чисто на уровне обычной логики осознать получение результата.

Без всякого программирования, просто представь, что тебе нужно найти максимум из трёх чисел. Которые, например, на бумаге ручкой написаны, что будешь делать для этого? Программа - это уже запись её средствами, пришедшей в голову логики решения.

liksys - вот тебе пример реальных проблем, которые новички в программировании могут испытывать. А ты тут по быстрому сначала Python, да ещё с ООП, потом Си для понимания конструкций и ускорения вычислений. Да до этого ещё, так сказать, дожить надо. Причём, глубоковложенные if'ы лучше изучать всё же на языке, в котором блоки явно выделяются begin ... end или {}, а то на Python можно и совсем запутаться в их логике, несмотря на красоту отступов.

«книжка не правильная»

по сути есть два края - один «мы» определяем в каком мы состоянии - и действуем - этому соответствует дерево ифов(либо опись конечных условий и действие выход) и соответсвующее полному состоянию действие

либо

мы «морфим» состояние унифицирую(инвариантирую) к некоторому целевому - это подход через изменение некоторых «глобальных относительно изменения» переменых - т.е. буквально концепция памяти и в целом побочки

настоящие программирование это навык где достаточно чистого а где нужно грязнить связями через память(пишем а затем читаем)

psps ; этому соответсвуют две ментальные модели

есть конвеер по котором летит состояние - если мы через дерево то это ветвление и состояние(экземпляр) в зависимости от некоторого условия уходит по левой или правой ленте конвеера и где-то в оконцове действие над классифицированым состоянием

второй подход «проще»(но он связан с постепеной модификацией состояния экземляра заготовки) - есть конвеер на ленте есть тесты если тест срабатывает то состояние передаётся в руки «роботу-модификатору» который обобщаяет состояние и делает какоето действие и возвращает на ленту - как итог вся программа выгляить как набор действий под защитой - сырец проще но возможные траектории исполнения эквиваленты дереву.

зы. вопрос удержания в мыслях в каком мы контексте в той или иной строке - без шуток курни:

Дейкстра почему goto это плохо

Хочется напомнить, что Python - третий в череде сходных языков, используемых для обучения студентов более 40 лет. Теоретики такие теоретики.

Нашёл на хабре комент по поводу книги: https://habr.com/en/news/1031636/#comment_29967908

Там бывает ещё не только радикализм во взглядах, но и фактические ошибки, в т.ч. не исправляемые по идейным соображениям. Вот, например, во втором томе по языку Си на стр. 17 есть такое:

" С литералами восьмеричными и шестнадцатеричными ситуация примерно такая же, только компилятор не пытается делать их знаковыми. Иначе говоря, если хватает разрядности unsigned int’а, то он и используется, если же не хватает, компилятор пытается использовать unsigned long и unsigned long long "

Насколько мне известно, в стандарте языка Си другие правила, и такие литералы могут быть по умолчанию знаковыми. Путаница может приводить к undefined behavior при умножении. Вообще в книге мало упоминается undefined behavior.

Или такая неверная информация про типы данных на стр. 17, которая может привести к коварным ошибкам при попытке скомпилировать программу с помощью MSVC или MinGW (но, насколько я знаю, он Windows не любит), и ему на это указывали в гостевой. Вот цитаты из книги:

«Зато на 64-битных платформах «подрос» следующий тип, long; он стал 64-битным, в результате чего совпадает с типом long long. Но здесь мы уже забежали вперёд»

«Отметим ещё один момент: действует соглашение, по которому разрядности числа типа long должно на любой архитектуре хватать для представления указателей»

А на стр. 30 - неверная сигнатура " void *malloc(int size); " для malloc, т.к. он из-за нелюбви к комитетам по стандартизации языка не приемлет даже size_t.

Также там имеются попытки вторгаться в чужую предметную область в разделе «4.10.3. Генерация псевдослучайных чисел». А именно упоминается функция rand для не связанных с безопасностью приложений, в т.ч. метода Монте-Карло, и говорится о том, что «целом псевдослучайные числа имеют распределение, достаточно близкое к равномерному». Но все широко распространённые её реализации содержат грубейшие статистические дефекты и непригодны для каких-либо расчётов вообще. Насколько я знаю, Столярову на это также указывалось.

И вот это, наверное, главная претензия к Столярову вообще: ошибки, не исправляемые по идейным соображениям.

Хочется напомнить, что Python - третий в череде сходных языков, используемых для обучения студентов более 40 лет. Теоретики такие теоретики.

Языку Python менее 40 лет вообще, ты о чём вообще? Насчёт сходности, то с чем он сходен?

вот тебе пример реальных проблем, которые новички в программировании могут испытывать.

Этот пример проистекает из некачественности учебного материала и совершенно не опровергает ни один из моих тезисов.

И вот это, наверное, главная претензия к Столярову вообще: ошибки, не исправляемые по идейным соображениям.

Не факт, что именно по идейным.

может привести к коварным ошибкам при попытке скомпилировать программу с помощью MSVC или MinGW (но, насколько я знаю, он Windows не любит)

А не надо писать код, который полагается на конкретную разрядность элементарных типов, кроме char (он-то надеюсь всегда восьмибитный?)

А не надо писать код, который полагается на конкретную разрядность элементарных типов, кроме char (он-то надеюсь всегда восьмибитный?)

Так ведь Столяров в п.4.3.3 т.2. как раз и занимается этим полаганиям, потратив несколько страниц на объяснение, что в MS-DOS int 16 битный, что в i386 - 32-битный, потом про long long. Чтобы проиллюстрировать, что у базовых типов может быть разная разрядность это верно, но неверно, когда он начинает писать, что long совпадает с long long на 64-бит. Потому что не везде совпадает. Фактически то, что пишет Столяров в этом параграфе верно только для x86-х архитектур и только для gcc в Linux. Столяров ни слова не сказал про типы с фиксированной битностью, введённые в C99, те что в <stdint.h> (вроде int32_t и др.). Но это же «комитетские мрази» придумали, поэтому Столяров будет упорно гнать лажу. Которую он принципиально не исправит.

Вообще получается, что если 1-й том в целом можно спокойно рекомендовать для обучения, то уже 2-й с очень большой осмотрительностью. Местами эта книга уже просто вредна даже. И это я ещё по диагонали её читал, вон пункт про типы в Си мимо внимания прошёл, в отличие от комментатора на Хабре.

Так ведь Столяров в п.4.3.3 т.2. как раз и занимается этим полаганиям, потратив несколько страниц на объяснение, что в MS-DOS int 16 битный, что в i386 - 32-битный, потом про long long.

Ну так он разве врёт? int в DOS действительно 16 бит, разве нет? Мне не очень хочется перечитывать, но и так должно быть понятно, что размер не постоянный.

Столяров ни слова не сказал про типы с фиксированной битностью, введённые в C99, те что в <stdint.h> (вроде int32_t и др.).

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

Местами эта книга уже просто вредна даже.

Думаешь? Мне кажется, эти нюансы всё равно с опытом приходят и их так не запомнишь.

Ну так он разве врёт?

Он пишет:

Зато на 64-битных платформах «подрос» следующий тип, long; он стал 64-битным, в результате чего совпадает с типом long long.

Это верно в модели данных LP64, но неверно в LLP64 в Windows. Может быть и ещё где-то неверно.

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

Всё можно, но не грех было бы и показать как именно, поскольку он во 2-м томе уже как бы практическому программированию учит и это важный практический момент, в конце-концов, 2026-й год, надо бы показать как правильно писать программы на Си, как раз не делая предположений о битности базовых типов. Вообще, использовать сейчас в реальных задачах базовый тип вместо фиксированной битности - это или небрежность, граничащая с ошибкой или хорошее понимание зачем и почему.

Но дело не только в этом, если верить комментатору, то ему на ошибку с long long указывали, но Столярову на неё пофиг.

Не факт, что именно по идейным.

Факт. Когда ему сказали про то, что возвращаемое значение malloc надо проверять, он забанил говорящего. Потому что манямирок столярова не должен подвергаться сомнениям. Столяров - просто клоун, строящий из себя пророка.

А не надо писать код, который полагается на конкретную разрядность элементарных типов, кроме char (он-то надеюсь всегда восьмибитный?)

Какая прелесть. А аппаратно-зависимый код как предлагается писать?

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

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

У этого клоуна есть технические аргументы против этого стандарта?

Он считает, что C99 нарушил философию языка Си, которая по его мнению заключается в том, что язык (компилятор) позволяет генерировать абсолютно предсказуемый и прозрачный ассемблерный код. Что программист в Си может полностью контролировать выделение памяти и использование стека, а VLA скрывает логику, динамическая работа со стеком потенциально опасна. Кроме того, для VLA sizeof оказывается не вычислим при компиляции и генерирует обширный код. Ещё он докопался до inline, объявлении переменных внутри кода и ещё по мелочам, вроде того, что // считает размытием границ между C и C++.

С моей точки зрения, непринятие VLA может быть и оправдано, фича довольно сомнительная получилась, недаром в C11 они стали опциональными. Но остальные претензии какие-то глупые.

полно хуже Столярова «методистов»

и мало кто лучше - вот например Арьков Валентин Юльевич из Угату?(ну Уфимец) - у него очень представительный набор методичек по информатике - и в целом имхо очень реально эффективные в части приобщения к.

имхо у столярова(с маленькой буквы) ретроградство(не всмысле устаревшего а буквально как следстие утёнка к чему по первости прирос душой то и эталон идеала)

разрядность элементарных типов, кроме char (он-то надеюсь всегда восьмибитный?)

Бит всегда однобитный?

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

Это верно в модели данных LP64, но неверно в LLP64 в Windows.

Из контекста книги очевидно, что речь идёт о GNU/Linux и FreeBSD. Он мог бы упомянуть, как забавный факт, что в Windows в отличии от нормальных ОС даже это сделано через задницу, но не стал, хотя несколько других забавных фактов о Windows упоминается, например как «я» может устроить EOF у криворуких и нужен флаг b для чтения файлов. Может сам не знал, может не посчитал нужным. В гостевой уточняли?

В книге и в гостевой поиск по ключевому слову LP64 (который захватит и LLP64) ничего не даёт. Я помню, что удивлялся трансанальности Windows в этом вопросе ещё когда 64-битная версия была новостью.

Вообще, использовать сейчас в реальных задачах базовый тип вместо фиксированной битности

А char можно? Ну и в принципе наверное short везде два байта и int везде кроме DOS четыре байта, исходя из того что под 8, 16, 32 бита нужны отдельные целые типы и кроме этих трёх других подходящих базовых нет. А если надо 64 можно везде писать long long на всякий случай, хотя было бы логичнее сделать long 64-битным, а long long 128-битным. Интересно 128-битные целые в C вообще есть?

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

Ой ли. Довольно многочисленная группа людей (включая меня) считает что MS приняла очень дальновидное решение оставив long одинаковыми между 32мя и 64мя битами. Целого класса проблем удалось избежать. А в «самой правильной системе» int64_t в 32ух битах алиасится в long long (ожидаемо), а вот в 64ёх - в long (нежданчик), и это реально проблема. И поправить это уже так просто нельзя потому как ABI.

MS приняла очень дальновидное решение оставив long одинаковыми между 32мя и 64мя битами. Целого класса проблем удалось избежать. А в «самой правильной системе» int64_t в 32ух битах алиасится в long long (ожидаемо), а вот в 64ёх - в long (нежданчик), и это реально проблема. И поправить это уже так просто нельзя потому как ABI.

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

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

Что мешает поискать по его сайтам (http://rebuildworld.net/ и http://stolyarov.info/) и книгами (благо наконец текстовый слой есть штатно и залазить с qpdf больше не нужно)? Я думаешь наизусть все его аргументы помню? Но главное возражение — VLA (stolyarov.info).

Но кстати в той же MS Visual C 6.0 не поддерживается C99, так что вот тебе аргумент не от Столярова, а от его противоположности.

А можно узнать, что за проблемы?

Невозможность «запретить» long который «плавает» (в плюсах для этого есть механизмы) и продолжать использовать int64_t.

Кто тебе запрещает использовать int64_t? И кому-то нужен тип который меняется в зависимости от битности процессора, так что long подходит.

Ещё раз (следите за руками): очевидные проблемы с RPC long’ов между 32ух и 64ёх битными аппликухами на одном железе, с очевидным решением - забанить long в соответствующем API, и c абсолютно неожиданными фоллаутами при попытке передать int64_t. Так понятнее?

кстати в той же MS Visual C 6.0 не поддерживается C99,

1. В каком году вышел этот компилятор?

2. C99 уже не стандарт.

C99 уже не стандарт.

С here are ли?? Его что, «вымарали» из ISO??.. Нет.

Не самый «свежий» стандарт, возможно (я не знаю, да и не суть), но - стандарт, и стандартом останется....

В каком году вышел этот компилятор?

Под Windows до сих пор MSVC всё компилируют. MinGW правда ещё есть, но с ним свои сложности. Там вместе с компилятором пришлось половину GNU притащить.

Под Windows до сих пор MSVC всё компилируют.

Из студии 6.0 ?

Я откуда знаю? Когда я сидел на Windows, все пользовались 6.0 хотя она уже устарела. А MS VS 2005 занимала целый DVD, что как мне кажется, для компиляции Hello World было избыточно. В итоге я как раз тогда перешел на линукс и там изкоробки gcc куда удобнее был и компилировал не так криво.

Тогда же я поставил Delphi и C++ builder современной на тот момент версии (200x не помню) и оно хотя бы запустилось, но тоже было крайне жирно. Если его закрыл, а потом снова открыл надо ждать секунд 10. А в линуксе открываешь nano / vim / emacs за долю секунды и пишешь код — гораздо удобнее.

Жаль, что преподаватели тогда не знали про FreePascal и о нём я узнал когда курс программирования на паскале уже закончился.

Его что, «вымарали» из ISO??..

Отозвали, заменили и зачеркнули

https://www.iso.org/standard/29237.html

Отозвали, заменили и зачеркнули

От же ж... гммм... супостаты!...

https://www.iso.org/standard/29237.html

Спасибо, но мне оно не надо. :)) На слово поверю... :)

преподаватели тогда не знали про FreePascal

FreePascal уже умеет работать без линукса?

FreePascal уже умеет работать без линукса?

Он с самого начала писался как замена Turbo Pascal. Есть сборки даже под древние КПК и DOS.

https://www.freepascal.org/download.html

работать без линукса?

Но вообще сидеть за Windows и пытаться изучать программирование — время впустую.

AMD64/Intel 64/x86_64

Windows 64-bit
Linux
Mac OS X/OS X/macOS (and cross-compilers for PowerPC(64)/Mac OS X, iOS & iPhoneSimulator, JVM/Java and JVM/Android).
FreeBSD
Solaris

Т.е., чтобы пользоваться на AMD64 FreePascalем нужно сначала установить мегагигабайты чего-нибудь ненужного?

Ну да, fpc-3.2.2.win32.and.win64.exe 93.9 MB жирновато, но это не 10 гигабайт MS Visual Studio, а в сотню раз меньше. И при этом гораздо удобнее и проще. А как редактор можно взять какой-нибудь порт gvim или на худой конец geanie.

И ещё Linux, systemd и пр…

SystemD ненужон. Можно Alpine Linux поставить если тебе место важно. На гигабайтную флешку влезет и FPC и ОС и редактор и место останется под программы.

SystemD ненужон

А Linux с дистрами что ли нужон?

А Linux с дистрами что ли нужон?

Если ты не хочешь любоваться на синий экран BIOS Setup, нужен. Альтернатив линуксу как бы и нет или они сильно нишевые/экспериментальные (BSD, OpenSolaris, Haiku и тд)

Если гигабайтный дистро может запуститься без постороннего, то 100-мегабайтный FreePsscal тем более сможет

Я думаешь наизусть все его аргументы помню?

Конечно помнишь, ты ж сектант. Собственно, ты и нашел. Давай посмотрим:

С технической точки зрения до введения VLA имя локальной переменной при трансляции в объектный код естественным образом превращалось в константное смещение относительно стекового фрейма. После введения VLA имя локальной переменной может превратиться в выражение произвольной сложности, в том числе такое, промежуточные результаты которого не поместятся в регистрах. Как следствие, Си при наличии ЭТОГО перестаёт быть низкоуровневым языком, т.е. заменителем ассемблера; но Си ни в каком другом качестве не нужен

Как я и думал, технических аргументов там нет - только религиозные. На сях пишут не потому, что это макроассемблер, а потом что на нем можно написать очень быстрый или низкоуровневый по отношению к железу и ОС код. Именно это - главный юзкейс си, а не то, что этот клоун себе там навыдумывал. При этом в подавляющем большинстве случаев тебе вообще не важно, что там нагенерировал компилятор - он всё равно наоптимизирует весь твой код и пережует его независимо от наличия или отсутствия VLA, для того чтобы сделать его более эффективным. Времена, когда ты руками мог написать на сях код с результирующим асмом эффективнее, чем наоптимизировал компилятор, уже давно прошли. Шутка про то, что си является синтаксическим сахаром над ассемблером - именно что шутка.

Но кстати в той же MS Visual C 6.0 не поддерживается C99, так что вот тебе аргумент не от Столярова, а от его противоположности.

Здесь вообще никакого аргумента нет. Хлам от МС вышел в 1998 году, а стандарт C99 был принят в 2000 году.

И я еще раз повторю свой вопрос, который ты проигнорировал:

Скажи вот мне пожалуйста, кем ты работаешь? Тебя научили столяровские опусы хоть чему-то, чтобы ты мог монетизировать эти знания?

Ну?

SystemD ненужон.

Мамкиному админу локалхоста, может, и не нужен. А вот строителям десктопных и серверных систем - очень даже нужен.

А паскалевским хелловордшикам не нужон не только системд

А ты сидишь как дибил и пялишься в задание, не понимая как его решить. Просто не можешь написать код, не можешь составить алгоритм.

Расскажи кстати, какая у тебя среда? Надеюсь нормальный fpc под GNU/Linux, а не какой-нибудь ABC, который вообще не паскаль, просто так называется?

Задание 5.5. Ввести четырехзначное целое число и определить, является ли оно палиндромом (например, числа 6666 и 3223). Для выделения разрядов числа используются операции div и mod.

Program palindrome;
Uses math;
Const base = 10;
Var n, m, a, b, c, d: integer;
Begin
	write('Enter 4-digit whole number: ');
	readln(n);
	if (n < base**3) or (n > base**4) then begin
		writeln('Error: ', n, ' is not a 4-digit number.');
		halt(1)
	end;
	m:=n;
	d:=m mod base;
	m:=m div base;
	c:=m mod base;
	m:=m div base;
	b:=m mod base;
	m:=m div base;
	a:=m mod base;
	m:=m div base;
	if (a=d) and (b=c) then
		writeln(n, ' is a palindrome!')
	else
		writeln(n, ' is not a palindrome, sorry.')
End.

А с этим разобрался? Тут желательно массив и цикл взять, конечно. Интересно @liksys опять скажет, что говнокод?

Задание 5.6. Ввести три числа A, B, C. Если ни одно из чисел не равно нулю, то в переменную K записать среднее арифметическое трех чисел.

Тут наверное тип Real. Только там небольшая засада с точным равенством. И как проверять переменную K? Отладчиком пользоваться? В задании не сказано его вывести.

Задание 5.7. Ввести значение X и, используя график функции, определить значение Y. Требуется заполнить блок-схему алгоритма.

Program piecewise_function;
Uses math;
Var x, y: real;
Begin
	readln(x);
	if x <= -1 then
		y := -2
	else if x <= 2 then
		y := x-1
	else
		y := (x-2)**2 + 1;
	writeln(y:1:4);
End.

Лучше конечно так в данном случае:

Program piecewise_function;
Uses math;

function f(x: real): real;
begin
	if x <= -1 then
		f := -2
	else if x <= 2 then
		f := x-1
	else
		f := (x-2)**2 + 1;
end;

Var x, y: real;
Begin
	readln(x);
	y := f(x);
	writeln(y:1:4);
End.

А с этим разобрался? Тут желательно массив и цикл взять, конечно. Интересно @liksys опять скажет, что говнокод?

Да. Терминальнейший. Проверка на число разрядов выглядит как полная срань. Операции деления по модулю там не нужны. Нахрен не нужны и пляски с каждым разрядом, которые ты выполняешь дальше. И даже циклы тут не нужны, потому что у тебя по условию задачи только четыре разряда. Всё, что тебе нужно - выделить два левых и два правых. Свапнуть любой из них и затем сравнить пару между собой.

int number;

scanf("%d", &number);
if (number < 1000 || number > 9999) {
    puts("Yobu dal");
    return;
}

int left = number / 100;
int right = number % 100;
int mirror_right = (right / 10 + (right % 10) * 10);

if (left == mirror_right) {
    puts("Yes");
} else {
    puts("No");
}

Легко увидеть, что ни обучение по столярову, ни понимание побочных эффектов (они тут ни при чем, но всё же) не помогли тебе не писать говнокод. Что наглядно демонстрирует ценность макулатуры, которую ты сюда раз за разом в новости приносишь.

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

Мне в свое время приходилось говнокодить после индусов - а именно брать их эстетически красивый минимализированный и казалось бы идеальный код, комментить нахрен весь и по быстрому ляпать свое говно на которое смотреть было страшно и на одну красивую сточку индуса приходилось 5 моих. Но по факту на реальных объемах данных мой страшный код отрабатывал за 15 минут а индусский красивый - за сутки не успевал.

Другое дело что сейчас в прикладном программировании не особо напрягаются такими вещами и не сильно вникают как оно там откомпилируется и будет отрабатывать - железо стало сильно мощнее и прощает многое.

посмотреть на скорость и ужор ресурсов

Его 4 операции деления против 8 выше. Остальное - стат.погрешность.

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

К слову, у него еще и проверка входных значений неправильная. Условие (n < base**3) or (n > base**4) не сработает на ввод 10000. И на кой хрен там нужно возведение в степень (у меня в посте описка - я там обозвал это делением) - вообще не понятно.

Проверка на число разрядов выглядит как полная срань.

Ага, и написал точно такую же. Хотя да, надо было n >= base**4, тут я ошибся.

int mirror_right = (right / 10 + (right % 10) * 10);

Молодец, но у меня сразу понятно, как код разбирает число на отдельные цифры, а у тебя надо вникать.

Операции деления по модулю там не нужны.

Ага, и сам же используешь операцию деления по модулю. / % — это что такое по-твоему? Это и есть аналоги паскалевских div и mod.

А вообще забавно, как ты меня ругал за плохо масштабируемую логику проверки условий в стиле, а что если у тебя не три переменных, а четыре или десять. А теперь наоборот, твоя логика привязана конкретно к четырёхзначности и плохо масштабируется, если например нужен будет восьмизначный палиндром.

И на кой хрен там нужно возведение в степень (у меня в посте описка - я там обозвал это делением) - вообще не понятно.

На случай если нужно будет проверить, является ли число палиндромом в какой-то другой системе счисления, например 16-ричной.

$ ./ushakov5.4-palindrome
Enter 4-digit whole number: 0x9F8
2552 is a palindrome!

Вот например по умолчанию десятичная система. А если base сделать не константой можно например перебирать основания и находить числа которые являются палиндромами в n-ричной системе.