Adamos

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

Даже в задании написано про перевыделение памяти - какого, собственно?

Чтобы создать на движке Unreal, например, крестики-нолики - арифметики будет достаточно.

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

Вообще-то в инструкции /configure --with-cards=hda-intel - но дело, конечно, не в этом.
Не знаю, какими ключами ему объяснить, что предупреждения не нужно трактовать, как ошибки.
Но вам же даны файл и строчка, в которой проблема. Замените текст на "Compiled today for kernel %s" например - предупреждение и исчезнет...

Вы вес .NET библиотек смотрели? И их поддержку в страшно устаревшей, но по-прежнему распространенной в реальной жизни ХР?
Вопрос звучит так, как будто вы сами не понимаете, что вам нужно. Мешать кроссплатформенную библиотеку с дотНетом - значит потерять достоинства и того, и другого. А главное - ЗАЧЕМ?!

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

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

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

Вообще такое приведение - это наследие С, и в С++ - моветон.
Если же заменить его dynamic_cast и проверять результат на NULL, могут вскрыться всякие нюансы.
У меня, например, были проблемы с приведением родительского окна к тому классу, которым оно должно было быть. Исследование показало, что в версии библиотеки под одну из платформ дочерний класс заворачивался еше в одного родителя, и такое приведение вызывало сегфолт...

class MyMatrix {
public:
  MyMatrix(size_t width, size_t height);
  ~MyMatrix();
  size_t getWidth();
  size_t getHeght();
  MyType get(size_t x, size_t y);
  void set(size_t x, size_t y, MyType value);
private:
  size_t _width, _height;
  MyType* _memory;
};

Если вы знаете С++, то написать реализацию у вас займет что-то в районе получаса...

Полиморфизм сам по себе влияет на уровне погрешности.
Архитектура без него может оказаться настолько менее оптимальной, что будет тормозить куда сильнее.
По моему опыту оптимизации вычислительной работы программы по скорости, главная проблема - это считать именно то, что нужно. Если просчитываются варианты, то их отсеивание на как можно более ранней стадии - это такой козырь, который бьет любые другие оптимизации.
Вторая - работа с памятью. Создание массива объектов во вложенном цикле в рекурсивной функции легко уложит на бок весь top500 %) Не говоря уже о том, что вероятность течи прямо пропорциональна количеству динамически созданных объектов.
А полиморфизм... ну, если у вас реально полиморфная функция будет вызываться миллион раз в секунду, вы, наверное, почувствуете падение производительности...

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

Если как в JS, так и храните, как в JS - строками, которые приводятся к нужному непосредственно перед использованием...

Просто напомню, что в этом веке файлы программы уже не пишут свои файлы туда же, где находится программа.
Потому что, например, в Виндах программе положено лежать в Program Files, а пользователь туда ничего писать не имеет прав. В других системах та же логика.
У вас, возможно, просто старая методичка, но лучше сразу не учиться плохому.
Есть пользовательские папки специально для этих целей, и у кроссплатформенных библиотек есть стандартные функции для получения пути к ним. Потому что реальный путь зависит от версии ОС и имени пользователя.

Как это сделать только под винды - можно посмотреть, например, тут