Progma: модуль должен быть совместимпо электрическим и информационным параметрам. Маленький низкочастотный восьмибитный контроллер, например, с большим трудом сможет потянуть 3D графику.
Но это - не главная проблема. Для полноценной работы нужно иметь четкую информацию о том, как обмениваться информацией с подключенным устройством. Хорошо, если есть библиотека или лабораторный стенд, прекрасно, если есть даташит. А вот если этого всего нет - тут только чутье, пишущий осциллограф и опыт помогут.
Там преинкремент криво написан:
Нужно так Counter temp=*this;
++count;
return temp;
О том, что будет реально происходить, мы, строго говоря, не знаем. Умник-оптимизатор может вовсе выкинуть долой выделение temp и копирование в него старого состояния счетчика, потому как в дальнейшем это состояние никому не нужно. Но может и сразу удалить temp за ненужностью, там же на строке ++с1;
Во втором случае, работает так называемый "конструктор копирования по умолчанию". Его работа состоит в банальном копировании полей. Он работает со ссылкой temp, которую выдал преинкремент c1, после чего temp сразу удалается.
И тут в дело снова вступает оптимизатор (RVO (Return Value Optimizaion)), который все эти раскланивания с temp выбрасывает и заменяет на банальное копирование значения счетчика с последующим инкрементом.
Только надо помнить, что с Discovery поставляются примеры, написанные с применением SPL, которые с точки зрения программиста - дрянь полная, и по которым программирование изучать не следует.
Аналогично с ардуиной - тот стиль написания программ, который формируется у пользователей ардуино наводит на мысли о насильственной умственной деградации - те же мысли высказывал Дейкстра о программистах, которых начинали обучать с бейсика.
Сразу предостерегу вас относительно того, что вы рискуете из-за выравнивания получить несовпадение в памяти написанных структур и с тем, что выдает библиотека.
Этого не будет только при условии, что "мощное хранилище" - ваше же собственное, и компилируется тем же компилятором из исходников.
И вам ничего не мешает точно так же внутри структуры объявить массив или кортеж (посмотрите как кортеж устроен внутри - это та же структура) и так же "наставять" его в нужное место строки, получая через него доступ к отдельным пикселям изображения. Естественно, memcpy никаких при этом не будет.
Дмитрий: А зачем нам нужно иметь 9000 специализаций, когда растровое изображение прекрасно формализуется в виде "Матрица из пикселей."
А Пиксель формализуется в виде "Кортеж из каналов" (это если мы хотим изысканных форматов пикселя типа R2 G3 B2 A1) или "вектор из каналов", если нам достаточно иметь одинаковые каналы.
br1an: Образы ваших виртуалок должны быть на зеркале, иначе смысл зеркала (устранение единой точки отказа хранилища) исчезнет. То же самое - об установке гипервизора на флешку - помрет флешка, и весь ваш uptime накроется.
Арсений Чебров: У каждого микроконтроллера свой ассемблер, но общие принципы близки. Программирование на высокоуровневых языках под мелкие контроллеры (avr,pic) ведется с оглядкой на то, во что компилятор превращает код. Иначе все аппаратные возможности контроллера трудно использовать.
Арсений Чебров: На микроконтроллере многие важные вещи делаются с сильной привязкой к аппаратуре контроллера, поэтому знание того, как физически машина реализует программу очень важно.
br1an: С мелкомягкими гипервизорами я знаком очень поверхностно, ничего не могу сказать. Под Linux программный RAID - типовая задача, с целыми двумя путями решения - LVM и mdadm. На мой взгляд, LVM более гибкий, mdadm-более ортодоксальный.
br1an: Это связано с тем, диски примерно одинаковые, работают в примерно одинаковых условиях под одинаковой нагрузкой. Во время синхронизации на выживший диск будет дана высокая нагрузка, которую он может не перенести.
Если же у вас будет RAID1 и бэкап на отдельный накопитель (желательно, чтобы это также был RAID1) - это будет правильное решение.
