Ранее я с некоторым пренебрежением относился к стандартной библиотеке. Мол всё что мне надо я напишу и сам. В частности те же движения со строками, перемещение, копирование и пр. Используя для этого массив, а не контейнерные решения.
Так же я смотрел и на вектор, типа ну а зачем оно мне?
Не так давно решил почитать что-то ещё по С++, остановился на Липпмане. Читал по большей части по диагонали, удивлялся, ну зачем конструктор по умолчанию, копирование объекта... Это для чего, для работы операционной системы? Когда из одной части памяти в другую что-то переносим?
Думаю, ну это же все равно, частный случай... А оказалось, что это не частный, а вполне себе конкретный случай. Просто во всех книгах, плохие примеры, если применение сходу не очевидно, перелистываешь тему. И похоже единственный вариант найти пример, это до него доехать по ходу какой-то программной реализации.
Вариант 1й. Стандартная схема использования объектов в Ардуино. Создается объект класса, а внутри бесконечного цикла начинает с ним что-то происходить. Двигается, взаимодействует с другими объектами. Если это какая-то страничная организация, то покидая страницу, удаляется и объект.
Это достаточно простая организация кода программы. Создается объект класса датчика, например, и он больше не удаляется. На протяжении работы всей программы происходит его опрос, в некоторых случаях меняются его настройки, но не происходит его удаления. А если оно и происходит, то только по закрытию блока фигурных скобок. Например покинули Case Page 1 { … }. Потом вернулись на страницу, объект снова создался, стандартными методами, через конструктор.
Вариант 2й. Внутри бесконечного цикла происходит создание объекта, по наступлению некоторого условия. А по наступлению другого условия, в этом же цикле, должно происходить его удаление. В качестве простого примера может выступать программа, которая по нажатию на кнопку создает объект, который впоследствии отображается на экране. Другая кнопка удаляет, например случайный из уже созданных.
Глядя на это действо, можно сходу заметить одну простую вещь, после закрытия скобок блока if произойдет удаление объекта. И в самом цикле уже ничего с ним сделать не сможем, потому что это был локальный объект.
Вот так и наступает необходимость в контейнерном классе, который будет контролировать создание и удаление объектов другого класса.
Схема работы тут будет следующая. Создаем пустой объект, используя конструктор по умолчанию, который просто резервирует память, не заполняя его поля. Далее используя метод .push_back, копируем его в созданный ранее вектор, по сути в новую область ОЗУ. После чего, уже к объекту находящемуся в векторе применяем метод, который является функциональным аналогом конструктора, который и заполнит поля объекта. После выхода из блока if, созданный обычным способом объект будет удален, как и любой локальный, будь то объект или переменная, а тот что в векторе — останется и после закрытия фигурных скобок. Обращаться уже к нему можно через итераторы, это контейнерная метода, либо индексацией, это классика, как с массивами.
Есть еще возможность методу .push_back заряжать объект сразу с нормальным конструктором, без создания пустого объекта. Но в моём случае (с объектами окна Display_Lib)такой вариант неканорыч, так как при вызове конструктора объекта, его адрес сохраняется в специальном массиве класса Window. И в таком случае, после копирования объекта в вектор, в новую область ОЗУ, адрес будет указывать на локальный объект созданный в блоке if, а не на сохраненный в векторе. И действовать нужно по чуть удлиненной, но тоже стандартной схеме для данного решения, описанной ранее.
В «большой» стандартной библиотеке инструментарий конечно посерьезней, но и жрет я думаю она посерьезней. Насколько прожорливый данный вариант, я пока сказать не могу. Всё пока в тестах, но классы в Display_Lib я уже перепилил для поддержки работы с контейнерными классами ArduinoSTL, включая корректное удаление объектов в деструкторе. Но и стандартная схема создания объекта тоже работать будет. Позже выложу, после тестов.
Пока вроде все достаточно интересно и не плохо. В стандартную библиотеку раньше не вникал особо, ограничивался string и io, и похоже что зря. С теми же итераторами, можно пробовать иначе разного рода массивы трясти.
Помимо <vector>, включает в себя также такие контейнерные классы как : <map>, <set>, <list>, но их надо подключать (#include) дополнительно. Можно использовать описание в книгах и на сайтах как для обычной стандартной библиотеки, но некоторые методы недоступны.
Данная библиотека (ArduinoSTL) доступна на сайте автора и на github
Она так же, судя по всему, доступна и через Менеджер библиотек в ArduinoIDE, так как присутствует описание на сайте arduino.cc