Tôi đã được người khác nói rằng viết using namespace std;mã là sai và thay vào đó tôi nên sử dụng std::coutvà std::cintrực tiếp.

Tại sao được using namespace std;coi là một thực hành xấu? Là nó không hiệu quả hay nó có nguy cơ khai báo các biến mơ hồ (các biến có cùng tên với một hàm trong stdkhông gian tên)? Nó có ảnh hưởng đến hiệu suất?

Điều này không liên quan đến hiệu suất. Nhưng hãy xem xét điều này: bạn đang sử dụng hai thư viện có tên Foo và Bar:

using namespace foo;
using namespace bar;

Mọi thứ đều hoạt động tốt, và bạn có thể gọi Blah()từ Foo và Quux()từ Bar mà không gặp vấn đề gì. Nhưng một ngày nào đó bạn nâng cấp lên phiên bản mới của Foo 2.0, giờ đây cung cấp một chức năng được gọi là Quux(). Bây giờ bạn đã có một cuộc xung đột: Cả Foo 2.0 và Bar nhập Quux()vào không gian tên toàn cầu của bạn. Điều này sẽ mất một số nỗ lực để khắc phục, đặc biệt là nếu các tham số chức năng xảy ra khớp.

Nếu bạn đã sử dụng foo::Blah()và bar::Quux(), thì việc giới thiệu foo::Quux()sẽ là một sự kiện không.

Tôi đồng ý với tất cả những gì Greg viết , nhưng tôi muốn nói thêm: Nó thậm chí có thể trở nên tồi tệ hơn Greg đã nói!

Thư viện Foo 2.0 có thể giới thiệu một chức năng, Quux()đó là một kết hợp tốt hơn rõ ràng cho một số cuộc gọi của bạn Quux()so với bar::Quux()mã của bạn được gọi trong nhiều năm. Sau đó, mã của bạn vẫn biên dịch , nhưng nó âm thầm gọi hàm sai và không biết chúa là gì. Điều đó tồi tệ như mọi thứ có thể nhận được.

Hãy ghi nhớ rằng stdkhông gian tên có tấn số nhận dạng, nhiều trong số đó là rất cái chung (nghĩ list, sort, string, iterator, vv) mà rất có khả năng xuất hiện trong mã khác nữa.

Nếu bạn cho rằng điều này không thể xảy ra: Có một câu hỏi được đặt ra ở đây trên Stack Overflow, nơi chính xác điều này đã xảy ra (hàm sai gọi là do std::tiền tố bị bỏ qua ) khoảng nửa năm sau khi tôi đưa ra câu trả lời này. Đây là một ví dụ khác, gần đây hơn của một câu hỏi như vậy. Vì vậy, đây là một vấn đề thực sự.

Đây là một điểm dữ liệu nữa: Nhiều, nhiều năm trước, tôi cũng từng thấy khó chịu khi phải thêm tiền tố vào mọi thứ từ thư viện chuẩn std::. Sau đó, tôi đã làm việc trong một dự án nơi quyết định ban đầu rằng cả hai usingchỉ thị và tuyên bố đều bị cấm ngoại trừ phạm vi chức năng. Đoán xem cái gì? Hầu hết chúng ta mất vài tuần để làm quen với việc viết tiền tố và sau một vài tuần nữa, hầu hết chúng ta thậm chí đồng ý rằng nó thực sự làm cho mã dễ đọc hơn . Có một lý do cho điều đó: Cho dù bạn thích văn xuôi ngắn hơn hay dài hơn là chủ quan, nhưng các tiền tố khách quan làm tăng thêm sự rõ ràng cho mã. Không chỉ trình biên dịch, mà cả bạn, cũng thấy dễ dàng hơn để xem định danh nào được nhắc đến.

Trong một thập kỷ, dự án đó đã phát triển để có vài triệu dòng mã. Vì các cuộc thảo luận này lặp đi lặp lại, tôi đã từng tò mò về mức độ thường xuyên phạm vi chức năng (được phép) usingthực sự được sử dụng trong dự án. Tôi đã tìm các nguồn cho nó và chỉ tìm thấy một hoặc hai chục địa điểm được sử dụng. Đối với tôi điều này chỉ ra rằng, một khi đã thử, các nhà phát triển không thấy std::đủ đau đớn khi sử dụng các chỉ thị ngay cả sau mỗi 100 kLoC ngay cả khi nó được phép sử dụng.

Điểm mấu chốt: Hoàn toàn tiền tố mọi thứ không gây hại gì, mất rất ít thời gian để làm quen và có những lợi thế khách quan. Cụ thể, nó làm cho mã dễ hiểu hơn bởi trình biên dịch và bởi các trình đọc của con người - và đó có lẽ nên là mục tiêu chính khi viết mã.

