И если вы такой объект расположите любой директивой компилятора по заданному адресу его так же нельзя будет инициализировать.
Вы можете инициализировать локальную структуру, а потом присвоить её вашей, расположенной по указателю.
Вы вроде хотели переменную в ОЗУ? При чём тут флешь?
В контексте МК это однозначно MAC+PHY. В STM32F107 есть MAC (с MII и RMII). Так что для подключения wifi через Ethernet ТС понадобится PHY, трансформатор + точка доступа WiFi с Ethernet выходом (на витую пару). Не уверен, что его этот огород устроит :)
Результат вполне ожидаемый. При приведении типа от любого плавающего к целому происходит отбрасывание дробной части (а не округление). Из за того, что точность плавучки не бесконечная, а десятичные дроби точно не представимы в двоичном внутреннем представлении как float так и double, при вычислениях неизбежно накапливаются ошибки округления. Достаточно ошибки в 1 бит в мантисе и результат будет тот, что вы и получили.
Самое простое решение - добавить 0.5 перед приведением к u08
Если 'проработать должно более 20 лет' то первые попавшиеся конденсаторы с барахолки не подойдут, даже если их вообще не включать :1111493779:
Вам нужно что то из серии long life, например https://en.tdk.eu/inf/20/30/db/aec/B43713_B43733.pdf
Плохо пытались.
Файл t.c:
int test_var;
Файл main.c:
#include <stdio.h>
int test_var;
int main(int argc, char** argv)
{
printf ("test var: %d\n", test_var);
return 0;
}
Сборка и запуск:
> gcc -c t.c -o t.o
> gcc -c main.c -o main.o
> gcc t.o main.o -o test
> ./test
test var: 0
Условия:
Только С
Переменные без инициализации
Такое поведение описано в стандарте С
Не надо. У всех контейнеров в STL есть шаблонный параметр - аллокатор (и он практически никогда не передаётся, а используется аллокатор по умолчанию - через new/delete и кучу)
Делаете свой аллокатор (с любым местом расположения объектов и алгоритмом алокации) у вуаля - всё управление кучей в ваших руках :)
Пошла 4 страница трёпа вокруг массива/указателя... Ещё 6 страниц и можно ожидать переходы на личности и мерянье пиписьками :)
Пошёл за попкорном :salmari:
Он не прав :)
Это не так. Если в программе нет того, что называется undefined behavior, то разница в её поведении на разных уровнях оптимизации - это ошибка компилятора.
Другое дело, что оптимизатор в VC всегда не являлся сильным местом компилятора. Нормальный оптимизатор в состоянии разобраться (или предположить, если ему пользователь скажет), могут указатели пересекаться или нет.
Попробуйте собрать программу с опцией 'Full program optimization' (или как она там называется). Ещё можно попробовать сделать поля в nv0 и nvf0 другого размера (была такая опция - ansi alias. Она предполагала, что типизированные указатели на память не могут пересекаться, если они указывают на типы, несовместимые по прямому присваиванию. Не знаю, есть ли оно в VC, но всё может быть)
Он не может. У вас там присваивания в поля структуры OscRaw (nv0 и nvf0). Для компилятора это запись в память. Видимо анализ указателей у VC хромает (или выключен), и он считает, что эта запись потенциально может попасть в любой глобальный объект (ч том числе и в те, к которым обращаются через указатель). Поэтому содержимое chain может измениться (с точки зрения компилятора).
тут вы взяли отвественность на себя, явно переместив значение в локальную переменную. Для неё pointer анализ говорит, что она ни с какими указателями не пересекается.
Нет. В массив могут записать 'сбоку' (не через указатель на него).
