C++ хороший стиль кодирования - всегда полностью соответствуют типам библиотек?

Question

Что обычно считается хорошим стилем кодирования в C++, где вы используете типы из стандартной библиотеки? Например, если у меня есть директива using namespace std;, вы по-прежнему ожидаете увидеть типы библиотек, полностью соответствующие следующим требованиям: std::string или приемлемо ли использовать только string в качестве идентификатора типа?

Если вы полностью квалифицируете себя, можете ли вы объяснить обоснование этого?

Answer 1

полностью соответствует заголовочным файлам. импортируйте пространство имен в .cpp-файлы.

сохраняет глобальное пространство имен от того завален простым #include

Answer 2

Я предпочитаю использовать:

using std::string; 
string whatever; 

чем полностью приведение имен в

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

Для библиотек, отличных от стандартных, я хотел бы квалифицировать, если пространства имен вложенных пространств не слишком длинны, если это просто typedef для значимого имени, которое включает имя библиотеки или что-то в этом роде.

Answer 3

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

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

Answer 4

namespace в основном введен, чтобы минимизировать конфликты имен символов, таких как функции, класса и переменные. Это нормально, что вы просто используете string, чем std::string, если ваша собственная библиотека не имеет string в своем собственном пространстве. Я практически не использую очень распространенное пространство имен, например std.

Answer 5

Полностью субъективный вопрос: Я бы сказал, допустимо просто использовать строку. IDE/компилятор достаточно умны, чтобы узнать, что вы имеете в виду. Если у вас есть объекты с тем же именем, например, 2 типа строк. Тогда у вас другая проблема, потому что компилятор не будет знать, что вы имеете в виду, и кодер не будет знать, что вы имеете в виду.

Другая причина не использовать имена библиотек из-за загромождения кода: В C# system.xml.xmltextreader просто перебор. XmlTextReader достаточно, чтобы понять, что это такое. Где он находится почти никогда не проблема

Answer 6

я, как правило, придерживаться двух правил:

• В заголовочных файлах, вы хотите, чтобы квалифицировать имена типов с полным имен и никогда, никогда не хотят, чтобы положить что-то вроде using namespace std;, так как это может вызвать или вызвать интересные проблемы из-за неожиданных конфликтов имен, которые вам нужно будет отслеживать в 1 утра.
• В файлах реализации я обычно использую символы, которые я использую из других пространств имен, используя using std::string; или аналогичные.На самом деле, я не согласен с этим на 100%, поскольку я часто не занимаюсь пространством имен std, но занимаюсь пространством имен проектов, но это личное предпочтение. Никогда, никогда не ставьте using namespace somethingorother; над любым #include.

Answer 7

В общем, я бы предпочел (1) в используя директиву как using std::string; string hello; как то, что Хименес было отмечено ранее; (2) я также использовать анонимных имена, впоследствии использовать используя директиву пространства имен импортировать все имена в мои анонимное пространство имен, как этот namespace { using namespace std; // or using std::string string blah_blah_blah; }

Answer 8

Просто за то, что он стоит, есть несколько вещей, которые вы можете сделать путем вытягивания пространства имен с помощью директивы using, которую вы не можете сделать квалификационными именами. Канонический пример - это, вероятно, запись общей функции сортировки. Если для отсортированного типа был определен swap, вы хотите его использовать, но если он не имеет собственного swap, вы хотите использовать std::swap.

Для достижения этой цели, вы можете написать код, как:

using namespace std; 
// ... 
template <class T> 
void my_sort(std::vector<T> &x) { 
    // ... 
    if (x[j] < x[k]) 
     swap(x[j], x[k]); 

Теперь, если есть в пространстве имен любого типа сортируется в swap, он будет найден аргумент зависимого поиска. Если нет, std::swap будет найден, потому что вы сделали его видимым с помощью директивы using.

Answer 9

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

• Избегайте using namespace в заголовочных файлах
• Использование using namespace в источнике для «очевидных» библиотек (например, std или библиотеку, чтобы проверить в тестовой программе)
• Вы можете псевдоним пространства имен в вашем источнике, чтобы сохранить его короткий и считываемый:

Пример

namespace fs = boost::filesystem; 
bool fileExists = fs::exists(fs::path(filePath)); 

EDIT, для полноты: using namespace в заголовочных файлах загрязняет исходные файлы с импортным namepaces в неочевидного способа ("Нуф объяснение этого уже в этой теме).

Answer 10

Я всегда полностью квалифицировался в заголовках. Я никогда не добавлял утверждения «using ...» в заголовки.

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

Answer 11

Если вы не в полной мере претендовать , у вас будет большая проблема при перемещении встроенных методов из заголовков в файлы CPP или наоборот, и вы определенно хотите один стиль в своих проектах.

В противном случае это не проблема, иногда я квалифицируюсь, несмотря на существующую инструкцию using.В заголовках это проблема, если она не находится в пределах области:

// somefile.h 
namespace VisionMap 
{ 
    namespace X 
    { 
     using namespace Y; // Does not impact the header's user, 
           // as would if it was in the global scope. 
    } 
}