Mercury13

На Си++ пишутся сложные быстрые программы. Этим всё сказано.
Игры, настольные программы, всякие там серверы…

Лучше скажу, что НЕ пишется на Си++.
1. Софт, сильно абстрагированный от машины, изменяемый пользователем и/или призванный запускаться где угодно: программы для iOS, Android, веба, высокоуровневые части некоторых игр…
2. Компактные программы (например, для микроконтроллеров). Сейчас — вотчина Си и его уменьшенных библиотек.
3. Простые программы, для которых быстродействие и установка дополнительного фреймворка — не проблема: 2D-игры наподобие Braid или Fez, графический редактор Paint.net…

Не будем встревать в холивар «должен ли указатель быть объектом». Примем, что указатель — простейший тип, ради совместимости и эффективности.
К простейшему типу инкапсуляция и наследование неприменимы.
А вот для полиморфизма указатели очень нужны. Динамический полиморфизм — это когда под одним фасадом могут оказаться разные объекты.
1. По копии их передавать невозможно, только по указателю/ссылке.
2. Их нельзя уничтожать под одну гребёнку. А значит, если мы их передаём в чьё-то другое владение, надо удостовериться, что они созданы в «куче» и у «фасада» есть виртуальный деструктор.

Есть ещё два принципа ООП — абстракция и принцип Лисков. Первый имеет отношение к указателям постольку, поскольку есть полиморфизм. Второй — гугли «ковариантные/контравариантные указатели».

1. Перед нами серьёзный проект: есть и сеть, и подкачка, и поиск путей. Если вы будете писать платформер с нуля, вероятно, «лишние» компоненты вы писать не будете.
2. Это компоненты, а не классы. Структура классов в геймплее будет более густая, а в рендеринге и физике — менее.
Например, пишем 2D-рендеринг. Я бы делал Renderer, Tileset, TileLayer, Sprite, Particle…

В зависимости от желания и целей, лучше воспользуйтесь чужим движком или напишите свой простенький. Куча вопросов отпадёт.

Нет, так нельзя. И вообще, эти части модели вызывает элемент управления (например, QTreeView). Тем чаще, чем активнее мы работаем с данными.

Как я понял, вы столкнулись с ситуацией: доступ к данным медленный. Значит, надо наладить кэш, чтобы rowCount, parent, index и прочие в большинстве случаев исполнялись мгновенно.

Хорошо, задача номер два: где-то в дебрях второго потока идёт долгое обновление модели, а мы хотим её по частям отображать. Это дело сложное, и универсального ответа нет.

Начнём с того, что синхронизировать поток и UI удобнее всего через сигналы-слоты-emit с типом соединения Qt::QueuedConnection (BlockedQueuedConnection, думаю, многовато будет). У слота будет один параметр: сколько элементов уже подгрузили.

Для каждого узла, чьих сыновей мы будет подгружать, указываем дополнительное поле: сколько элементов видно из элемента управления. Все сложные структуры данных закрываем мьютексом. Поскольку дело это сложное, для тех объектов, чья ёмкость ограничена и невелика, лучше этого не делать — например, если у нас группы-альбомы-песни, можно делать это только для корневого элемента: даже у продуктивных групп вроде «битлов» элементов не так много.

В слоте производим такую фишку: rowsAboutToBeInserted, изменяем наше дополнительное поле, rowsInserted. И так для всех элементов, у кого добавилось потомства.

Это испорченная память, где-то ошибка в управлении памятью (например, запись за границами массива).
UPD. Ваша ошибка: в составе std::string есть внутренние неконтролируемые поля, и его нельзя побайтово сохранять в файл. Такими неконтролируемыми полями могут быть указатели, кэши-ускорители и многое другое. Вообще std::string состоит из указателя или двух, и отсюда следуют две вещи. 1) При сохранении в файл не попадут строковые данные, попадёт только указатель. К тому же в Windows нет хорошего 16-ричного просмотрщика, а без него при работе с файлами как без рук (по крайней мере начинающему, я давно обхожусь). 2) Как только вы этот указатель загрузите, std::string портится, и на деструкторе может случиться что угодно.

