mayton2019

Серая область? Тут наверное 2 цикла надо.

Либо обходить левый прямоугольник элементов и уже 2 линиями ограничить. Одна линия
y = x и вторая - перевернутая y = -x и сдвинутая на вниз на SIZE. Тоесть y = -x + SIZE

Вместо 4 сторон света лучше брать единичный вектор на плоскости (x,y). Тогда формулы удара о борт получаются тривиальные. Просто где то меняется знак с плюса на минус.

Никакой это не JSON.

А по задаче. Может лучше не массив а vector?

Есть такая популярная задача. Называется СУММА ПРОПИСЬЮ. Ее решают тыщу раз и для каждого языка уже написано много кода. Эти типа 1.25 == "Один рубль двадцать пять копеек".

Поищи исходники - там будет половина решения твоих окончаний.

Не совсем ясно , чего хотел преподаватель.

Но для сортировки больших массивов ( которые много крат превышают оперативку ) используется сортировка слиянием - merge sort.

ООП предполагает что в задаче есть некая сущность. Объект. И у него должны быть методы. Что происходит в данной задаче? Пользователь вводит x, потом размер массива. Потом сам массив. После этого делаются какие-то манипуляции с массивом. И после этого массив распечатывается на экран. Где тут ООП? Я не знаю! Я чорт возьми не пойму где здесь ООП.

Вобщем скажи своему преподавателю что здесь нет смысла вводить ООП. Код достаточно хорош и концептуален в том виде как он записан. И надо не забывать про принципы KISS/YAGNI которые никто не отменял.

Проверить что внутри строки - нечто похожее на число - это одна задача. Ее можно сделать регуляркой. А сделать кастинг его к int/long/float/double - это другая задача.

Некоторые числа бывают слишком большие и не влезают даже в long (64) и некоторые вещественные могут иметь множитель 10 в степени 310 и это не лезет в double. Мне сложно такое представить но теоретически пользователь может такое ввести.

Какую задачу решает автор? Что будет дальше происходить с введенным числом?

Проще всего с этим работать на линуксе. Эта операционка отображает все диски на блочные устройства /dev/* и позволяет с ними работать просто как с очень большими файлами.

Разумеется права суперпользователя тебе пригодятся. Механизмы безопасности никто не отменял. В Windows тоже есть аналог для таких устройств.

Возникла проблема - требуется писать программы быстрыми, чем быстрее - тем лучше.

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

Кстати я тебе предлагаю как всегда пойти от формализма - просто перечислить фичи которые ты собираешся реализовать в виде документа. И я думаю где-то на 500-й фиче ты забросишь это дело.

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

Яркий пример - создатели своих DBMS. Тыщи их. Но никто не в состоянии довести разработку даже до альфа-версии. А уж о том чтобы ее показать на презентации - вообще и речи нет.

И ещё хотелось бы понять, почему каждый такой указатель является константой?

Это - тяжелое наследие старых систем. В данном примере ты разбираешся с ASCIIZ-строками. С массивами символов которые завершаются нулем. Такая организация позволяет хранить строки компактно. Маркер const защищает строку от случайного изменения. И правильно делает. От этого больше проблем. Тот формат и тот способ хранения строки вообще не предполагает активных изменений. Особенно с размером. Максимум что можно делать - только читать.

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

Для С++ более удобной строкой является std::string. Его использовать приятнее. И с размерами там веселее.
В легаси исходниках можно встретить причудливые CString (MFC), TString (Borland). Это все разные реализации строк.

Для Qt есть тоже свой тип строк.

Есть понятие partially defined функция. Это работает в Haskell, Scala. Результатом такого например
применения будет просто онлайн компилляция новой функции с меньшим числом аргументов.

plusInt(_, b)

Но для С++ тем более в данном контексте использования тебе проще сделать просто еще одну функцию.
Кстати обращаю твоё внимание на то что функции обычно возвращают занчения. А побочный эффект
такой как cout - лучше просто вызвать отдельно.

Мотивация станет более ясна когда будешь такой код тестировать. Всегда проще проверить результат чем анализировать потоки вывода.

Вот эти вот символы (191, 192, 196, 217, 218). лучше не использовать. Берите сразу Unicode в разделе BoxDrawing https://www.w3.org/TR/xml-entity-names/025.html

Что за душный душнило этот ваш преподаватель? Расскажите ему уже что на дворе 2022 год.

Тут зубчатый массив не нужен. Можно и одномерным прекрасно обойтись.

for (int i = 0; i < heightGameField; i++)
      gameField[i] = new int[widthGameField];

Тут всё поле можно не перерисовывать. Змейка это вообще - эконом-игра. В ней можно обновлять
только голову змеи и хвост. И те места на карте где выпадает еда.

for (int i = 0; i < heightGameField; i++)
    {
      for (int j = 0; j < widthGameField; j++)
      {
        switch (gameField[i][j])

Я не кодил на SFML/Graphics.hpp. Моя С++ библиотека когда-то называлась Borland C++ BGI. Но там мне хватало
вот такого частичного обновления экрана.

Зачем этот метод? Он безсмысленный.

int** getGameField(void)
  {
    return gameField;
  }

Он взламывает инкапсуляцию класса. После него всё ООП должно пойди по звезде. Вобщем можешь его даже не делать.

Вообще в данной игровой логике ООП не очень нужно. Ну тоесть я не вижу ниакой мотивации к ООП. Между змеей и локацией нет никакой секретности. Короче пиши набор функций и не парься. Если SFML жостко не требует ООП
то и не беспокойся об этом. Шаблонизация тут как я понимаю важнее чем ООП. А об этом еще великий Степанов
говорил.

Макросы - это рудимент. Пережиток прошлого. Во многих современных языках их нету принципиально. Хотя в C/C++ они выполняют функцию такого себе прозрачного преобразования исходника перед сборкой. С помощью М. можно например принять решение о платформенной компилляции WIN32/LINUX/MAC. Напихать ассемблера с вариантами.

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

Вообще с помощью М. можно делать разные веселые вещи например переименовать TRUE в FALSE. Такая себе тема троллинга на собеседовании.

Вот это предложение - хорошее.

compiled{
   if(something){
   }
}

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

Почитайте еще спецификацию ZigLang. Там были реализованы какие-то фичи с compile time.

Мне вспоминается мульсериал Футурама. Там когда профессора спросили - на каком принципе летает его космическая ракета - он ответил что она на самом деле не летает. Она стоит на месте. Просто она двигает вокруг себя всю вселенную.

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

Тут нужно акцент не на С++ делать а на то что разработка ведется для Windows. Тегнул топик.

Вот ссылочка на DLL-linked ordering. Может будет полезна

https://docs.microsoft.com/en-us/windows/win32/dll...