Mercury13

И снова приходится отвечать самому.

#pragma GCC optimize("O1")
#pragma GCC optimize("no-lto")

3 тоже есть, так что правильный ответ 3. Ошибка тройная.

for(size_t z = 0; z < b.length(); z++){
        if(a.find(b[z]) != std::string::npos){

1. Индексы строк в STL беззнаковые, и компилятор может ругаться на сравнение знакового целого и беззнакового.
2. На что тут 4, если есть s.length()
3. Знак «не найдено» — std::string::npos.

Нет, ваше решение неуниверсально и ваша ошибка — не заэкранировать идентификатор E-mail.
Попробуйте [E-mail].
(Часто используется экранирование `E-mail`, но в SqLite оно не катит, это специфика MySQL.)

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

Лучше скажу, что НЕ пишется на Си++.
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. Программа не модульная, нет нужды в хедере.