Есть класс:



Интересует, скажем, при вызове Method1() проверять, а проинициализированы ли указатели или они NULL и выдавать ошибку. Насколько это возможно именно на этапе компиляции/линковки?

Обходной путь на данный момент не интересует, хотя он довольно прост: создать сразу конструктор с параметрами и "не париться".

Стормозил на уровне браузера, просьба администриторов удалить одну тему.

На этапе компиляции нельзя, будет ли создан класс, будут ли проинициализированы указатели - это выясняется во время выполнения. А проверять в Method1(), пожалуйста, сколько угодно.

Простую проверку внутри программы сделать проблем нет. Вопрос именно в возможности сгенерировать ошибку ДО получения файла прошивки. Что-то типа throw, что ли...

Вы переоцениваете компиляторы. Он не знает Ваших намерений.
Насчет throw, насколько я знаю, это тоже ловится во время выполнения.
Тестируйте, по возможности, в ОЗУ. Берите Dev.Board c максимальной RAM, тестируйте кусками - на вскидку больше ничего предложить не могу.

На данном этапе проще (и правильнее, ИМХО) сделать конструктор с параметрами. На будущее интересно
Почему же переоцениваю? Ведь на уровне "variable x was defined but not used" справляется - здесь вроде не сложнее задача.

С переменными проще, чем с указателями.
Указатели всегда останутся за программистами или роботы нас со временем начнут эксплуатировать. Шутка.

Субъективное мнение или имеет под собой какую-то базу?
Я по принципу, что проще и экономичнее ссылаться куда-либо, чем хранить копию... В данном классе хранить непосредственно данные необходимости не возникает. Хотя, в конкретно данном опять же, случае что ссылка, что сам тип данных будут занимать один и тот же объем.

Если объект глобальный - ваши указатели проинициализированы нулями, даже если вы не сделали этого в конструкторе.
Чтобы выдать подобное предупреждение, компилятор должен проанализировать каждый вызов ф-ции Method1() и убедиться, что перед для этого объекта вызван метод Init(). В случае прерываний\многопоточности это наверное вообще невозможно... Да и как вы это объясните компилятору?
throw, безусловно, ловится только на этапе выполнения.
Кст, насколько я знаю, IAR исключения не поддерживает.

Думаю, Вы правы, поскольку в ЮзерГиде ничего по этому поводу не нашел

Версия для AVR не поддерживает точно - EWAVR_CompilerReference, стр. 189-190.
Насчет ARM не знаю.

...намного сложнее. Когда используется уровень "variable x was defined but not used" компилятор просто просматривает текст чтобы определить используется где-либо объявленное имя или нет. В вашем случае ему бы пришлось еще анализировать и алгоритм реализованный в программе (задача не тривиальная)...например на предмет неявных присваиваний:

class anyclass
{
unsigned char* pointer;
...
};



anyclass a, b;

a = b;








...а чем Вам не нравится вариант инициализации в кострукторе, ведь это хороший тон программирования?

Тоже нет. Во всяком случае в 4.хх

Кто такое NULL?


Через конструктор - это как раз прямой путь. А вот все остальные - обходные.


По факту это так, но лучше все же инициализацию объектов класс-типов делать через конструктор, чтобы их инициализация не зависела от того, где этот объект создан - в глобальной scope, локально в функции или динамически в куче.

Тогда здесь же вопрос к людям, имеющим в приложении к МК опыт бОльший, нежели я
Куда лучше складировать данные классов - во флеш или в кучу? Понимаю, что зависит от ситуации, но может, направите на литературу, где можно про это найти.

Во флеш вы можете хранить только неизменяемые части данных, причем в классе придется предусмотреть указатель на эту неизменяемую часть. Это имеет смысл для классов с большим количеством "настроечной" информации, заранее известной на этапе компиляции - например, элементы пользовательского интерфейса.

Что касается кучи, ИМХО, лучше вобще не использовать, по крайней мере стандартную:
1. Сам не вникал, но много слышал, что стандартный менеджер памяти далек от идеала и при некоторых обстоятельствах может приводить к сильной дефрагментации кучи и как следствие - не будет свободного места.
2. Придется вручную оценить требуемый размер - т.е. проанализировать, сколько одновременно объектов может быть создано. При этом любое изменение программы потребует перерасчета.
3. Надо быть очень аккуратным с new и delete - иначе начнутся утечки памяти.
Поэтому лично я использую динамическое выделение памяти только для целей пользовательского интерфейса, причем свой собственный менеджер памяти, организованный на основе стека и заведомо не приводящий к проблемам дефрагментации.
Все остальные объекты я делаю глобальными \ статическими \ членами классов, экземпляры которых глобальны либо создаю в стеке. Это полностью убирает вышеуказанные проблемы.

У меня на tiny2313 как-то уж очень быстро все заполняется

У Вас нет ясности, что такое Flash, а что такое RAM. Когда разберетесь, таких вопросов не будет.

alexander55, не совсем понимаю, к чему Вы клоните, возможно неверно понимаю принцип работы. Если складывать данные в флеш и обращаться к ним, например, через указатели - то они же не будут РАМу постоянно засорять?

В грубой аналогии - флеш - это как HDD?

Запись во флеш осуществляется страницами (это отдельная песня), т.е. их надо подготавливать в буфере (в том же RAM), а потом писать блоком. Что тут можно выиграть, я не знаю.
В классах данные находятся в RAM, а функции во Flash.


Аналогии, безусловно, есть.
Запись: в HDD посекторная - во флешь постраничная.
Чтение: из HDD посекторное - из флешь, в зависимости от ее организации, побайтное для AVR, для ARM вопрос более сложный.

...зависит от конкретной задачи. В принципе объекты класса можно размещать во flash, если данные объекта не изменяются во время выполнения или изменяются редко. Куча предпочтительней, но при использовании объектов разных классов возможна дефрагментация и как следствие при создании объекта во время выполнения память может быть не выделена даже если общий размер свободной памяти на куче больше требуемой. У меня например есть суеверный страх перед кучей , но если программа продумана хорошо проблем нет. В случае создания статических обектов проблемы кучи исчезают и поэтому он предпочтительней, как плюс - уже на этапе компиляции известен объем требуемой памяти (в случае кучи надо анализировать выполнение программы чтобы его определить, либо определять опытным путем при выполнении программы).

У меня когда-то в "классике" был такой страх перед динамикой и перед использованием двоичных файлов. Порой вообще необоснованный Сейчас в случае с МК этого нет. Может быть, напрасно?

сомневаюсь, поскольку опыт работы с МК у меня минимальный.

А у меня суеверный страх перед изменением flash (пусть даже редким) во время работы программы. По-моему, в 99,99% случаев использовать этот прием не стоит...

Интуиция Вас не подводит.
В предыдущем высказывании при редактировании я добавил одну фразу, сейчас с удивлением смотрю на результат.