Язык С, ARM - простые вопросы Опции

[Slash]

Здравствуйте!

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

А если программа строится в виде задач в бесконечном цикле:

Код

while (1)
{
    Task1();
    Task2();
    Task3();
}

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

[rezident]

Теперь мне нужно прикрутить в проект второй UART с той же функциональностью, третий, четвёртый ... И вообще - я, как менеджер проекта, не знаю, сколько у заказчика будет UART-ов. Как мне Ваш модуль с минимальными доработками несколько раз включить в проект ?

Что-то я не понял затруднений. Статические переменные объявленные внутри функции имеют область видимости в пределах этой функции. Статические переменные объявленные вне какой-либо функции имеют область видимости в пределах данного модуля. Разве не так?
Могу конечно ошибаться, но по-моему singlskv имел в виду как раз такой случай. Глобальная переменная (объявленная вне тела функции) типа static имеет область видимости в пределах данного модуля. Никто не мешает дублировать эти модули в требуемых количествах. Хотя конечно же, если модуль состоит из одной функции, то разумнее было бы объявить эти переменные как static, но внутри самой функции.

[singlskv]

Могу конечно ошибаться, но по-моему singlskv имел в виду как раз такой случай. Глобальная переменная (объявленная вне тела функции) типа static имеет область видимости в пределах данного модуля. Никто не мешает дублировать эти модули в требуемых количествах. Хотя конечно же, если модуль состоит из одной функции, то разумнее было бы объявить эти переменные как static, но внутри самой функции.

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

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

[Demeny]

Я вот совсем теперь не понимаю за что ратует Demeny ...

Попробую ещё раз пояснить преимущества локальных переменных перед глобальными, пусть даже и статическими, т. е. видимыми в пределах одного программного модуля.
1) Если Ваш конечный автомат, или другой программный модуль (функция) хранит своё внутреннее состояние в статических или глобальных переменных, он тут же становится непригодным для многопоточного использования, проще говоря, становится "non-reenterable", во всяком случае, Вам придётся прибегнуть к специальным ухищрениям навроде синхронизации, чтобы использование Ваших функций в многопоточном приложении не вызвало крах всего приложения. Также она не может быть безопасно вызвана в качестве обработчика прерывания.
В случае локальных переменных всё безопасно - ведь у каждого потока свой стек, следовательно, каждый поток работает со своим уникальным набором переменных.
2) Ваш модуль в составе программы может вообще оказаться невостребованным (ну нет у клиента 8 UART-ов, заложенных по максимуму ...), однако память под буфера и прочие настройки Вы уже зарезервировали статически. Или же Ваш модуль нужен только на этапе инициализации - один раз при старте системы, а память занята уже "навсегда" ...
3) Доступ к локальным переменным осуществляется, как правило, быстрее, чем к глобальным (статическим), потому что любой оптимизирующий компилятор старается раскидать по возможности локальные переменные по регистрам процессора.
4) С точки зрения проектирования удобно представлять себе отдельную функцию, как законченный функциональный блок ("черный ящик") с входными и выходными параметрами. Это позволяет отлаживать функцию отдельно от остальных. Использование глобальных переменных размывает это понятие, поскольку, как ни крути, поведение функции зависит от поведения остальной части программы. Вот и будем ломать голову при отладке, какого же рожна глобальная переменная имеет "не то" значение, какое должно быть, и какая собака его испортила. Придётся бросить отладку текущей функции и заняться поиском "собаки".

[zltigo]

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

Либо с точностью до наоборот - ПРИГОДНЫМ. Конечный автомат получает указатель на структуру с котрой работать в данный момент и работает. Кроме того, опять, если нужны сколь нибудь реально-сложные автоматы в многопоточном приложении, то по любому он нужен и эти проблемы придется решать и отнюдь "просто используем локальные переменные".

Вы уже зарезервировали статически.

