Windows 8 — Winrt включить использование пространств имен в заголовочном файле?
Возможный дубликат:
«Использование пространства имен» в заголовках c ++
Я разработчик c # в мире WPF, но я решил сделать всю свою разработку Winrt на C ++.
Одна вещь, которую я запутался, это использование (или нет) using операторы в заголовочных файлах (в отличие от ввода полностью определенных имен типов).
Это намного проще иметь using заявления в заголовочных файлах. Многие образцы Microsoft Winrt включают using операторы в заголовках, что делает код ясным и легким для чтения.
Тем не менее, я просматривал примеры с ++ в предварительном просмотре новой книги Джона Петцольда, и он требует, чтобы заголовки были свободны от всех using заявления.
Я не понимаю плюсы и минусы, и когда я в Google, я получаю много противоположных мнений.
Может ли кто-нибудь дать мне четкое объяснение этой проблемы, поскольку она связана с миром Winrt (я не заинтересован в C ++ в других средах)
Спасибо
Решение
В C ++ очень привычно избегать using пространства имен в заголовочных файлах по нескольким причинам.
В отличие от C #, C ++ не имеет удобной системы модулей. Все, что вы делаете в заголовке, влияет на каждый файл, который включает его. Так что, если один заголовок имеет using namespace, если эффективно загрязняет не только сам заголовочный файл, но и все файлы, которые его содержат. Это может привести к неожиданным конфликтам имен.
Так что в C ++ наиболее распространенным соглашением является следующее: никогда не ставлю using namespace в шапке. В исходных файлах вы можете сделать это, если хотите, но многие люди избегают этого даже там.
Другая причина состоит в том, что это может фактически помочь читаемости:
Если я ссылаюсь на vector<int>не очень понятно что это является. Это может быть любой векторный класс, определенный где-либо в любом из моих включенных заголовков.
Но если я напишу std::vector<int>тогда я знаю что это стандартный заголовок библиотеки. Он говорит мне, откуда приходит тип. Я думаю, что это делает код более понятным и легким для чтения.
Конечно, есть приемы, которые вы можете использовать, чтобы сделать это более управляемым, если вы часто ссылаетесь на определенные типы или если у определенных пространств имен длинные длинные подробные имена.
Длинные имена пространства имен могут быть псевдонимами:
namespace foo = VeryLongNamespaceName;
// now I can do foo::bar instead of VeryLongNamespaceName::bar
или отдельные имена могут быть импортированы из пространства имен:
using std::cout;
// now I can refer to `cout` without the std prefix
Конечно, это не случайно, что разработчики C ++ склонны использовать плоские иерархии пространств имен и короткие имена пространств имен.
Почти вся стандартная библиотека C ++ находится в std пространство имен, которое немного легче набрать, чем эквивалент .NET. (std::vector<T> против System.Collections.Generic.List<T>). Короткие имена и плоская иерархия означают, что вы можете жить без using namespace заявления.
Может ли кто-нибудь дать мне четкое объяснение этой проблемы, поскольку она связана с миром Winrt (я не заинтересован в C ++ в других средах)
В этом контексте не существует понятия «мир WinRT». Если вы пишете код C ++ в своем приложении WinRT, вы должны следовать конвенциям C ++ и передовым практикам. Если вы пишете код C # в своем приложении WinRT, вы должны следовать рекомендациям C # и так далее.
Нигде в руководящих принципах WinRT не говорится «Пожалуйста, не обращайте внимания на все, что вы обычно делаете на языке, который вы используете». WinRT — это API, а не язык.
Что касается того, почему образцы Microsoft делают иначе: они являются образцами. Их цель — проиллюстрировать конкретные концепции и дать вам отправную точку, а не научить вас писать хороший код в целом. Предполагается, что вы можете взять концепции, которые они иллюстрируют, и вписать их в свой собственный код, не копируя различные ярлыки, взятые в примерах. Во многих примерах также отсутствует код обработки ошибок по той же причине. Это не имеет значения для целей образца, но, конечно, не имеет значения в реальном приложении.
Другие решения
Других решений пока нет …