res2001

void func(const unsigned char *array, size_t array_length);
...
func(bfr, sizeof(bfr)/sizeof(bfr[0]));

Не знаю, что такое PROGMEM, видимо это какой-то макрос, который навешивает какой-нибудь аттрибут для типа.

STL по сути часть языка, так что в любом учебнике по плюсам будут и основы STL.
Boost - это такая расширенная версия STL, многие новшества перед тем как попасть в стандарт и соответственно в STL тестируются на Boost. Но в Boost содержится много того, чего нет в STL. У Boost своя хорошая документация, изучайте по ней и по примерам.
Любые другие библиотеки изучаются по документации от разработчиков библиотеки. Если документации нет, бывает и такое, - по исходникам.

lololoshka_1991, Если совсем просто, то пиши исходники в кодировке cp866. Кодировка консоли по умолчанию как раз такая в русской винде. Но в этом случае и запускай программу руками из консоли, т.к. тот же MSVS может менять кодировку консоли при запуске программы из него.
Так же кодировка консоли может меняться и командой в самой консоли. Например: chcp 1251
В винде по умолчанию может быть 3 варианта кодировок с поддержкой кириллицы: cp866, cp1251, UTF8.

Что бы сделать программу независимой от кодировки консоли, то придется заморочиться. Готового решения не встречал. По уму надо делать так: пишем исходники в UTF8, в программе узнаем кодировку консоли (WinAPI позволяет это делать), перед выводом весь текст перекодируем в кодировку консоли, после ввода весь ввод перекодируем в UTF8. Внутри программы работаем только с UTF8. Для хранения строк в программе использовать wchar_t, wstring и т.п. Функции перекодирования в WinAPI так же присутствуют.

Кстати в плюсах есть метод std::basic_ios.imbue(), который позволяет задавать кодировку потока. Можно попробовать поиграть с этим. Но вообще менять кодировку консоли из программы - плохо, т.к. пользователь консольной программы может ждать ответ от запускаемой программы в конкретной кодировке. Это широко используется при написании батников и т.п. скриптов. Например большая часть виндовых команд корректно выводит текст не зависимо от того какая кодировка в консоли. Тот же dir, например.

sizeof(chars) в результате дает размер указателя (8 - для x64 систем, 4 - для х32 систем), а не размер строки. Чтоб получить размер строки надо его передать в функцию (str.size()) или вызвать strlen уже внутри.
sizeof(*chars) всегда в результате равен 1, т.к. размер char по стандарту 1 байт.

Вам не нужно 2 цикла. Я так понимаю, вы хотели различать четное и не четное количество символов в строке.
Но если количество элементов четное, то мы должны обработать все элементы массива при этом количество итераций цикла будет strlen(chars)/2. А если количество элементов не четное, то центральный элемент мы пропускаем и количество итераций будет то же strlen(chars)/2, за счет того, что тут используется целочисленное деление и остаток от деления отбрасывается.

В функцию можно передавать ссылку на объект string, а не сырой массив (c_str()). string позволяет обращаться на прямую к каждому символу отдельно с помощью операции индексации (str[i], так же как и сырые массивы). При этом возвращать что-либо из функции не нужно, т.к. вы будете манипулировать непосредственно данными самого объекта и все изменения будут видны в main.

Просто считайте количество открывающих скобок и количество закрывающих. Причем, если на закрывающей скобке количество открывающих <= количества закрывающих, то ее не учитываем (или учитываем в ошибках закрывающих скобок), т.к. нет парной открывающей.
Ошибки по открывающим скобкам будут, если в конце количество открывающих > количества закрывающих, количество ошибок открывающих скобок в этом случае = количество открывающих - количества закрывающих.
Количество правильных скобок == количеству закрывающих (т.к. не правильные закрывающие мы не считаем).

Видимо препод хочет, чтоб программа могла работать с несколькими значениями А и N.
1. Ввод A и N и расчет периметра выносите в отдельную функцию.
2. В main делаете вечный цикл, где спрашиваете пользователя что-нибудь типа "Давай еще посчитаем (1 - да; 0 - нет)". Если пользователь вводит 1, то выполняете функцию из п.1, после ее выполнения снова спрашиваете пользователя. Если пользователь вводит 0 - break из цикла и завершение программы.

