Есть класс:



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

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

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

Сообщение отредактировал aspID - Sep 10 2007, 09:19

На этапе компиляции нельзя, будет ли создан класс, будут ли проинициализированы указатели - это выясняется во время выполнения. А проверять в 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 - иначе начнутся утечки памяти.
Поэтому лично я использую динамическое выделение памяти только для целей пользовательского интерфейса, причем свой собственный менеджер памяти, организованный на основе стека и заведомо не приводящий к проблемам дефрагментации.
Все остальные объекты я делаю глобальными \ статическими \ членами классов, экземпляры которых глобальны либо создаю в стеке. Это полностью убирает вышеуказанные проблемы.