Vấn đề với việc đưa using namespacevào các tệp tiêu đề của các lớp của bạn là nó buộc bất kỳ ai muốn sử dụng các lớp của bạn (bằng cách bao gồm các tệp tiêu đề của bạn) cũng phải 'sử dụng' (tức là nhìn thấy mọi thứ trong) các không gian tên đó.

Tuy nhiên, bạn có thể cảm thấy thoải mái khi đặt câu lệnh sử dụng trong các tệp (riêng tư) * .cpp của mình.

Xin lưu ý rằng một số người không đồng ý với câu nói "cảm thấy thoải mái" của tôi như thế này - bởi vì mặc dù một usingtuyên bố trong tệp cpp tốt hơn trong tiêu đề (vì nó không ảnh hưởng đến những người bao gồm tệp tiêu đề của bạn), nhưng họ nghĩ rằng nó vẫn không tốt (vì tùy thuộc vào mã, nó có thể làm cho việc thực hiện lớp khó khăn hơn để duy trì). Mục C-Super Super FAQ này cho biết,

Lệnh sử dụng tồn tại cho mã C ++ cũ và để dễ dàng chuyển sang không gian tên, nhưng có lẽ bạn không nên sử dụng nó một cách thường xuyên, ít nhất là không phải trong mã C ++ mới của bạn.

Câu hỏi thường gặp gợi ý hai lựa chọn thay thế:

• Một khai báo sử dụng:

  using std::cout; // a using-declaration lets you use cout without qualification
  cout << "Values:";
  

• Chỉ cần gõ std ::

  std::cout << "Values:";

Gần đây tôi đã gặp phải một khiếu nại về Visual Studio 2010 . Hóa ra khá nhiều tập tin nguồn có hai dòng này:

using namespace std;
using namespace boost;

Rất nhiều tính năng Boost đang đi vào tiêu chuẩn C ++ 0x và Visual Studio 2010 có rất nhiều tính năng C ++ 0x, vì vậy đột nhiên các chương trình này không được biên dịch.

Do đó, tránh using namespace X;là một hình thức chứng minh trong tương lai, một cách đảm bảo thay đổi thư viện và / hoặc các tệp tiêu đề đang sử dụng sẽ không phá vỡ chương trình.

Phiên bản ngắn: không sử dụng usingkhai báo toàn cầu hoặc chỉ thị trong tệp tiêu đề. Hãy sử dụng chúng trong các tập tin thực hiện. Dưới đây là những gì Herb Sutter và Andrei Alexandrescu nói về vấn đề này trong Tiêu chuẩn mã hóa C ++ (được nhấn mạnh là của tôi):

Tóm lược

Việc sử dụng không gian tên là để thuận tiện cho bạn, không phải để bạn gây ra cho người khác: Không bao giờ viết một tuyên bố sử dụng hoặc chỉ thị sử dụng trước một lệnh #incoide.

Hệ quả: Trong các tệp tiêu đề, không viết mức không gian tên bằng cách sử dụng các lệnh hoặc sử dụng khai báo; thay vào đó, rõ ràng không gian tên đủ điều kiện tất cả các tên. (Quy tắc thứ hai tuân theo quy tắc thứ nhất, bởi vì các tiêu đề không bao giờ có thể biết những tiêu đề nào khác có thể xuất hiện sau chúng.)

Thảo luận

Tóm lại: Bạn có thể và nên sử dụng không gian tên bằng cách sử dụng các khai báo và chỉ thị một cách tự do trong các tệp triển khai của mình sau các lệnh #incoide và cảm thấy tốt về nó. Mặc dù nhiều lần khẳng định ngược lại, không gian tên sử dụng khai báo và chỉ thị không phải là xấu xa và chúng không đánh bại mục đích của không gian tên. Thay vào đó, chúng là những gì làm cho không gian tên có thể sử dụng .

Không nên sử dụng usingchỉ thị ở phạm vi toàn cầu, đặc biệt là trong các tiêu đề. Tuy nhiên, có những tình huống phù hợp ngay cả trong tệp tiêu đề:

template <typename FloatType> inline
FloatType compute_something(FloatType x)
{
    using namespace std; // No problem since scope is limited
    return exp(x) * (sin(x) - cos(x * 2) + sin(x * 3) - cos(x * 4));
}

Điều này tốt hơn trình độ rõ ràng ( std::sin, std::cos...), vì nó ngắn hơn và có khả năng làm việc với các loại dấu phẩy động do người dùng xác định (thông qua tra cứu phụ thuộc đối số (ADL)).

Không sử dụng nó trên toàn cầu

Nó được coi là "xấu" chỉ khi được sử dụng trên toàn cầu . Bởi vì:

• Bạn làm lộn xộn không gian tên bạn đang lập trình.
• Người đọc sẽ gặp khó khăn khi xem một định danh cụ thể đến từ đâu, khi bạn sử dụng nhiều using namespace xyz.
• Bất cứ điều gì đúng với những người đọc khác về mã nguồn của bạn thậm chí còn đúng hơn đối với người đọc thường xuyên nhất về nó: chính bạn. Trở lại sau một hoặc hai năm và xem ...
• Nếu bạn chỉ nói về using namespace stdbạn có thể không nhận thức được tất cả những thứ bạn lấy - và khi bạn thêm cái khác #includehoặc chuyển sang bản sửa đổi C ++ mới, bạn có thể gặp phải xung đột tên mà bạn không biết.

