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

я думал, что можно передать указатель на свой объект, через последний параметр ф-ии CreateWindow, хотя GDI не мой конек  

bsa, со случайной )

Это сообщение отредактировал(а) Lazin - 13.4.2009, 14:00

GetWindowLong/SetWindowLong + GWL_USERDATA + hWnd.

Proghat, а что это такое вообще? Просто лишь бы что-то было, или есть какой-то смысл именно в этом примере? В обоих вариантах примера используется непонятно где находящееся a[i], смысл if'а  в функции остался недоступен, других вариантов останова, кроме как по переполнению стека вызова я что-то не вижу. Что полезное делает это функция понять невозможно. Для данного примера ответ, ИМХО, зависит от того, какая цель преследуется. Если нужно, чтобы переполнение наступило быстрее, то дополнительные переменные этот процесс ускорят. Если нужно, чтобы подольше помучилась, то использование глобальных переменных немного продлит процесс. Что это за пример такой?   

Я привел не полный код.

Так его или совсем не нужно было приводить, получается тема "за жисть поговорить", или как-то конкретизировать условия. Или думаешь, без этого примера никто не догадается чем отличается в коде использование глобальных переменных и передача переменных как параметров фукнции? 
Если хочешь, чтобы общий разговор на тему был полезен и тебе, можно было как-то хотя бы немного уточнить, на чём программируешь (С, С++), какой сложности программы писал, что на тему читал и т.д. А то ведь не всякий разговор воинов дZена понятен школьнику обыкновенному. 

Это сообщение отредактировал(а) Ln78 - 13.4.2009, 16:11

Понятно. Учту ; ). Хотел спросить об использовании глобальных переменных именно в данном примере(это решение простой олимпиадной задачи).

Прочитал эту тему и те две темы, которые предлагал Soah и сделал для себя выводы:
1) всегда нужно стараться сделать функцию максимально независимой от другого кода;
2) в решении простой олимпиадной задачи (<100 строк) можно использовать глобальные переменные.

Цитата(Ln78 @  13.4.2009,  16:09 )

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

Учу C++. (До этого писал на Pascal около трех лет.) Писал решения олимпиадных задач.

Это сообщение отредактировал(а) Proghat - 13.4.2009, 16:32

Использование глобальных переменных нецелесообразно и опасно. Если дизайн поджимает и обойти никак, тогда лучше использовать функцию со static variable inside. Хотя бы избавит от несогласованности в инициализации между еденицами трансляции. В С++ я вообще не вижу в них смысла, если конечно не приходится в существующий  "дизайн" вписываться.

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


Это сообщение отредактировал(а) GoldFinch - 13.4.2009, 17:45

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

Это сообщение отредактировал(а) mes - 13.4.2009, 17:54

есть опыт работы с большими проектами?

vinter, с небольшими, и не на С\С++
приведите пример, где использование глобальных переменных нецелесообразно и опасно, 
ато может то что очевидно вам, совсем не очевидно остальным


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

Это сообщение отредактировал(а) GoldFinch - 13.4.2009, 18:09

GoldFinch, конкретного примера под рукой нет. Но, потенциальные проблемы:
1. Проблемы связанные с сокрытием и перекрытием имен. Ужасные проблемы могут быть связаны с этим.
2. Проблемы меж-еденица-трансляционного взаимодействия - нет гарантии, что переменная инициализирована при ее использовании, нет гарантии что переменная не изменит своего значения в неподходящий момент.
Глобальную переменную в больших проектах, практически невозможно контролировать

Возьмем пример:
Некие настройки большого проекта - пара сотен окон, все хотят сохранить некие свои настройки.
1 подход. Сохраняйся кто как может. Используем налево-направо серализацию, плодим кучу веток в реестре или файлах настройки. Это все легко контролируется?
2 подход. Глобальный объект локальных настроек. Один на всех, который поддерживает необходимые методы для сохранения всего что кому-нибудь нужно.

Что легче контролировать?

У глобальных переменных есть только одна проблема: программист(-ы). Если разработчик(-и) дружат с головой ничего страшного в глобальных переменных нет.
ИМХО.

самый простой пример - масштабируемость кода, допустим есть у нас глобальая переменная connection, мы ее юзаем в множестве мест программы, все хорошо, не нужно передавать лишних параметров в методы(ф-ии), достаточно проверить if (connection.connected()) и все, программа растет и обрастает функционалом, и тут выясняется что дальше нам прийдется работать с большим количеством connection-ов, либо с connection-ом другого типа