Была такая машина - 'Эльбрус 2', и был у нее язык програмирования 'Эль 76', весь насквозь динамический, при описании переменной указывался только ее размер, содержимое же переменной (целое, плавающее или указатель) определялось динамически на этапе выполнения (прямо boost::any). Казалось бы очень удобно, очень гибко и динамично, гип-гип ура! Увы, эта гибкость обернулось ОГРОМНЫМ недостатком - если компилятор C/C++ способен найти несоотвествие типов уже на этапе компиляции (причем все), то на Эльбрусе эти несоотвествия вываливались run-time (причем по мере хождения по этим граблям). И не было никакой гарантии, что не осталось каких нибудь несоотвествий типов (просто потому, что по этому месту не прошли). Явная динамика типов была нужна КРАЙНЕ редко. В следующей версии Эль 76 были добавлены статические описания типов.

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

В примере обшая переменная для двух функций храняшихся в разных файлах . Единственное отличие oт примера на php - декларация вне фунциии;
Вот и вопрос чем не устраивает такой подход и почему надо обязательно иметь возможность декларировать глобальные переменные в фунции ??


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


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

Добавлено через 6 минут и 55 секунд

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


Это сообщение отредактировал(а) mes - 6.5.2008, 16:27

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

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

Добавлено через 2 минуты и 14 секунд
хотя как раз эту задачу (ограничение области видимости до двух функций) можно решить с помощью friend:
создаём глобальный экземпляр класса, в котором в закрытой секции прописана эта переменная
и делаем две выбранных функции его друзьями
таким образом без изменения этого класса не получится доступиться к этой переменной откуда-то кроме этих двух функций

Добавлено через 3 минуты и 26 секунд
хотя это, конечно, для того случая, если есть причины не создавать класс, в котором будут эти функции (т.к. налицо нечто общее между ними)

На C/C++ это лучше сделать и вовсе без глобальных переменных:




Приведи конкретный пример.


namespace?

Что-т в последнее время много тем, по сути сводящиеся к вопросу: "почему С++ не позволяет делать то, что делается в скриптовых языках...".

  весна  

неймспейс хорошо, а класс - лучше, ибо переменную можно приватной сделать и все - никакой using namespace ничего плохого не сделает

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

Про ООП в С++ я ваще ничего не шарю, еще не дорос. Так что ничего написать не могу. 

Добавлено через 4 минуты и 18 секунд
И еще мне не понравилось в С++ что функция не может массив возвращать :(

Это сообщение отредактировал(а) Igor_K - 7.5.2008, 22:49

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

И еще мне не понравилось в С++ что функция не может массив возвращать :(
в C++ это и не нужно.

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

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


Неименованному пространству имен никакой using не сделаешь  


Это смотря как передашь. 




Это сообщение отредактировал(а) opjox - 9.5.2008, 00:34

Для QList (и прочие кутешные классы) вполне нормально возвращать коллекцию. Копируется только внутренний указатель (при изменении, если несколько физических объектов владеют этим указателем - делается копия коллекции).

Примечание: это относится  только к объектам реализованным в стиле COW (copy_on_write) 
 



Это сообщение отредактировал(а) mes - 8.5.2008, 20:57

static
а вообще надо смотреть по ситуации



ага
оно включено во всей cpp-шке и так - то есть ВСЕ функции могут попортить переменную