Bạn có thể sử dụng nó cục bộ

Đi trước và sử dụng nó một cách tự do (gần như). Điều này, tất nhiên, ngăn bạn khỏi sự lặp lại std::- và sự lặp lại cũng tệ.

Một thành ngữ để sử dụng nó cục bộ

Trong C ++ 03 có một thành ngữ - mã soạn sẵn - để thực hiện một swapchức năng cho các lớp của bạn. Có ý kiến ​​cho rằng bạn thực sự sử dụng một địa phương using namespace std- hoặc ít nhất là using std::swap:

class Thing {
    int    value_;
    Child  child_;
public:
    // ...
    friend void swap(Thing &a, Thing &b);
};
void swap(Thing &a, Thing &b) {
    using namespace std;      // make `std::swap` available
    // swap all members
    swap(a.value_, b.value_); // `std::stwap(int, int)`
    swap(a.child_, b.child_); // `swap(Child&,Child&)` or `std::swap(...)`
}

Điều này thực hiện phép thuật sau:

• Trình biên dịch sẽ chọn std::swapfor value_, tức là void std::swap(int, int).
• Nếu bạn có quá tải void swap(Child&, Child&)thực hiện trình biên dịch sẽ chọn nó.
• Nếu bạn không có quá tải, trình biên dịch sẽ sử dụng void std::swap(Child&,Child&)và thử trao đổi tốt nhất.

Với C ++ 11, không có lý do gì để sử dụng mẫu này nữa. Việc thực hiện std::swapđã được thay đổi để tìm một sự quá tải tiềm năng và chọn nó.

Nếu bạn nhập các tập tin tiêu đề phải bạn đột nhiên có những cái tên như hex, left, plushoặc counttrong phạm vi toàn cầu của bạn. Điều này có thể gây ngạc nhiên nếu bạn không biết std::có chứa những tên này. Nếu bạn cũng cố gắng sử dụng những tên này cục bộ, nó có thể dẫn đến một số nhầm lẫn.

Nếu tất cả các công cụ tiêu chuẩn nằm trong không gian tên riêng của nó, bạn không phải lo lắng về xung đột tên với mã của bạn hoặc các thư viện khác.

Một lý do khác là bất ngờ.

Nếu tôi thấy cout << blah, thay vì std::cout << blahtôi nghĩ: đây là coutgì? Có phải là bình thường cout? Nó có gì đặc biệt không?

Các lập trình viên có kinh nghiệm sử dụng bất cứ điều gì giải quyết vấn đề của họ và tránh bất cứ điều gì tạo ra vấn đề mới và họ tránh các chỉ thị sử dụng cấp độ tệp tiêu đề vì lý do chính xác này.

Các lập trình viên có kinh nghiệm cũng cố gắng tránh trình độ đầy đủ của các tên trong các tệp nguồn của họ. Một lý do nhỏ cho điều này là việc viết thêm mã khi không đủ mã trừ khi có lý do chính đáng . Một lý do chính cho việc này là tắt tra cứu phụ thuộc vào đối số (ADL).

Những lý do tốt là gì? Đôi khi các lập trình viên rõ ràng muốn tắt ADL, những lần khác họ muốn định hướng.

Vì vậy, sau đây là OK:

1. Chỉ thị sử dụng cấp độ chức năng và khai báo sử dụng bên trong triển khai chức năng
2. Khai báo cấp độ nguồn tệp trong tệp nguồn
3. (Đôi khi) chỉ thị sử dụng cấp độ tệp nguồn

Tôi đồng ý rằng nó không nên được sử dụng trên toàn cầu, nhưng nó không quá tệ khi sử dụng cục bộ, như trong a namespace. Đây là một ví dụ từ "Ngôn ngữ lập trình C ++" :

namespace My_lib {

    using namespace His_lib; // Everything from His_lib
    using namespace Her_lib; // Everything from Her_lib

    using His_lib::String; // Resolve potential clash in favor of His_lib
    using Her_lib::Vector; // Resolve potential clash in favor of Her_lib

}

Trong ví dụ này, chúng tôi đã giải quyết các xung đột tên tiềm năng và sự mơ hồ phát sinh từ thành phần của chúng.

Các tên được khai báo rõ ràng ở đó (bao gồm các tên được khai báo bằng cách sử dụng khai báo như His_lib::String) sẽ ưu tiên hơn các tên được truy cập trong phạm vi khác bằng cách sử dụng directive ( using namespace Her_lib).