cin и cout - это объекты классов потоков ввода и вывода в консоль. Объекты cin и cout объявляются автоматически, т.е. вам не нужно создавать эти объекты, они уже созданы внутри стандартной библиотеки.
Есть в std классы ifstream и ofstream, которые являются потоками ввода/вывода в файлы. Объекты этих классов не создаются автоматически, но вы можете создать эти объекты вручную и указать при создании с каким файлом объект должен работать. Дальше заменяете все cin/cout на объекты классов ifstream/ofstream.

Есть другой вариант. Вообще не менять программу, но при запуске перенаправлять потоки stdin/stdout в файлы, что-то типа такого:
prog.exe <file_input.txt >file_output.txt
В этом случае в программе объекты cin/cout автомтатически начинают использовать file_input.txt для ввода и file_output.txt для вывода.

Потому что при передаче в функцию статического/автоматического массива передается указатель, а не сам массив.
8 - размер указателя на 64-битной платформе.
Размер нужно передавать отдельным параметром, как писал mayton2019

size_type - это обычно typedef из других типов, который разработчик контейнера решил использовать в контейнере. Скорее всего это будет тот же size_t. Для данного конкретного контейнера логично использовать его size_type.
Размер size_t привязан к размеру указателя, т.е. sizeof(void*) == sizeof(size_t).
Как раз это и обеспечивает, то что size_t может индексировать всю возможную память (по байту) для конкретной архитектуры процессора. Размер size_t на х32 - 4 байта, на х64 - 8 байт. Размер указателя, в свою очередь, равен размеру адресной шины процессора.
В общем случае для счетчиков элементов и т.п. вещей всегда используйте size_t. Но если вы точно знаете, что у вас вот в этом конкретном контейнере/массиве не может быть больше n-ого количества элементов (например массив фиксированного размера), то можно использовать тип меньшей разрядности, достаточный для индексации контейнера.
Переменные счетчиков, индексов и т.п. обычно делаются беззнаковыми (size_t - беззнаковый), потому что обычно алгоритмически эти переменные никогда не принимают отрицательных значений. Так зачем терять лишний значащий разряд? Но это не всегда так, в каждом конкретном случае нужно делать свой выбор, универсальных решений нет.
Бывает ли на практике размер контейнера таких размеров которые вмещаются в size_t? В базах данных запросто может быть таблица размером больше, чем помещается в 4 байтовый size_t. Максимальное значение 8 байтового size_t - это ооочень большое число. В практических задачах вряд ли найдется контейнер, вмещающий такое количество объектов (но всегда могут быть исключения). Но итерироваться или считать можно не только объекты в контейнере, можно считать например байты/сектора на диске или пакеты в интернете или контейнер может лежать в распределенной системе хранения размером в экзабайты или больше (сейчас это уже реально).

Между const char * и char const * - разницы нет. Допустимо использовать обе записи.
Но кроме самих данных, на которые указывает указатель, можно делать константным и сам указатель, как написал Adamos.

https://en.cppreference.com/w/cpp/io/ios_base/width

for(int i = 1; i < 11; i+=2)

3.27869 - это 1/0,305. Надо выводить y*0.305 и то же самое для x.

Если программа выполняется под виндой, то:
1. В консоли винды по умолчанию кодировка cp866 (да же не cp1251 и тем более не unicode). Кодировка консоли в винде может быть легко изменена с помощью команды консоли chcp, так что полагаться на то, что в консоли будет всегда одна и та же кодировка не стоит. Когда вы читаете символ с консоли, то он появляется в программе в кодировке консоли.
2. Еще у вас есть кодировка файла исходного кода. Компилятор сам ничего не перекодирует. В какой кодировке написаны ваши константы в исходниках в той они и будут в программе. Когда вы выполняете операцию сравнения, то символ в кодировке файла исходного кода сравнивается с символом в кодировке консоли. Если обе кодировки не совпадают - сравнение будет не удачным, даже если символ один и тот же.
3. Простой вариант - писать исходники в cp866 и не менять кодировку консоли в тестах. Может не работать, если, например, запускаете программу из MSVC - IDE может сама менять кодировку своей отладочной консоли. Лучше тесты запускать вручную в отдельном консольном окне.
4. Правильный вариант - исходники писать в UTF8, символьные и строковые константы писать как wide char (wchar_t, в винде это UTF-16) перед вводом узнать кодировку консоли, перекодировать введенные символы в UTF-16, сравнивать символы в UTF-16. С выводом в консоль - та же история. В WinAPI есть функции перекодировки из многобайтных (cp866/1251, ...) в широкие символы и обратно.

В линуксе сейчас повсеместно консоль в unicode, соответственно и читать вам надо unicode и сравнивать с unicode.