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

При большом размере текущих библиотек C/C++, таких как STL, Win32, Boost, posix и т. д., возникает вопрос, какие идентификаторы являются проблематичными. Даже с пространствами имен приятно иметь возможность выбирать идентификаторы, которые не конфликтуют с наиболее часто используемыми идентификаторами других библиотек, при разработке новой библиотеки, предназначенной для совместной работы с существующими.

По крайней мере, для стандартных библиотек C++ (включая 0x) должны быть доступны списки. Разумно было бы предположить, что кто-то сделал для этой цели инструмент, который считывает набор заголовочных файлов и создает список всех имен, упорядоченных по пространству имен. Кто знает такое средство? Предпочтительно, чтобы инструмент читал все заголовки в дереве каталогов, а не только те, которые включены в конкретный файл cpp.


c++ list identifier
person Bengt Gustafsson    schedule 22.01.2011    source источник
comment
Doxygen - это инструмент, который вам нужен?   -  person Steve Jessop    schedule 22.01.2011

Ответы (2)


arrow_upward
4
arrow_downward

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

Я понимаю, что довольно много библиотек делают это, но эта попытка в корне ошибочна.

Не создавайте свои идентификаторы так, чтобы они не конфликтовали, создавайте их так, чтобы они были четкими, короткими и описательными. Это должны быть единственные критерии.

Конфликт идентификаторов — решаемая проблема благодаря пространствам имен. При правильном использовании конфликтов имен просто не возникает.

person Konrad Rudolph    schedule 22.01.2011
comment
При правильном использовании конфликтов имен просто не возникает. - за исключением иногда с ADL. Например, крайне не рекомендуется определять свободную функцию swap с семантикой, отличной от семантики std::swap. На практике это единственная известная мне функция, которая, как ожидается, будет перегружена через ADL, но в принципе каждый раз, когда библиотека вводит такую ​​функцию, она загрязняет все пространства имен. Если какой-либо вызывающий объект выполняет using std::sort, чтобы вызвать sort без полной квалификации, то он потенциально может привести к конфликту с любым пространством имен, содержащим свою собственную функцию sort. - person Steve Jessop; 22.01.2011
comment
@Steve: правда, но это не такая уж большая проблема, потому что ее можно исправить явной квалификацией, как только произойдет конфликт. Это только локальное изменение (если только using не используется глобально в заголовке, и в этом случае все рушится). - person Konrad Rudolph; 22.01.2011
comment
@Конрад: справедливое замечание. Без пространств имен эквивалентное столкновение в C — кошмар. - person Steve Jessop; 22.01.2011
comment
Я, конечно, знаю, что, кроме имен макросов, имена в C++ не конфликтуют при правильном использовании пространства имен. Тем не менее, избавление от необходимости квалифицировать большой процент идентификаторов является любезностью для пользователей библиотеки. Кроме того, я планировал использовать макросы, и это делало необходимость более важной. Сейчас, как всегда, многие из вас будут протестовать: НЕНОНО, не используйте макросы. Но в данном случае реальной альтернативы нет. Писать код от руки будет настолько утомительно, что библиотека будет совершенно бесполезна. С макросами действительно очень аккуратно. - person Bengt Gustafsson; 22.01.2011
comment
@Bengt: использовать макросы можно. Но эти макросы должны (!!!) начинаться с идентификатора конкретной библиотеки, например. MYLIBRARY_SOME_MACRO. Таким образом (и только таким образом) исключается опасность конфликта имен. В противном случае ваша библиотека должна считаться сломанной. - person Konrad Rudolph; 22.01.2011
comment
Ну я конечно все это знаю. И именно поэтому я хочу сканировать идентификаторы. Причина этого, в свою очередь, заключается в том, что в частях кода, использующих библиотеку, будет очень высокая плотность макросов, и добавление префиксов к ним всем сделает исходный код гораздо менее читаемым. Кроме того, поскольку я сделал все возможное, чтобы избежать как можно большего количества макросов, пользователю будет довольно сложно узнать, какие объекты являются макросами, поэтому префикс увеличивает порог обучения, а простота использования является основной целью! - person Bengt Gustafsson; 24.01.2011

arrow_upward
-1
arrow_downward

Как насчет использования egrep? [бормочет, чтобы получить 30 символов]

person Yttrill    schedule 22.01.2011
comment
1. Потому что написать регулярное выражение для этого было бы непросто. Для этого вам понадобится более мощный инструмент. 2. Поскольку расположение всех файлов, которые могут быть #included, вероятно, заранее неизвестны. - person Billy ONeal; 22.01.2011
comment
Да, регулярное выражение было бы непросто (возможно?) разработать. Нет, я не хочу, чтобы дерево #include определяло, что сканировать, меня интересует, что находится в библиотеке, то есть все файлы в каталоге (дереве). - person Bengt Gustafsson; 22.01.2011