remove anonimous namespaces

[GoogleCodeExporter]

What feature do you require in pugixml?
Прошу отказаться от использования 
анонимных пространств имен
What do you need this feature for?
Анонимным нэймспейсам некоторые 
компиляторы (gcc) генерируют уникальные 
имена. В результате этого собранные 2раза 
бинарники отличаются контрольными 
суммами. Для некоторых продуктов это 
недопустимо ( сертификация ). 

Original issue reported on code.google.com by blackice...@gmail.com on 19 Oct 2010 at 12:25

[GoogleCodeExporter]

С одной стороны, мне не сложно убрать 
анонимные неймспейсы.

С другой стороны, я хотел бы понимать 
проблему, прежде чем ее решать... за 
несколько запусков я не смог получить 
разные объектники с помощью mingw44, mingw45.
Также за несколько запусков сборки exe 
файлов я все время получал разные exe файлы, 
но отличия - только в двух байтах в 
заголовке (timestamp).

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

Original comment by arseny.k...@gmail.com on 19 Oct 2010 at 4:26

[GoogleCodeExporter]

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

Original comment by blackice...@gmail.com on 19 Oct 2010 at 6:37

[GoogleCodeExporter]

Ага, я разобрался - зависит от версии gcc.

В версиях 4.4.0, 4.4.3, 4.5.0 все ок.
В версиях 3.4.5, 4.0.1, 4.2.1 имя неймспейса 
содержит указатель.

Видимо, в 4.3 или в 4.4 это исправили.
Ок, я уберу анонимные неймспейсы.

Original comment by arseny.k...@gmail.com on 19 Oct 2010 at 7:03

• Changed state: Accepted

[GoogleCodeExporter]

Стабилизировать результат сборки в случае 
использования старого gcc можно двумя 
способами:

- избавиться от анонимных неймспейсов
- передать ключ компиляции -frandom-seed=123456789

Анонимные неймспейсы в случае новых gcc (а 
также других достаточно новых 
компиляторов) обладают преимуществом - они 
помечают символы внутри себя как приватные 
для translation unit (я не могу добиться этого 
другим кроссплатформенным способом для 
классов), что уменьшает таблицу экспорта 
для gcc.

Я поисследую эту проблему для других 
компиляторов (некоторые из них тоже 
генерируют псевдослучайные имена в 
объектниках - неизвестно, доходят ли они до 
dll/exe), но если gcc старых версий будет 
единственным с такой проблемой, то 
возможно анонимные неймспейсы так и 
останутся анонимными.

Original comment by arseny.k...@gmail.com on 22 Oct 2010 at 5:28

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

У нас проблема была на совсем старом gcc 2.95
Если проблема специфическая, то возможно в 
основную ветку и ненадо вносить.
Как вариант добавить макросы:
/// anonimous
#define BEGIN_PRIVATE_NAMESPACE namespace {
#define END_PRIVATE_NAMESPACE }
/// non anonimous
#define BEGIN_PRIVATE_NAMESPACE namespace private {
#define END_PRIVATE_NAMESPACE } using namespace private;

Original comment by blackice...@gmail.com on 22 Oct 2010 at 5:37

[GoogleCodeExporter]

В других компиляторах в основном проблем 
нет - они либо генерируют имя без всяких 
псевдослучайных компонентов, либо 
фиксируют seed, т.е. от сборки к сборке 
результат не меняется. Исключениями 
являются компиляторы Borland и Digital Mars, но в них 
в DLL/EXE эти символы не попадают.

Итого, в основной ветке на данный момент 
останутся анонимные неймспейсы (возможно, 
это решение придется закастомизировать 
макросами если я таки сделаю когда-нибудь 
header-only вариант сборки - пока без макросов). 
На старых gcc можно использовать -frandom-seed.

Original comment by arseny.k...@gmail.com on 22 Oct 2010 at 7:25

• Changed state: WontFix