Tôi cũng coi đó là một thực hành xấu. Tại sao? Chỉ một ngày, tôi nghĩ rằng chức năng của một không gian tên là phân chia công cụ, vì vậy tôi không nên làm hỏng nó bằng cách ném mọi thứ vào một túi toàn cầu.

Tuy nhiên, nếu tôi thường sử dụng 'cout' và 'cin', tôi viết: using std::cout; using std::cin;trong tệp .cpp (không bao giờ trong tệp tiêu đề như nó truyền bá #include). Tôi nghĩ rằng sẽ không có ai lành mạnh đặt tên cho một luồng couthay cin. ;)

Thật tuyệt khi thấy mã và biết những gì nó làm. Nếu tôi thấy std::couttôi biết đó là coutdòng stdthư viện. Nếu tôi thấy coutthì tôi không biết. Nó có thể là coutdòng của stdthư viện. Hoặc có thể có int cout = 0;mười dòng cao hơn trong cùng một chức năng. Hoặc một staticbiến có tên couttrong tập tin đó. Nó có thể là bất cứ điều gì.

Bây giờ, hãy lấy một triệu cơ sở mã dòng, không đặc biệt lớn và bạn đang tìm kiếm một lỗi, điều đó có nghĩa là bạn biết có một dòng trong một triệu dòng này không làm những gì nó phải làm. cout << 1;có thể đọc một cái static inttên cout, dịch nó sang trái một chút và ném đi kết quả. Tìm kiếm một lỗi, tôi phải kiểm tra xem. Bạn có thể thấy làm thế nào tôi thực sự thực sự thích nhìn thấy std::cout?

Đó là một trong những điều có vẻ là một ý tưởng thực sự tốt nếu bạn là một giáo viên và không bao giờ phải viết và duy trì bất kỳ mã nào để kiếm sống. Tôi thích xem mã ở đâu (1) Tôi biết nó làm gì; và, (2) Tôi tin tưởng rằng người viết nó biết nó làm gì.

Đó là tất cả về quản lý sự phức tạp. Sử dụng không gian tên sẽ kéo mọi thứ mà bạn không muốn, và do đó có thể khiến việc gỡ lỗi trở nên khó khăn hơn (tôi nói là có thể). Sử dụng std :: khắp nơi khó đọc hơn (nhiều văn bản hơn và tất cả những thứ đó).

Ngựa cho các khóa học - quản lý sự phức tạp của bạn như thế nào bạn có thể tốt nhất và cảm thấy có thể.

Xem xét

// myHeader.h
#include <sstream>
using namespace std;


// someoneElses.cpp/h
#include "myHeader.h"

class stringstream {  // Uh oh
};

Lưu ý rằng đây là một ví dụ đơn giản. Nếu bạn có các tệp có 20 bao gồm và nhập khác, bạn sẽ có rất nhiều phụ thuộc để tìm ra vấn đề. Điều tồi tệ hơn về nó là bạn có thể nhận được các lỗi không liên quan trong các mô-đun khác tùy thuộc vào các định nghĩa xung đột.

Điều đó không kinh khủng, nhưng bạn sẽ tự cứu mình khỏi đau đầu bằng cách không sử dụng nó trong các tệp tiêu đề hoặc không gian tên toàn cầu. Có thể được phép làm điều đó trong phạm vi rất hạn chế, nhưng tôi chưa bao giờ gặp vấn đề khi gõ thêm năm ký tự để làm rõ chức năng của mình đến từ đâu.

1. Bạn cần có khả năng đọc mã được viết bởi những người có phong cách khác nhau và ý kiến ​​thực hành tốt nhất so với bạn.

2. Nếu bạn chỉ sử dụng cout, không ai bị nhầm lẫn. Nhưng khi bạn có rất nhiều không gian tên bay xung quanh và bạn thấy lớp này và bạn không chắc chắn chính xác nó làm gì, có không gian tên rõ ràng đóng vai trò như một nhận xét sắp xếp. Bạn có thể thấy ngay từ cái nhìn đầu tiên, "ồ, đây là một hoạt động của hệ thống tập tin" hoặc "đó là công cụ mạng".

Sử dụng nhiều không gian tên cùng một lúc rõ ràng là một công thức cho thảm họa, nhưng sử dụng không gian tên JUST stdvà chỉ không gian tên stdkhông phải là vấn đề lớn theo quan điểm của tôi bởi vì việc xác định lại chỉ có thể xảy ra bởi mã của riêng bạn ...

Vì vậy, chỉ cần xem chúng có chức năng như các tên dành riêng như "int" hoặc "class" và đó là nó.

Mọi người nên dừng việc quá hậu môn về nó. Giáo viên của bạn đã đúng tất cả cùng. Chỉ cần sử dụng MỘT không gian tên; đó là toàn bộ điểm của việc sử dụng không gian tên ở vị trí đầu tiên. Bạn không được phép sử dụng nhiều hơn một cùng một lúc. Trừ khi nó là của riêng bạn. Vì vậy, một lần nữa, xác định lại sẽ không xảy ra.

Tôi đồng ý với những người khác ở đây, nhưng tôi muốn giải quyết các mối quan tâm về khả năng đọc - bạn có thể tránh tất cả điều đó bằng cách sử dụng typedefs ở đầu tệp, hàm hoặc khai báo lớp.

Tôi thường sử dụng nó trong khai báo lớp của mình vì các phương thức trong một lớp có xu hướng xử lý các kiểu dữ liệu tương tự (các thành viên) và typedef là một cơ hội để gán một tên có ý nghĩa trong ngữ cảnh của lớp. Điều này thực sự hỗ trợ khả năng đọc trong các định nghĩa của các phương thức lớp.

// Header
class File
{
   typedef std::vector<std::string> Lines;
   Lines ReadLines();
}

và trong việc thực hiện:

// .cpp
Lines File::ReadLines()
{
    Lines lines;
    // Get them...
    return lines;
}

như trái ngược với:

// .cpp
vector<string> File::ReadLines()
{
    vector<string> lines;
    // Get them...
    return lines;
}

hoặc là:

// .cpp
std::vector<std::string> File::ReadLines()
{
    std::vector<std::string> lines;
    // Get them...
    return lines;
}

Một ví dụ cụ thể để làm rõ mối quan tâm. Hãy tưởng tượng bạn có một tình huống trong đó bạn có hai thư viện foovà barmỗi thư viện có không gian tên riêng:

namespace foo {
    void a(float) { /* Does something */ }
}

namespace bar {
    ...
}

Bây giờ hãy nói rằng bạn sử dụng foovà barcùng nhau trong chương trình của riêng bạn như sau:

using namespace foo;
using namespace bar;

void main() {
    a(42);
}

Tại thời điểm này mọi thứ đều ổn. Khi bạn chạy chương trình của mình, 'Làm gì đó'. Nhưng sau đó, bạn cập nhật barvà giả sử nó đã thay đổi thành:

namespace bar {
    void a(float) { /* Does something completely different */ }
}

Tại thời điểm này, bạn sẽ gặp lỗi trình biên dịch:

using namespace foo;
using namespace bar;

void main() {
    a(42);  // error: call to 'a' is ambiguous, should be foo::a(42)
}

Vì vậy, bạn sẽ cần thực hiện một số bảo trì để làm rõ nghĩa 'a' foo::a. Điều đó là không mong muốn, nhưng may mắn là nó khá dễ dàng (chỉ cần thêm foo::vào trước tất cả các cuộc gọi để atrình biên dịch đánh dấu là mơ hồ).

Nhưng hãy tưởng tượng một kịch bản thay thế nơi thanh thay đổi thay vào đó trông như thế này:

namespace bar {
    void a(int) { /* Does something completely different */ }
}

Tại thời điểm này, cuộc gọi của bạn a(42)đột nhiên liên kết với bar::athay vì foo::avà thay vì thực hiện "một cái gì đó", nó thực hiện "một cái gì đó hoàn toàn khác". Không có cảnh báo trình biên dịch hoặc bất cứ điều gì. Chương trình của bạn chỉ âm thầm bắt đầu làm một cái gì đó hoàn thành khác với trước đây.

Khi bạn sử dụng một không gian tên, bạn sẽ gặp rủi ro như một kịch bản như thế này, đó là lý do tại sao mọi người không thoải mái khi sử dụng các không gian tên. Càng nhiều thứ trong một không gian tên, nguy cơ xung đột càng lớn, do đó mọi người có thể còn khó chịu hơn khi sử dụng không gian tên std(do số lượng vật trong không gian tên đó) so với các không gian tên khác.

Cuối cùng, đây là sự đánh đổi giữa khả năng ghi và độ tin cậy / khả năng bảo trì. Khả năng đọc cũng có thể là yếu tố, nhưng tôi có thể thấy các đối số cho điều đó đi cả hai chiều. Thông thường tôi sẽ nói độ tin cậy và khả năng bảo trì là quan trọng hơn, nhưng trong trường hợp này bạn sẽ liên tục trả chi phí có thể ghi cho một tác động độ tin cậy / khả năng bảo trì khá hiếm. Sự đánh đổi 'tốt nhất' sẽ quyết định dự án của bạn và các ưu tiên của bạn.

Một không gian tên là một phạm vi được đặt tên. Không gian tên được sử dụng để nhóm các khai báo liên quan và để tách các mục riêng biệt. Ví dụ: hai thư viện được phát triển riêng biệt có thể sử dụng cùng một tên để chỉ các mục khác nhau, nhưng người dùng vẫn có thể sử dụng cả hai:

namespace Mylib{
    template<class T> class Stack{ /* ... */ };
    // ...
}

namespace Yourlib{
    class Stack{ /* ... */ };
    // ...
}

void f(int max) {
    Mylib::Stack<int> s1(max); // Use my stack
    Yourlib::Stack    s2(max); // Use your stack
    // ...
}

Lặp lại một tên không gian tên có thể là một sự phân tâm cho cả người đọc và người viết. Do đó, có thể nói rằng các tên từ một không gian tên cụ thể có sẵn mà không cần bằng cấp rõ ràng. Ví dụ:

void f(int max) {
    using namespace Mylib; // Make names from Mylib accessible
    Stack<int> s1(max); // Use my stack
    Yourlib::Stack s2(max); // Use your stack
    // ...
}

Không gian tên cung cấp một công cụ mạnh mẽ để quản lý các thư viện khác nhau và các phiên bản mã khác nhau. Cụ thể, họ cung cấp các lựa chọn thay thế cho lập trình viên về cách rõ ràng để tạo một tham chiếu đến một tên không nhắm mục tiêu.

Nguồn: Tổng quan về ngôn ngữ lập trình C ++ của Bjarne Stroustrup

Một ví dụ trong đó using namespace stdđưa ra một lỗi biên dịch vì sự mơ hồ của số đếm, đây cũng là một hàm trong thư viện thuật toán.

#include <iostream>

using namespace std;

int count = 1;
int main() {
    cout << count << endl;
}

Nó không làm cho hiệu suất phần mềm hoặc dự án của bạn tồi tệ hơn. Việc bao gồm không gian tên ở đầu mã nguồn của bạn không phải là xấu. Việc đưa vào using namespace stdhướng dẫn thay đổi tùy theo nhu cầu của bạn và cách bạn đang phát triển phần mềm hoặc dự án.

Các namespace stdhàm chứa các biến và hàm tiêu chuẩn C ++. Không gian tên này hữu ích khi bạn thường sử dụng các hàm tiêu chuẩn C ++.

Như được đề cập trong trang này :

Câu lệnh sử dụng không gian tên std thường được coi là thực hành xấu. Thay thế cho câu lệnh này là chỉ định không gian tên mà định danh thuộc về sử dụng toán tử phạm vi (: :) mỗi lần chúng ta khai báo một kiểu.

Và xem ý kiến ​​này :

Không có vấn đề gì khi sử dụng "sử dụng không gian tên std" trong tệp nguồn của bạn khi bạn sử dụng nhiều không gian tên và biết chắc chắn rằng không có gì sẽ va chạm.

Một số người đã nói rằng việc bao gồm các using namespace stdtệp nguồn của bạn là một cách thực hành tồi vì bạn đang gọi từ không gian tên đó tất cả các hàm và biến. Khi bạn muốn xác định một hàm mới có cùng tên với một hàm khác có trong hàm, namespace stdbạn sẽ làm quá tải hàm và nó có thể tạo ra các vấn đề do biên dịch hoặc thực thi. Nó sẽ không biên dịch hoặc thực thi như bạn mong đợi.

Như được đề cập trong trang này :

Mặc dù câu lệnh lưu chúng ta khỏi việc gõ std :: bất cứ khi nào chúng ta muốn truy cập một lớp hoặc loại được xác định trong không gian tên std, nó nhập toàn bộ không gian tên std vào không gian tên hiện tại của chương trình. Chúng ta hãy lấy một vài ví dụ để hiểu tại sao điều này có thể không phải là một điều tốt như vậy

...

Bây giờ ở giai đoạn phát triển sau này, chúng tôi muốn sử dụng một phiên bản cout khác được tùy chỉnh triển khai trong một số thư viện có tên là foo foo (ví dụ)

...

Lưu ý làm thế nào có một sự mơ hồ, thư viện nào mà cout trỏ đến? Trình biên dịch có thể phát hiện điều này và không biên dịch chương trình. Trong trường hợp xấu nhất, chương trình vẫn có thể biên dịch nhưng gọi hàm sai, vì chúng tôi không bao giờ chỉ định không gian tên thuộc về định danh nào.

Tôi không nghĩ rằng nó thực sự là thực hành xấu trong mọi điều kiện, nhưng bạn cần cẩn thận khi sử dụng nó. Nếu bạn đang viết thư viện, có lẽ bạn nên sử dụng các toán tử phân giải phạm vi với không gian tên để giữ cho thư viện của bạn không bị húc đầu với các thư viện khác. Đối với mã cấp độ ứng dụng, tôi không thấy có gì sai với nó.

"Tại sao 'sử dụng không gian tên std;' được coi là một thực hành xấu trong C ++? "

Tôi nói cách khác: Tại sao một số nhân vật phụ lại bị coi là cồng kềnh?

Xem xét ví dụ viết một phần mềm số. Tại sao tôi thậm chí sẽ xem xét gây ô nhiễm không gian tên toàn cầu của mình bằng cách cắt "std :: vector" chung thành "vectơ" khi "vectơ" là một trong những khái niệm quan trọng nhất của miền vấn đề?

Tôi đồng ý với những người khác - đó là yêu cầu đụng độ tên, sự mơ hồ và sau đó thực tế là nó ít rõ ràng hơn. Trong khi tôi có thể thấy việc sử dụng using, sở thích cá nhân của tôi là hạn chế nó. Tôi cũng sẽ xem xét mạnh mẽ những gì một số người khác chỉ ra:

Nếu bạn muốn tìm một tên hàm có thể là một tên khá phổ biến, nhưng bạn chỉ muốn tìm nó trong stdkhông gian tên (hoặc ngược lại - bạn muốn thay đổi tất cả các cuộc gọi không nằm trong không gian tên std, không gian tên X, ...), Sau đó, làm thế nào để bạn đề xuất để làm điều này?

Bạn có thể viết một chương trình để thực hiện nó, nhưng sẽ tốt hơn nếu dành thời gian làm việc cho chính dự án của bạn hơn là viết một chương trình để duy trì dự án của bạn?

Cá nhân, tôi thực sự không bận tâm đến std::tiền tố. Tôi thích cái nhìn hơn là không có nó. Tôi không biết đó có phải là vì nó rõ ràng và nói với tôi "đây không phải là mã của tôi ... Tôi đang sử dụng thư viện tiêu chuẩn" hoặc nếu đó là một cái gì đó khác, nhưng tôi nghĩ nó trông đẹp hơn. Điều này có thể kỳ lạ khi tôi chỉ mới vào C ++ (đã sử dụng và vẫn sử dụng C và các ngôn ngữ khác lâu hơn nữa và C là ngôn ngữ yêu thích của tôi mọi thời đại, ngay trên phần lắp ráp).

Có một điều khác mặc dù nó có phần liên quan đến những điều trên và những gì người khác chỉ ra. Mặc dù điều này có thể là thông lệ xấu, đôi khi tôi dành std::namecho phiên bản thư viện tiêu chuẩn và tên để triển khai cụ thể theo chương trình. Vâng, thực sự điều này có thể cắn bạn và cắn bạn mạnh mẽ, nhưng tất cả là do tôi đã bắt đầu dự án này từ đầu, và tôi là lập trình viên duy nhất cho nó. Ví dụ: Tôi quá tải std::stringvà gọi nó string. Tôi có bổ sung hữu ích. Tôi đã làm điều đó một phần vì xu hướng C và Unix (+ Linux) của tôi đối với các tên viết thường.

Bên cạnh đó, bạn có thể có các bí danh không gian tên. Dưới đây là một ví dụ về nơi hữu ích mà có thể không được đề cập đến. Tôi sử dụng tiêu chuẩn C ++ 11 và đặc biệt với libstdc ++. Vâng, nó không có std::regexhỗ trợ đầy đủ . Chắc chắn, nó biên dịch, nhưng nó ném một ngoại lệ dọc theo dòng của nó là một lỗi ở phần cuối của lập trình viên. Nhưng nó thiếu thực hiện.

Vì vậy, đây là cách tôi giải quyết nó. Cài đặt regex của Boost và liên kết nó. Sau đó, tôi làm như sau để khi libstdc ++ thực hiện hoàn toàn, tôi chỉ cần xóa khối này và mã vẫn giữ nguyên:

namespace std
{
    using boost::regex;
    using boost::regex_error;
    using boost::regex_replace;
    using boost::regex_search;
    using boost::regex_match;
    using boost::smatch;
    namespace regex_constants = boost::regex_constants;
}

Tôi sẽ không tranh luận về việc đó có phải là một ý tưởng tồi hay không. Tuy nhiên, tôi sẽ lập luận rằng nó giữ sạch cho dự án của tôi và đồng thời làm cho nó cụ thể: Đúng, tôi phải sử dụng Boost, nhưng tôi đang sử dụng nó như libstdc ++ cuối cùng sẽ có nó. Có, bắt đầu dự án của riêng bạn và bắt đầu với một tiêu chuẩn (...) ngay từ đầu đã đi một chặng đường rất dài với việc giúp bảo trì, phát triển và mọi thứ liên quan đến dự án!

Chỉ cần làm rõ điều gì đó: Tôi thực sự không nghĩ rằng nên sử dụng tên của một lớp / bất cứ điều gì trong STL một cách có chủ ý và cụ thể hơn thay cho. Chuỗi là ngoại lệ (bỏ qua lần đầu tiên, ở trên hoặc thứ hai ở đây, chơi chữ nếu bạn phải) đối với tôi vì tôi không thích ý tưởng về 'Chuỗi'.

Như vậy, tôi vẫn rất thiên về C và thiên vị so với C ++. Chi tiết tiết kiệm, phần lớn những gì tôi làm việc phù hợp với C nhiều hơn (nhưng đó là một bài tập tốt và là cách tốt để khiến bản thân tôi học một ngôn ngữ khác và b. Cố gắng không bị thiên vị so với đối tượng / lớp / v.v. như ít khép kín, ít kiêu ngạo và chấp nhận nhiều hơn.). Nhưng những gì là hữu ích là những gì một số đã đề nghị: Tôi thực sự sử dụng danh sách (đó là khá chung chung, là nó không?), Và sắp xếp (điều tương tự) để đặt tên hai có thể gây ra một cuộc đụng độ tên nếu tôi được làm using namespace std;, và do đó Cuối cùng, tôi thích cụ thể hơn, kiểm soát và biết rằng nếu tôi dự định đó là sử dụng tiêu chuẩn thì tôi sẽ phải chỉ định nó. Nói một cách đơn giản: không cho phép giả định.

Và như để làm phần regex của Boost std. Tôi làm điều đó để hội nhập trong tương lai và - một lần nữa, tôi thừa nhận hoàn toàn đây là sự thiên vị - tôi không nghĩ nó xấu như vậy boost::regex:: .... Thật vậy, đó là một điều khác cho tôi. Có nhiều điều trong C ++ mà tôi vẫn chưa chấp nhận hoàn toàn về ngoại hình và phương thức (một ví dụ khác: các mẫu matrixdic so với var argument [mặc dù tôi thừa nhận các mẫu matrixdic rất rất hữu ích!]). Ngay cả những điều mà tôi chấp nhận nó cũng khó khăn và tôi vẫn có vấn đề với họ.

Từ kinh nghiệm của tôi, nếu bạn có nhiều thư viện sử dụng nói cout, nhưng với mục đích khác, bạn có thể sử dụng sai cout.

Ví dụ, nếu tôi gõ vào, using namespace std;và using namespace otherlib;và gõ chỉ cout(mà sẽ xảy ra là trong cả hai), chứ không phải std::cout(hoặc 'otherlib::cout'), bạn có thể sử dụng một trong những sai lầm, và nhận lỗi. Nó hiệu quả và hiệu quả hơn nhiều để sử dụng std::cout.

Với các định danh nhập không đủ tiêu chuẩn, bạn cần các công cụ tìm kiếm bên ngoài như grep để tìm ra nơi định danh được khai báo. Điều này làm cho lý luận về tính chính xác của chương trình khó hơn.

Nó phụ thuộc vào vị trí của nó. Nếu nó là một tiêu đề phổ biến, thì bạn đang làm giảm giá trị của không gian tên bằng cách hợp nhất nó vào không gian tên toàn cầu. Hãy nhớ rằng, đây có thể là một cách gọn gàng để tạo mô-đun toàn cầu.

Đây là một thực tiễn xấu, thường được gọi là ô nhiễm không gian tên toàn cầu. Sự cố có thể xảy ra khi có nhiều hơn một không gian tên có cùng tên hàm với chữ ký, do đó trình biên dịch sẽ không rõ ràng để quyết định nên gọi cái nào và tất cả có thể tránh được khi bạn chỉ định không gian tên với hàm gọi của bạn std::cout. Hi vọng điêu nay co ich. :)

