[jenya7 0]

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

[Baser 5]

с тем же успехом ее можно сделать глобальной ну или статик на уровне файла.

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

В других местах можно применять переменные с таким же именем и они будут другими для компилятора.

[jenya7 0]

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

В других местах можно применять переменные с таким же именем и они будут другими для компилятора.

я понял. спасибо. наверное когда нибудь мне пригодиться такое свойство.

[Baser 5]

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

Например, переменная step, которая является текущим шагом конечного автомата, описываемого функцией.

Это повышает читабельность кода и снижает возможность ошибок.

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

[jenya7 0]

спасибо. наконец то понял для чего это нужно. :)

[adnega 11]

При "правильном" программировании

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

Функцию с внутренней переменной step не особенно запихнешь в библиотеку для повторного использования.

С многопоточностью будут проблемы у такой функции.

Совпадение имен глобальной и локальной переменной тоже лучше не практиковать - попутать что где легче простого.

[dxp 53]

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

Функцию с внутренней переменной step не особенно запихнешь в библиотеку для повторного использования.

С многопоточностью будут проблемы у такой функции.

Ну, с глобальной переменной будет ровно то же самое. Что касается полезности, то завит от. У локальных статических функций есть свои плюсы. Например, функции-генераторы. Или тот же синглтон Мейерса. Реализация получается простая и эффективная. Конечно, в любом случае программист должен чётко представлять, что он делает и какие последствия могут возникнуть из-за неправильного использования.

 

Совпадение имен глобальной и локальной переменной тоже лучше не практиковать - попутать что где легче простого.

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

[adnega 11]

Ну, с глобальной переменной будет ровно то же самое.

А если все необходимые переменные передавать в функцию (в виде списка или сложного объекта)?

Разумеется, что совсем без побочных действий не обойтись, но если данные можно отделить от кода,

то я такой возможностью пользуюсь.

Тут пример для управления шаговым двигателем приводили. Предложенная реализация возможна

для одного двигателя, а если их много больше?

Я бы сделал массив объектов, которые бы хранили все необходимое - и текущий шаг, и скорость, и ускорение,

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

А функцию, решающую что делать с полем step, сделал бы универсальной.

Разумеется static переменных в ней не было бы. Оформил бы это в виде библиотеки и таскал из проекта в проект,

где есть хоть один шаговый двигатель.

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

Разумеется static переменных в ней не было бы.

Все это хорошо, но локальные данные могут быть и константными (скажем, таблица для перевода номера микрошага в коэф. заполнения ШИМ или любые другие константы) и чтобы эти данные не копировались в ОЗУ во время создания переменной при каждом входе в такую функцию, переменная должна быть объявлена статической.

[adnega 11]

скажем, таблица для перевода номера микрошага в коэф. заполнения ШИМ

Т.е. эта таблица жестко "вшита" в функцию? Не пойдет ибо ШИМ довольно аппаратно-зависимая вещь.

Хотя идея понятна (может понадобиться таблица синуса, например).

[Baser 5]

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

С многопоточностью будут проблемы у такой функции.

С этим никто не спорит, но нужно решать в каждом конкретном случае, как будет удобней.

 

Функцию с внутренней переменной step не особенно запихнешь в библиотеку для повторного использования.

А вот тут никто вам не запрещает это делать. Более того, в стандартных библиотеках Си полно функций с таким финтом,

в описаниях отдельно пишут, что они "опасные", не реентерабельные, дописывают новые варианты безопасных, но нестандартных функций. Но стандартные функции то уже никуда не денешь :)

Вот пример, функция парсинга текстовых строк strtok

 

Совпадение имен глобальной и локальной переменной тоже лучше не практиковать - попутать что где легче простого.

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

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

 

А если все необходимые переменные передавать в функцию (в виде списка или сложного объекта)?

Такой подход тоже имеет место быть, когда есть несколько одинаковых кусков кода обработки.

 

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

Для таблиц и констант можно применять указатели, которые тоже передаются в функцию. Можно передавать также и переменные свойства таблиц (длину, структуру).

 

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

А то сам иногда так накручу код для компактности, потом смотрю на тот ужОс, который получился и понимаю, что написание "тупо в лоб методом copy-paste" было бы лучше :)

 

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

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

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

А то сам иногда так накручу код для компактности, потом смотрю на тот ужОс, который получился и понимаю, что написание "тупо в лоб методом copy-paste" было бы лучше :)

Серега, ты созрел для перехода на C++ :)

 

[Baser 5]

Серега, ты созрел для перехода на C++ :)

Увы, все никак...

Даже осилил почти весь учебник Шилдса, но до конца прочуствовал только одну фразу во введении,

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

 

У меня проекты сравнительно простые, поэтому я никак не пойму для чего мне все эти фантики (обертки) которые скрывают реальную сущность объектов.

С переходом с асма на си было все понятно, выгоды очевидны, а тут... :laughing:

[esaulenka 7]

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

 

Да что этот Шилдс понимает... :-)

Я осваивал плюсы на scmRTOS ("кишки" довольно сложные, но снаружи всё просто и понятно) и на Qt (супер-понятный внешний интерфейс, в "кишки" даже не лазил).

Рекомендую!

После этого свои классы без особых проблем придумываются.

 

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

[zltigo 1]

...созрел для перехода на C++ :)

Мой первый сиобразный язык был С++, а не С. В незапамятные времена, когда только появился первый (первый, потому, что 1.0 версии не было :) ) борлондячий Борланд С++ 2.0 я получил персональный компьютер и решил сваять для работы некую приблуду для которой требовалась, то, что я назвал, "оконной библиотекой" - то есть всякие окошки, текстовые естественно, но все же типа "Windows". В КБ у меня уже был уже бывалый сишный программисто, который утверждал, что писать нужно на Си с большими вкраплениями ASM, иначе будет безумно медленно. В обшем-то он был прав, поскольку тогдашний массовый персональный компьютер был восьмибитовым и имел тактовую 4,7MHz :). Он даже взялся на спор показать мастеркласс в соревновании на скорость работы оконной библиотеки. В общем вечерами сидели и писали. Я на плюсах, правда с вкрапелениями на ASM, ибо уровень оптимизации тогдашних компиляторов был просто никакой, он на Си. Результат был как бы неожиданный - плюсовая работала быстрее :). Причина на самом деле проста - уже больно она красиво и хорошо ложилась она во все эти классы и иже с ними. Выигрыш был за счет лучшей системной оптимизации. На самом деле обе , библиотеки работали медленно :(. Так что дальше начался этап писания на Си, но опираясь на понимание пришедшее с плюсов. Компиляторы с тех пор сделали громадный скачек так что СЕГОДНЯ откатываться на Си уже не пришлось-бы.

Сегодня надо писать на C++, хотя я так и остался де-факто на Си. Но С++ подход к делу НАВСЕГДА остался со мной.