Евгений Шатунов

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

Память для динамического массива выделяется в динамической памяти (в куче) (new[]). Когда массив становится не нужным память должна быть освобождена (delete[]), иначе произойдет утечка памяти.

В связи с вышеизложенными принципиальными отличиями, есть несколько следствий:
1. Имя статического массива это не указатель. Это можно понять например сравнив, что возвращает sizeoff() для статического массива и для динамического. Хотя в некоторых ситуациях компилятор ведет себя так, как будто имя статического массива это указатель, например: можно передать имя статического массива в функцию, принимающую указатель.
2. У динамического массива нет имени. Операция new[] возвращает указатель. Имя есть у указателя.
3. Внимание! Оба варианта массивов имеют фиксированный размер. Изменять его нельзя!
То что в std::vector вы можете укладывать кучу элементов постепенно, не указывая нигде предварительного размера является следствием того, что std::vector скрывает от вас всю работу, которую он при этом делает. При добавлении нового элемента, для которого нет места, он выделяет память для нового массива большего размера, копирует старый массив в новый, удаляет старый массив, добавляет новый элемент. Если идет интенсивная работа с push_back(), то это может ОООЧЕНЬ дорого стоить. std::vector - это удобно, но необходимо всегда помнить, за счет чего достигается это удобство. std::vector - это не динамический массив - это обертка над ним для более удобной работы с динамическим массивом.

В языке Си (C99) есть такая штука как Variable Length Array (VLA) - это статический массив с изменяемым размером. Т.е. вы можете, например, в функции объявить int arr[N], где N будет передаваться в функцию как параметр.
В стандарте С++ VLA нет! Но, например, тот же gcc с опциями по умолчанию разрешает его использования в С++ проектах. С опциями, заставляющими gcc более жестко следовать стандарту, он может запрещать использовать VLA в С++ проектах. Но не рассчитывайте, что все компиляторы будут так делать. Например микрософтовский компилятор в принципе не умеет в VLA (хотя я уже пару лет не проверял это).
VLA может показаться классной штукой.
Но, например, в ядре Линукс в свое время проводили целую компанию по выпиливанию VLA из исходников. Торвальдс высказывался негативно про VLA. Все это при желании можно нагуглить.
Стоит помнить, что размер стека ограничен, а VLA то же выделяется на стеке. Кроме того выделение памяти для обычного статического массива это просто увеличение счетчика стека на константу (и все, одна операция сложения регистра с константой, а компилятор одной операцией выделяет память для всех переменных в текущей области видимости). С VLA все сложнее с выделением и удалением. Так же sizeof() для обычного статического массива это операция времени компиляции (при выполнении будет уже заранее известная константа), для VLA - это полноценный вызов функции.

Компилятор же тычет носом в строчки, где проблема.
А проблема в том, что программист небрежен и не пользуется IDE, которая ткнула бы его носом более предметно - где он забыл фигурную скобку, где кавычки, а где - упомянуть класс, метод которого вызывает. Вот и все три ужасные ошибки.

Для чего нужен 0, если теоретически единиц достаточно для определения границ символа?

Для удобства. По стартовому байту последовательности (кодирующей символ) можно определить ее длину в байтах: сколько единичных страших битов, столько и байт в последовательности. Ноль обозначает конец серии единичных старших бит. Если бы не было этого нуля, невозможно было бы сказать, сколько старших бит установлено в стартовом байте (пришлось бы считывать байты дальше до тех пор, пока не встретится следующий стартовый байт или однобайтовый символ).
Т.е. допустим, вы видите такую последовательность (второй байт просто для иллюстрации, внимание на первый):
11110001 10xxxxxx
Если нуля бы не было, то это два байта, кодирующие символ Юникода 110001xxxxxx? Или это три байта, кодирующие символ 1001xxxxxx...? Или четыре, символ 001xxxxxx...?
Не получится понять, не считав до начала следующего символа.

Си можно начать изучать с книги "Язык программирования Си" Кернигана и Ритчи. Или с "Head First C" (я начинал с неё). Потом можно почитать про новые фичи стандарта c11.
Если вы хотите низкоуровневым программированием заниматься, то для начала нужно прочитать "Архитектура Компьютера" Таненбаума. Ещё есть очень хорошая книга "Цифровая схемотехника и архитектура компьютера" от Сары и Дэвида Харрис.
Потом читать спецификации на железки, под которые вы хотите писать код.