Để trả lời câu hỏi của bạn, tôi nhìn vào nó theo cách này một cách thực tế: rất nhiều lập trình viên (không phải tất cả) gọi không gian tên std. Do đó, người ta nên có thói quen KHÔNG sử dụng những thứ bắt chước hoặc sử dụng cùng tên với những gì trong không gian tên std. Đó là một thỏa thuận tuyệt vời được cấp, nhưng không quá nhiều so với số lượng các từ và bút danh mạch lạc có thể được đưa ra với cách nói nghiêm túc.

Ý tôi là thực sự ... nói rằng "đừng dựa vào sự hiện diện này" chỉ là thiết lập cho bạn dựa vào nó KHÔNG hiện diện. Bạn liên tục gặp vấn đề khi mượn đoạn mã và liên tục sửa chữa chúng. Chỉ cần giữ các công cụ do người dùng xác định và mượn trong phạm vi hạn chế như họ nên và RẤT không phụ thuộc vào toàn cầu (trung thực toàn cầu nên luôn luôn là phương sách cuối cùng cho mục đích "biên dịch ngay bây giờ, tỉnh táo sau"). Thực sự tôi nghĩ rằng đó là lời khuyên tồi từ giáo viên của bạn bởi vì sử dụng std sẽ hoạt động cho cả "cout" và "std :: cout" nhưng KHÔNG sử dụng std sẽ chỉ hoạt động cho "std :: cout". Bạn sẽ không đủ may mắn để viết tất cả mã của riêng bạn.

LƯU Ý: Đừng tập trung quá nhiều vào các vấn đề hiệu quả cho đến khi bạn thực sự tìm hiểu một chút về cách trình biên dịch làm việc. Với một chút kinh nghiệm mã hóa, bạn không cần phải tìm hiểu nhiều về chúng trước khi bạn nhận ra họ có thể khái quát hóa mã tốt thành một thứ gì đó đơn giản đến mức nào. Mỗi bit đơn giản như thể bạn đã viết toàn bộ trong C. Mã tốt chỉ phức tạp như nó cần phải có.