1. Предыстория появления struct
Когда вы только начинаете, легко думать так: “Ну подумаешь, у задачи есть id и title, я заведу две переменные — и готово”. Но как только задач становится две, три, десять — вы внезапно понимаете, что у вас не “список задач”, а “список наборов переменных”, которые можно легко перепутать и сломать. struct нужен, чтобы связать данные, которые логически образуют одно целое, под одним именем типа.
Представим, что мы хотим хранить одну задачу для будущего мини‑приложения “список дел” (мы будем развивать его дальше в следующих лекциях дня). Без struct часто получается что-то вроде:
int id1 = 1;
std::string title1 = "Buy milk";
int id2 = 2;
std::string title2 = "Pay rent";
Пока это выглядит терпимо… но только пока задач две. Потом появится id3/title3, затем “сделано ли” (done1/done2/…), затем “дата создания”, и вы начнёте подозревать, что код как-то слишком быстро начал напоминать бухгалтерию в Excel.
С struct мы говорим компилятору: “вот сущность Task, у неё есть поля id, title, …, и это одно целое”. Тогда можно хранить Task t;, можно хранить std::vector<Task> tasks;, можно передавать Task в функции и не разрывать сущность на части.
2. Базовый синтаксис и работа с полями
Объявление struct и обязательная ;
Синтаксис struct очень простой, но у него есть одна классическая ловушка: после закрывающей фигурной скобки нужно поставить точку с запятой. Это выглядит чуть “нелогично” (мол, “я же уже закрыл блок!”), но таков контракт языка: объявление типа — это инструкция компилятору, и она заканчивается ;.
Минимальное объявление модели Task:
#include <string>
struct Task {
int id;
std::string title;
};
Обратите внимание на две идеи.
Первая идея: внутри struct мы перечисляем поля (их ещё называют members). По сути это обычные переменные, только “живущие” внутри типа.
Вторая идея: Task — это теперь имя типа, как int или std::string. Значит, можно писать: Task t;.
И да, вот это ; после } — не декоративная деталь. Если вы его забудете, компилятор очень честно скажет “expected ; …” и будет прав.
Доступ к полям через точку: obj.field
Когда у нас есть объект структуры, доступ к его полям делается через оператор .. В реальном коде это один из самых часто используемых операторов вообще: вы будете писать task.id, task.title, user.name, order.total, и так далее. Это выглядит почти как “имя.свойство” в обычном языке — и это одна из причин, почему модель данных резко повышает читаемость.
Давайте создадим одну задачу и выведем её поля:
#include <iostream>
#include <string>
struct Task {
int id;
std::string title;
};
int main() {
Task t{1, "Buy milk"};
std::cout << t.id << "\n"; // 1
std::cout << t.title << "\n"; // Buy milk
}
Здесь важно не только чтение, но и изменение:
#include <string>
struct Task {
int id;
std::string title;
};
int main() {
Task t{1, "Buy milk"};
t.title = "Buy oat milk"; // меняем поле
}
То есть t.title — это не “копия значения”, а именно поле внутри t. Мы обращаемся к нему и можем менять (если объект не const).
Агрегатная инициализация {...} и порядок полей
Когда вы пишете Task t{1, "Buy milk"};, вы используете очень удобную штуку: агрегатную инициализацию. В стандарте C++ фигурные скобки такого вида называются braced-init-list — буквально “список инициализации в фигурных скобках”.
Главная идея простая: вы перечисляете значения для полей, и компилятор раскладывает их по полям структуры. Но есть “цена удобства”: значения идут строго по порядку объявления полей.
Пусть Task выглядит так:
#include <string>
struct Task {
int id;
std::string title;
};
Тогда:
Task t{1, "Buy milk"};
означает “id = 1, title = "Buy milk"”.
Если вы перепутаете порядок, компилятор может ругнуться (или ругнётся не так, как вы ожидали). Например:
Task t{"Buy milk", 1}; // ошибка компиляции: типы не совпадают
В этом случае ошибка даже полезная: типы разные, и компилятор не даст вам случайно “поменять местами”.
Но иногда типы совпадают — и тогда начинается тихий ужас. Например, если у вас два int:
#include <string>
struct Task {
int id;
int priority;
std::string title;
};
То запись Task t{10, 1, "Buy milk"}; и Task t{1, 10, "Buy milk"}; оба варианта валидны, но смысл разный. Поэтому при проектировании структур полезно располагать поля так, чтобы порядок был “естественный”: сначала идентификатор, потом основное имя/текст, потом дополнительные детали.
Значения полей по умолчанию
Когда вы создаёте много объектов, часто повторяются одни и те же значения. Например, “задача по умолчанию не выполнена”. Писать каждый раз false быстро надоедает и ещё быстрее начинает давать ошибки (в одном месте забыли, в другом перепутали).
В struct можно задать значение поля по умолчанию прямо в объявлении поля. Это называется default member initializer (“инициализатор поля по умолчанию”).
Добавим в Task флаг done:
#include <string>
struct Task {
int id;
std::string title;
bool done = false; // по умолчанию задача НЕ выполнена
};
Теперь можно создавать задачу так:
#include <iostream>
#include <string>
struct Task {
int id;
std::string title;
bool done = false;
};
int main() {
Task a{1, "Buy milk"}; // done = false
Task b{2, "Pay rent", true}; // done = true
std::cout << a.done << "\n"; // 0
std::cout << b.done << "\n"; // 1
}
Обратите внимание на баланс: значения по умолчанию должны быть “скучными и безопасными”. Если вы поставите по умолчанию что-нибудь “хитрое”, то отладка потом будет как квест “почему оно само так решило”.
struct и функции: передаём модель целиком
С появлением структур у вас появляется очень приятная возможность: функции начинают принимать “сущности”, а не набор разрозненных параметров. Код становится более читаемым: вместо PrintTask(id, title, done) у вас будет PrintTask(task).
При этом мы помним правило из прошлых дней: большие объекты лучше не копировать без необходимости. Поэтому для чтения мы обычно передаём const T&.
Сделаем функцию печати одной задачи (пока без красивого форматирования — его мы будем централизовать позже):
#include <iostream>
#include <string>
struct Task {
int id;
std::string title;
bool done = false;
};
void PrintTask(const Task& t) {
std::cout << t.id << ": " << t.title << " (done=" << t.done << ")\n";
}
И используем:
#include <iostream>
#include <string>
struct Task {
int id;
std::string title;
bool done = false;
};
void PrintTask(const Task& t) {
std::cout << t.id << ": " << t.title << " (done=" << t.done << ")\n";
}
int main() {
Task t{1, "Buy milk"};
PrintTask(t); // 1: Buy milk (done=0)
}
Заметьте: PrintTask — “только читает”. Это хорошая привычка: если функция называется Print..., странно, если она вдруг что-то меняет.
3. Мини‑приложение TaskTracker и взгляд на модель
Практический пример: заготовка “TaskTracker”
Чтобы практика не была набором разрозненных кусочков, начнём собирать основу приложения, которое мы будем развивать дальше по дню. Сегодня наша цель скромная: научиться описывать задачу как модель данных и уверенно создавать объекты. Мы пока не делаем полноценный менеджер задач, не пишем сложный ввод и не реализуем операции поиска/удаления — это будет в следующих лекциях дня.
Сначала оформим “фабрику” создания задачи: функция, которая создаёт Task из понятных аргументов и возвращает готовый объект. Здесь снова помогает агрегатная инициализация.
#include <string>
struct Task {
int id;
std::string title;
bool done = false;
};
Task MakeTask(int id, const std::string& title) {
return Task{id, title}; // done возьмётся из значения по умолчанию
}
Теперь main() может выглядеть так (да, мы уже умеем std::vector, но используем его максимально мягко — просто чтобы увидеть пользу модели):
#include <iostream>
#include <string>
#include <vector>
struct Task {
int id;
std::string title;
bool done = false;
};
Task MakeTask(int id, const std::string& title) {
return Task{id, title};
}
void PrintTask(const Task& t) {
std::cout << t.id << ": " << t.title << " (done=" << t.done << ")\n";
}
int main() {
std::vector<Task> tasks;
tasks.push_back(MakeTask(1, "Buy milk"));
tasks.push_back(MakeTask(2, "Pay rent"));
for (const Task& t : tasks) {
PrintTask(t);
}
}
Вывод будет примерно такой:
1: Buy milk (done=0)
2: Pay rent (done=0)
И вот здесь становится видно главное: vector хранит “много задач”, и каждая задача — цельный объект. У нас нет параллельных массивов ids[], titles[], dones[], которые надо держать в синхронном состоянии. Мы не играем в “убери элемент из titles и не забудь убрать из ids”. Мы просто работаем с задачами.
Как думать о struct как о модели
Когда мы говорим “модель”, это не про какие-то “ООП‑мантры”, а про очень практичный смысл: struct описывает одну сущность вашей предметной области. Важно, чтобы поля были понятными, имена были говорящими, а сама структура не превращалась в “универсальный мешок всего”.
Небольшая схема того, что происходит в голове у программы, часто выглядит так:
flowchart TD
A["Пользовательская сущность
например: задача"] --> B["Модель данных: struct Task"]
B --> C["Поля: id, title, done"]
C --> D["Объекты: Task{...}"]
D --> E["Коллекция: vector<Task> (много задач)"]
И ещё одна полезная “памятка” в виде таблицы. Она помогает отличать “одну задачу” от “набор переменных”:
| Подход | Как выглядит | Что легко сломать |
|---|---|---|
| Россыпь переменных | |
легко перепутать “пары” и забыть обновить одну из частей |
|
|
порядок полей в |
| Много задач | |
ошибки меньше: коллекция хранит цельные объекты |
9. Типичные ошибки
Ошибка №1: забыли ; после объявления struct.
Это тот самый “ритуальный баг”, который хотя бы раз ловят все. Причина в том, что объявление типа — это тоже “инструкция” и она заканчивается точкой с запятой. Лечится просто: увидели } после struct — мысленно спрашиваете себя “а где ;?”. Через пару дней это станет автоматическим рефлексом.
Ошибка №2: перепутали порядок значений в агрегатной инициализации {...}.
Агрегатная инициализация удобна, но она доверяет вам порядок. Если два поля одного типа (например, два int), компилятор не сможет догадаться, что вы “имели в виду”. В таких структурах особенно важно располагать поля в логическом порядке и внимательно следить за тем, что именно вы передаёте в {...}.
Ошибка №3: сделали “странные” значения по умолчанию у полей.
Значение по умолчанию должно быть предсказуемым: done = false, count = 0, пустая строка — нормально. Если поставить что-то вроде priority = 999 “потому что так удобно”, вы потом забудете, что это “особый смысл”, и получите поведение, которое выглядит как мистика, но на самом деле просто плохо задокументированный дефолт.
Ошибка №4: передают Task по значению там, где можно по const Task&.
С маленькими структурами это не всегда больно, но как только внутри появится std::string (а она у нас уже есть), копирование становится заметным и, что важнее, лишним. Если функция только читает задачу, делайте const Task& t: так вы и смысл покажете, и лишние копии не создадите.
Ошибка №5: превращают модель в “свалку всего подряд”.
Иногда хочется добавить в Task ещё “что-нибудь”: кусок текста для логов, какой-то временный флаг для UI, промежуточные данные для поиска. В результате структура перестаёт описывать сущность и начинает описывать ваш текущий бардак. Хорошая модель держит только те поля, которые реально являются частью сущности. Всё остальное лучше хранить отдельно и передавать в функции как временные параметры.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