Статически-то зачем? Спросили сколько надо у менеджера памяти. А вот стек, который потребуется Вам для Вашего непрогнозируемого количества "UART-ов" Вы как раз скорее всего статически-то и выделите. 

3) Доступ к локальным переменным осуществляется, как правило, быстрее, чем к глобальным (статическим)

Из каждого "правила" есть исключения. Причем "как правило" они очень мешают жить. 

.. поведение функции зависит от поведения остальной части программы.

Либо поведение этой функции ДОЛЖНО ЗАВИСЕТЬ от "остальной части" и тут Вас никакие ухищрения не заставят обойти эту зависимость. Либо НЕ зависят - в этом случае глубоко фиолетов глобальные или нет какие-то переменные, ибо в этом случае они по любому приватно находятся в пользовании одной функции.

 

[A. Fig Lee]

Статически-то зачем? Спросили сколько надо у менеджера памяти. А вот стек, который потребуется Вам для Вашего непрогнозируемого количества "UART-ов" Вы как раз скорее всего статически-то и выделите. 

 

Товарищи капиталисты, по-моему вы путаете теплое с мягким.

Глобальное - то, что видно отовсюду и всегда живет (возможно спорно),
Локальное - определено и живет в пределах обьекта к которому принадлежит.
Пример - переменные обьявленные внутри функции - локальные для етой функции (
совсем не обязательно они должны быть на стеке),
переменные обьявленные внутри класс/структуры - локальны для етих
классов/структур и глобально (без структуры/класса) - невидимы.
Могут размещатся в хипе, от етого глобальными не становятся.

[_Pasha]

Товарищи капиталисты, по-моему вы путаете теплое с мягким.
Глобальное - то, что видно отовсюду и всегда живет (возможно спорно),

Статическое - это то, что видно только там, где надо, и всегда живет. Не путайте мертвое  с пьяным

[A. Fig Lee]

Статическое - это то, что видно только там, где надо, и всегда живет. Не путайте мертвое  с пьяным

смотря о каких языках говорил - C или C++?

2. живет не всегда. например, обьявленная внутри функции - с момента обращения к функции.

Это у Вас каша из глобальности и области видимости, на что я уже сразу указывал.

видимость переменной может быть и глобальной, но она являтся локальной -
обьявить паблик мембер - член класса

[_Pasha]

2. живет не всегда. например, обьявленная внутри функции - с момента обращения к функции.

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

[sonycman]

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

А если статическая переменная локальная? Разве её инициализация будет производиться в стартапе?

[singlskv]

А если статическая переменная локальная? Разве её инициализация будет производиться в стартапе?

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



Более того(если захотеть), менять ее можно будет и из другой функции.

[rezident]

Более того(если захотеть), менять ее можно будет и из другой функции.

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

[singlskv]

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

Я это и имел в виду.("менять ее можно будет...")

А мне тут недавно говорили, что статические локальные переменные инициализируются при первом заходе в содержащую их функцию.
И совершенно не в стартапе.

Вас обманули...

Ну то есть, конечно, можно представить себе компилятор который будет так поступать,
только это очень не эффективно.

Ну и главное что память под такую переменную уже будет отведена компилятором, те к моменту первого
запуска ее адрес будет постоянным.

[sonycman]

Вас обманули...

Ну то есть, конечно, можно представить себе компилятор который будет так поступать,
только это очень не эффективно.

Ну и главное что память под такую переменную уже будет отведена компилятором, те к моменту первого
запуска ее адрес будет постоянным.

Да, проверил - простые встроенные типы к моменту первого входа в функцию уже инициализированы.

С другой стороны - объект простого класса инициализируется всё таки уже внутри функции - с обработкой защёлки через __cxa_guard_acquire.
Несмотря на то, что такие-же глобальные объекты создаются и инитятся в стартапе.
Но не локальные статические.

То есть статические локальные объекты всё таки несут в себе определённый оверхед...