[gretis 0]

Есть класс:

 

class My_Class
{
private:
  unsigned char * cPort;
  unsigned char * cMask;
public:
  My_Class() {};
  ~My_Class() {};
  Init(char * cPort, char * cMask);
  int Method1();
};

 

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

 

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

 

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

Изменено 10 сентября, 2007 пользователем aspID

[alexander55 0]

Есть класс:

 

class My_Class
{
private:
  unsigned char * cPort;
  unsigned char * cMask;
public:
  My_Class() {};
  ~My_Class() {};
  Init(char * cPort, char * cMask);
  int Method1();
};

 

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

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

[gretis 0]

в Method1(), пожалуйста, сколько угодно

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

[alexander55 0]

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

Вы переоцениваете компиляторы. Он не знает Ваших намерений.

Насчет throw, насколько я знаю, это тоже ловится во время выполнения.

Тестируйте, по возможности, в ОЗУ. Берите Dev.Board c максимальной RAM, тестируйте кусками - на вскидку больше ничего предложить не могу.

[gretis 0]

На данном этапе проще (и правильнее, ИМХО) сделать конструктор с параметрами. На будущее интересно :)

Почему же переоцениваю? Ведь на уровне "variable x was defined but not used" справляется - здесь вроде не сложнее задача.

[alexander55 0]

На данном этапе проще (и правильнее, ИМХО) сделать конструктор с параметрами. На будущее интересно :)

Почему же переоцениваю? Ведь на уровне "variable x was defined but not used" справляется - здесь вроде не сложнее задача.

С переменными проще, чем с указателями.

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

[gretis 0]

С переменными проще, чем с указателями.

Субъективное мнение или имеет под собой какую-то базу?

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

[Johnny81 0]

На данном этапе проще (и правильнее, ИМХО) сделать конструктор с параметрами. На будущее интересно :)

Почему же переоцениваю? Ведь на уровне "variable x was defined but not used" справляется - здесь вроде не сложнее задача.

 

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

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

throw, безусловно, ловится только на этапе выполнения.

Кст, насколько я знаю, IAR исключения не поддерживает.

[gretis 0]

насколько я знаю, IAR исключения не поддерживает

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

[Johnny81 0]

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

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

Насчет ARM не знаю.

[tag 0]

На данном этапе проще (и правильнее, ИМХО) сделать конструктор с параметрами. На будущее интересно :)

Почему же переоцениваю? Ведь на уровне "variable x was defined but not used" справляется - здесь вроде не сложнее задача.

 

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

 

class anyclass

{

unsigned char* pointer;

...

};

 

 

 

anyclass a, b;

 

a = b;

 

 

 

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

 

 

 

 

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

[Сергей Борщ 123]

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

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

[dxp 50]

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

Кто такое NULL?

 

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

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

 

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

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

[gretis 0]

Тогда здесь же вопрос к людям, имеющим в приложении к МК опыт бОльший, нежели я :)

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

[Johnny81 0]

Тогда здесь же вопрос к людям, имеющим в приложении к МК опыт бОльший, нежели я :)

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

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

 

Что касается кучи, ИМХО, лучше вобще не использовать, по крайней мере стандартную:

1. Сам не вникал, но много слышал, что стандартный менеджер памяти далек от идеала и при некоторых обстоятельствах может приводить к сильной дефрагментации кучи и как следствие - не будет свободного места.

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

3. Надо быть очень аккуратным с new и delete - иначе начнутся утечки памяти.

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

Все остальные объекты я делаю глобальными \ статическими \ членами классов, экземпляры которых глобальны либо создаю в стеке. Это полностью убирает вышеуказанные проблемы.