static variable Опции

[Jenya7]

Зачем локальную переменную делать статик? Если мы сохраняем ее в RAM то с тем же успехом ее можно сделать глобальной ну или статик на уровне файла.

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

может быть дядька Шилдт имел ввиду объектно-ориентированный подход, а не сам язык С++, который к объектно-ориентированному подходу достаточно перпендикулярен?
Я не понимаю, что может мешать в программе класса "мигалка светодиодом" использовать перегрузку операторов:

CODE

void print(char const * string);
void print(int number);

void test()
{
    print("I = ");
    print(123);
}
// вместо дающего точно такой же выходной код сишного
void print_string(char const * string);
void print_number(int number);

void test()
{
    print_string("I = ");
    print_number(123);
}

что мешает объявлять типы структур более короткой записью, без typedef:

CODE

struct a_t
{
    int B;
    int C;
};
a_t A;

// вместо дающего точно такой же выходной код сишного
typedef struct
{
    int B;
    int C;
} a_t;
a_t A;

что мешает использовать шаблоны

CODE

void send(void const * from, size_t size);

template<typename T>
inline void send(T & data) { send(&data, sizeof(data)); }

uint32_t A;
uint8_t B;
struct c_t { uint32_t A; uint8_t B; char Name[20]; } C;

void test()
{
    send(A);
    send(B);
    send(C);
}

// вместо дающего точно такой же выходной код сишного
void test1()
{
    send(&A, sizeof(A));
    send(&B, sizeof(B));
    send(&C, sizeof(C));
}

что мешает использовать объявления структур внутри структур

CODE

struct config_t
{
   struct module_a_t
   {
       ....
   };
   struct module_b_t
   {
      ....
   };
   module_a_t A;
   module_b_t B;
} Config;

config::module_a_t * pModule_A_cfg = &Config.A;
// вместо дающего точно такой же выходной код сишного
typedef struct
{
   ....
} module_a_config_t;
typedef struct
{
    ....
} module_b_config_t;
typedef struct
{
   module_a_config_t A;
   module_b_config_t B;
} config_t;
config_t Config;

module_a_config_t * pModule_A_cfg = &Config.A;

что мешает использовать хотя бы простейшие объекты?

CODE

class a_t
{
public:
    void do_process();
private
    ... какие-то данные ....    
}
a_t A, B;
void test()
{
    A.do_process();
    B.do_process();
}

// вместо дающего точно такой же выходной код сишного
typedef struct
{
    ... какие-то данные ....    
} a_t;
a_t A, B;
void do_process(a_t * data);

void test()
{
    do_process(&A);
    do_process(&B);
}

и таких примеров можно привести великое множество. Еще раз подчеркиваю - эти исходники дают абсолютно идентичный выходной код, но на С++ они короче, а значит их легче писать, в них труднее запутаться или допустить описку.

[Baser]

может быть дядька Шилдт имел ввиду объектно-ориентированный подход, а не сам язык С++, который к объектно-ориентированному подходу достаточно перпендикулярен?
Я не понимаю, что может мешать в программе класса "мигалка светодиодом" использовать перегрузку операторов:
что мешает объявлять типы структур более короткой записью, без typedef:
что мешает использовать шаблоны
что мешает использовать объявления структур внутри структур
что мешает использовать хотя бы простейшие объекты?

и таких примеров можно привести великое множество. Еще раз подчеркиваю - эти исходники дают абсолютно идентичный выходной код, но на С++ они короче, а значит их легче писать, в них труднее запутаться или допустить описку.

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

А применение объектно-ориентированного подхода это уже отдельный вопрос и к вышеприведенным примерам отношения не имеющий, и на маленьких проектах ИМХО себя не оправдывающий.