Вам надо самим придумать формат файла и реализовать загрузку/сохранение, используя length(), data() и front().

Важное правило: ткни в любой байт дампа вашего файла — вы должны сказать, что он значит. Из-за сложности формата это может быть сложно. Байт может быть неиспользуемым или оставленным для совместимости, но какое-то значение должно быть. Если формат многоуровневый, надо сказать назначение на всех уровнях: например, «это значение атрибута XML» на уровне XML и «это имя студента» на прикладном уровне.

Исключение: если есть объект-«чёрный ящик», который написан не нами и сериализуется гарантированно корректно, достаточно сказать: «это часть чёрного ящика». (Сериализуется — это переводится в цепочку байтов, например, файл или сетевой поток.)

Что ещё пока вижу (но это не причина ошибки).
1.

unsigned short int *exam_t = new unsigned short int[5];

Нет нужды new, невелик массив. Хватает локального массива на стеке. Аналогично остальные два new.
2. Нет нужды давать clear/close. Это фишка Си++, автоматически сработает деструктор.
3. Не называйте переменную flag, называйте wasFound (или что она реально значит).
4. sizeof(&student_r) только чудом совпадает с sizeof(student_r).
5. Не надо писать flag == false, надо !flag.
6. Функция del_reversive делает излишнюю работу и переставляет студентов, к тому же есть стандартный алгоритм remove_if.
7. while (!flag) в del_rev бессмысленно.
8. Вы же работаете со string’ами — зачем вводить информацию в буфер ограниченной длины?
9. Программа не модульная, нет нужды в хедере.

Незыблемых правил два.
1. В CPP первым — свой хедер. Это даёт уверенность, что в хедере нет недостающих включений.
2. Избегать циклической зависимости по интерфейсам. Делить программу на слои и не включать ничего из верхних слоёв.

Если уж второе не получилось — есть три решения, каждое из которых решает свою задачу.
1. Forward declaration, полумера против сильной связанности классов.

// Хедер 1
class Master;

class Slave {
  Master* master;
}

// Хедер 2
class Master {
  Slave slave;
}

2. Разорвать порочный круг интерфейсом.

// Хедер 1
class Master {  // interface
public:
  virtual void enumSlaves(const EnumSlavesCallback& v) = 0;
  virtual ~Master() = default; 
}

class Slave {
  Master* master;
}

// Хедер 2
class MyMaster :  public Master {
public:
  Slave slave;
  void enumSlaves(const EnumSlavesCallback& v) override {}
}

3. Вынести общие типы/функции в отдельный хедер под названием someDefines.h или someUtils.h.

1. Ошибка в вызове ReadFile. Причём я говорил про эту ошибку.

DWORD nRead;
 isSucceed = ReadFile(myfile, buffer, 10, &nRead, NULL);

А также.
2. Файл открывать только для чтения.
3. Проверить myFile на корректность.
4. Читаем 10 байтов, пишем 100?

Ваши ошибки.

1. Это разные дескрипторы.
FindFirstFile даёт дескриптор поиска файлов.
А ReadFile требует дескриптор файла, который можно получить через CreateFile.

2. Второй параметр FindFirstFile не может быть NULL. Это указатель на WIN32_FILE_DATA, в которую функция и будет кидать информацию о найденных файлах.

3. Если вы не ищете по маске и точно хотите открыть файл, на что вам FindFirstFile? Орудуйте сразу CreateFile.

4. Вы подключили пару излишних хедеров.

5. Не советую вместо нулевого указателя NULL писать 0.

6. В ReadFile два последних параметра не могут одновременно быть NULL: первый — для синхронного чтения, второй — для асинхронного.

В общем, «курите маны». Благо, у M$ они хорошие.