2 вопроса по Си++, WinAVR Опции

[kurtis]

Вопрос 1:
Есть функция getErrorPacket(), она является частью класса Etaz_item, который в конструкторе принимает ссылку на класс типа NetTransferConstrol, который уже в свою очередь содержит функцию get_error_packet(), которая ""генерирует" исходные данные.
Упрощенно класс Etaz_item выглядит следующим образом

Код

class NetTransferConstrol;

class Etaz_item: public TechObj
{
    private:
        NetTransferConstrol & cBfppClass;
    public:
        void func1();
        void func2();
        uint8_t getErrorPacket()
        {            
            return cBfppClass.get_error_packet();            
        };
        Etaz_item ( NetTransferConstrol & _cBfppClass )
                    : cBfppClass ( _cBfppClass )
        {
            //.......
        };
};

т.е. есть какой-то класс NetTransferConstrol, описание которого находится где-то в другом месте, и сам класс Etaz_item, который принимает ссылку на обьект типа NetTransferConstrol. К классу Etaz_item относится 2 файла : Etaz.cpp, где описан код реализации всех функций класса, и Etaz.h, где находится реализация структуры класса.
И вот тут начинаются непонятные вещи, когда я код функции getErrorPacket() помещаю в Etaz.cpp, то проект компилируется, но если я перемещая код функции в класс, как показано в примере, то компилятор начинает ругаться

./src/Etaz.h:166: error: invalid use of incomplete type 'struct NetTransferConstrol'
./src/Etaz.h:122: error: forward declaration of 'struct NetTransferConstrol'

Почему компилятор генерирует ошибку в случае когда код функции описан прямо в классе, но ничего не выдает, когда эта же функция описана во внешнем файле(Etaz.cpp)? Возможно как-то получается ситуация когда класс типа Etaz_item "родился", а класс типа NetTransferConstrol еще нет, но тогда совсем непонятно как оно работает и где оно берет ссылку... И непонятно причем тут "struct NetTransferConstrol", ведь NetTransferConstrol обьявлен как class?
Пробовал имитировать подобную ситуацию в MinGW, но там все компилируется без проблем, так что считаю что это не синтаксическая ошибка...

Вопрос 2:
Как мне убедится что на момент создания класса Etaz_item, обьект типа NetTransferConstrol уже существует, и ссылка будет правильной?

Всем заранее спасибо за помощь!!!
З.Ы. Компилятор WinAVR 20080610
З.Ы.Ы. Обьекты создаются статически во время начальной инициализации

[Kuzmi4]

2 Сергей Борщ

..Не поверите - чтобы использовать преимущества объектного программирования...

Не могли бы вы привести тогда пару примеров ?

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

2 Сергей Борщ
Не могли бы вы привести тогда пару примеров ?

Легко. Вот только некоторые:
Инкапсуляция - группирование взаимосвязанных элементов (данные, функции для работы именно с этими данными) в один класс и ограничение доступа к этим данным и функциям извне.
Пространства имен - тоже группирование и уменьшение писанины.
Наследование - построение иерархии данных.
Шаблоны - вместо copy-paste и мелких правок похожих функций пишется шаблон.
Переопределение операторов и функций:

Код

class uart_t
public:
    void dump(uint8_t );
    void dump(uint16_t );
    void dump(char const *);
    void dump(my_struct_t *);
};
struct my_struct_t
{
    ......
    bool operator=(mystruct &);
};
вместо
   void uart_dump_uint8_t(uint8_t);
   void uart_dump_uint16_t(uint16_t);
   void uart_dump_string(char const *);
   void uart_dump_mystruct(my_struct_t *);
   bool compare_my_struct(my_struct_t *, my_struct_t *);

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

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

Теперь, возможно, Amper25 приведет описание ужасов объектного подхода, из-за которых "для MCU, тем более для AVR" не нужно его использовать?