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

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

Если нет в ANSI, значит есть вероятность существования компилятора, в котором это не будет работать.
И какие могут быть претензии к создателю компилятора при этом, если этого нет в стандарте ?

Добавлено через 5 минут и 57 секунд
Первое сомнение изложил.
Второе, всегда в литературе почему-то работают с динамической памятью , где с указателем на статические внутренние переменные получается удобней.

вернуть адрес из функции - то по твоему "возможность недокументированная" ?

чего это нет в стандарте? Там есть упоминание о том, что время жизни такой переменной - время выполнения программы? Есть. 
Значит она там будет всегда, когда бы мы к ней не обратились.
Да она сама (статическая переменная) не видна вне функции, в которой объявлена, и против этого  мы тоже не идем, мы ведь не пытаемся увеличить видимость переменной (дико звучит   ) а передаем на нее указатель/ссылку.
Что незаконного в действиях?


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

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

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

А разве деструкторы статических объектов вызываются не в порядке, обратном вызову конструкторов? Так реализовать проще, имхо.

Не совсем понятно.  Все глобальные переменные инициализируются до мейн(), функцию любую можно вызвать только после входа в мейн(). Ну или до мэйн() можно при создании глобального объекта вызвать внешнюю функцию из конструктора.
Тогда при чем тут порядок инициализации ? С тем же успехом можно либо в мэйн() вначале задать значение А, и В(А). Либо сделать это в той же функции при построении глобального объекта.
В общем интересно. Как-нить может сам набреду на пример.   

Random13, имеется ввиду нечто подобное:

ну и по аналогии со статическими переменными та же история.

вот о чем речь: файл aaa.cpp:файл bbb.cpp:файл ccc.cpp:А теперь скомпилируй их командой: g++ aaa.cpp bbb.cpp ccc.cpp и запусти, увидишь вывод:А если g++ ccc.cpp bbb.cpp aaa.cpp:

Речь ведь идет не о вложенных напрямую объектах, а о том что переменная A в деструкторе за каким-то лешим лезет к переменной B, тоже статической. Т.к. порядок создания их не определен, точно так же не определен и порядок разрушения. То, что он обратный созданию, не спасает - при создании объекту A до объекта B может быть до лампочки.
Это был ответ bsa... про порядок вызова деструкторов ...

Это сообщение отредактировал(а) Earnest - 4.12.2007, 16:47

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

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

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

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