Почему вы в функции с переменным количеством аргументов не используете стандартный механизм для работы с аргументами в подобных функциях (#include <cstdarg>)?

Поставьте отладочный вывод в цикл, где выведите значение count, а заодно и *ptr и comp. То же самое можно быстро посмотреть в отладчике затратив минуты 3 на все. Выводите значение floatов с большим количество знаков после запятой (10-15).
Вы будете удивлены тому, что во float 3.0 это не обязательно равно 3, ну и т.д. То же самое относится к любым типам с плавающей точкой.
Передавайте первым аргументом uint32_t, вторым и следующим float. Тогда все будет нормально. Код, конечно, придется немного переделать.

Если вы хотите писать на си, то посмотрите в сторону GTK
Или в сторону Qt (C++)

Советую использовать всётаки C++, тк с ним хоть немного меньше кода придётся писать, и он будет понятнее

Хорошо написанный, и скомпилированный в -o3 код на си, как правило, будет быстрее и эффективнее аналогичного кода на питоне.
В вашем случае неизвестно, почему вы могли получить такие результаты (даже не сказано, какие)

А какой используется интерпретатор?
А как был скомпилирован код на си?
На одном и том же железе происходил запуск? Условия равны?
Чем print на питоне отличается от сишного printf?
Как вообще происходил замер? Было ли учтено время на запуск интерпретатора?
Сколько было замеров? Может в случае с си был аномально медленный прогон?

UPD: Короче хз, как вы там меряли, но вот мой вариант
Для C я использовал Tiny C compiler, чтобы дать питону фору (будет учитываться время на компиляцию), да и оптимизации тут будут не такие дикие, как в GCC
Чтобы не тестировать скорость вывода на экран - вывод я перенаправил в /dev/null (Хз что это за заклинание такое, но я его нашёл на SO)
Запускал всё на WSL2 по одному разу, но в принципе результат очень даже стабилен.
Вот результат:

vabka@DESKTOP-7AFIA69:~/repos$ time (python3 test.py) 2>&1 1>/dev/null

real    0m0.381s
user    0m0.359s
sys     0m0.016s
vabka@DESKTOP-7AFIA69:~/repos$ time (tcc -run test.c) 2>&1 1>/dev/null

real    0m0.081s
user    0m0.047s
sys     0m0.031s
vabka@DESKTOP-7AFIA69:~/repos$ cat test.c
#include <stdio.h>

int main() {
  int i = 0;
  while(i < 1000000) {
    printf("%d\n", i);
    i++;
  }
  return 0;
}
vabka@DESKTOP-7AFIA69:~/repos$ cat test.py
i = 0
while i < 1000000:
  print(i)
  i += 1

vabka@DESKTOP-7AFIA69:~/repos$

Питон получился в 4 раза медленнее.

Вот ещё результат без /dev/null:
Для C:

real    0m58.757s
user    0m1.094s
sys     0m11.078s

Для питона:

real    1m1.762s
user    0m2.953s
sys     0m13.594s

Результат тоже хуже, но тут очень много времени тратится на вывод в консоль, по тому разница почти не видна.

Зачем это
r[j] = '\0';
в цикле? Вынесите из цикла.
Путаницу в куче я вижу только в том смысле, что памяти выделяется больше, чем нужно. Можно этот момент подрихтовать.
Сам цикл я бы реализовал немного по другому - так чтобы в одной итерации цикла добавлялись сразу 2 символа из строки и один symbol. В этом случае нужно будет еще обработать оставшийся хвост, если количество символов не четное.

Добавлено: Проглядел отсутствие освобождения памяти. Оно необходимо, конечно.

Для того, чтобы посмотреть вывод программы, ее вовсе не надо останавливать - достаточно настроить IDE так, чтобы она не закрывала терминал после завершения программы.

Если сильно хочется, можно использовать вот такой код:

#include <ios>      // Required for streamsize
#include <iostream>
#include <istream>
#include <limits>   // Required for numeric_limits

void myflush ( std::istream& in )
{
  in.ignore ( std::numeric_limits<std::streamsize>::max(), '\n' ); // опустошаем все что есть в буфере
  in.clear();
}

void mypause() 
{ 
  std::cout<<"Press [Enter] to continue . . ."; // собственно, пауза
  std::cin.get();
}

Источник
Использование же system("pause") - костыль, к использованию не годится никогда.

type_traits - это имя параметра шаблона, который задан в родительском классе streambuf.

type_traits::eof() - возвращает код конца файла, для текущего параметра шаблона.

Вся эта шаблонная магия взялась для того, чтобы можно было читать из файла или char, или wchar, или еще черт знает что, в зависимости от кодировки. Раз читаемые символы могут быть какими угодно, то и код конца файла нужен свой собственный для разных типов символов. Поэтому eof() является частью type_traits в streambuf.