Информация о пространстве имен ухудшает читабельность в C ++ - PullRequest
4 голосов
/ 15 января 2020

Я новичок в C++ и имел фон в C. Одна вещь, которую мне довольно сложно принять, - это часто использовать оператор видимости, например std::. Ну, я бы избежал его использования, поставив using namespace std в начале моего исходного кода, но многие люди не используют этот метод, поскольку они думают, что это может укусить их в будущем.

Кроме того, visual-studio также показывает сообщения об ошибках / предупреждения вдоль оператора области действия, например,

cannot convert from 'std::vector<int,std::allocator<_Ty>> *' to 'std::shared_ptr<std::vector<int,std::allocator<_Ty>>>'

Хотя приведенное выше сообщение является многословным, но это такая боль читать это (?). Я думаю, что это может быть просто читать, если бы он был в такой форме

cannot convert from 'vector<int,allocator<_Ty>> *' to 'shared_ptr<vector<int,allocator<_Ty>>>'

1) Почему все используют std::, даже для cout, cin, endl? В любом случае, зачем кому-то использовать метки для каких-то других целей?

2) Есть ли обходной путь в Visual Studio, чтобы не показывать мне сообщения об ошибках / сообщениях / подсветке синтаксиса с префиксом std::?

Ответы [ 4 ]

4 голосов
/ 15 января 2020

Хотя, как указано в комментариях, код типа using namespace std; является считается плохой практикой , вы можете избежать повторного использования префикса пространства имен в коде, подобном std::cout, указав индивидуальный элементы с областью видимости в using операторах.

Примерно так:

using std::cout;  //
using std::cin;   // You can, from then on, just use 'cout', 'cin' and 'endl'
using std::endl;  //

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

3 голосов
/ 15 января 2020

Для начинающих существует разница в поиске имен для квалифицированных и неквалифицированных имен.

Рассмотрим, например, следующую программу.

#include <iostream>

class A
{
private:    
    int x = 10;

public:
    operator int() const { return x; }
    friend void f( const A & )
    {
        std::cout << "f( const A & )\n";
    }
};

void f( int )
{
    std::cout << "f( int )\n";
}

int main() 
{
    const A a;

    f( a );

    ::f( a );

    return 0;
}

Вывод программы:

f( const A & )
f( int )

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

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

Существуют ситуации, когда вам нужно использовать явную или неявную директиву using.

Например, если вы хотите использовать объявления из пространства имен std::placeholders или когда вы хотите объявить inline Пространство имен. Но сфера применения этих директив обычно очень ограничена. Другой пример - использование объявлений. Но снова попробуйте сделать их прицелы как можно меньше.

1 голос
/ 15 января 2020

Внутри ограниченной области, например, внутри функции, логично использовать using namespace std или любое другое using.

Повторение имен пространства имен утомительно, когда вы можете избежать этого бесплатно. Я видел много кода, зараженного std::, особенно когда дело доходит до использования std :: forward, std :: move, std :: function, std :: thread et c.

C ++ ключевые слова, такие как using, существуют по причине; Безоговорочно говорить, что «использование пространства имен std плохо» - ошибочно.

0 голосов
/ 15 января 2020

Чтобы ответить на ваш 2), я считаю, что ответ «Нет, нет способа изменить способ, которым VS записывает сообщения об ошибках, чтобы напрягать все std::».

Хорошая новость заключается в том, что эти сообщения об ошибках были намного хуже . Вы получите сообщения об ошибках для всех N вариаций данного шаблона, а затем должны будете проанализировать крошечное значение c сигнала из океана шума. Не весело. Небеса помогут вам, если вы используете вложенные шаблоны, такие как std::vector<std::vector<std::string> > >.

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

О, и >> всегда использовался для анализа в качестве оператора потока, поэтому вам пришлось добавить пробелы между > s для вложенного шаблона. UP HILL, ОБА ПУТЕЙ !!!

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