Có gì sai với cplusplus.com?

Đây có lẽ không phải là một diễn đàn hoàn toàn phù hợp cho câu hỏi này, nhưng hãy để tôi cho nó một cú đánh, có nguy cơ bị chuyển đi.

Có một số tài liệu tham khảo cho thư viện chuẩn C ++, bao gồm tiêu chuẩn ISO vô giá, MSDN , IBM , cppreference , và cplusplus . Cá nhân, khi viết C ++, tôi cần một tài liệu tham khảo có quyền truy cập ngẫu nhiên nhanh chóng, thời gian tải ngắn và ví dụ sử dụng và tôi đã tìm thấy cplusplus.com khá hữu ích. Tuy nhiên, tôi đã nghe những ý kiến ​​tiêu cực về trang web đó thường xuyên ở đây trên SO, vì vậy tôi muốn biết cụ thể:

Các lỗi, quan niệm sai lầm hoặc những lời khuyên tồi tệ được đưa ra bởi cplusplus.com là gì? Những rủi ro của việc sử dụng nó để đưa ra quyết định mã hóa là gì?

Hãy để tôi thêm điểm này: Tôi muốn có thể trả lời các câu hỏi ở đây trên SO với các trích dẫn chính xác của tiêu chuẩn, và do đó tôi muốn đăng các liên kết có thể sử dụng ngay lập tức và cplusplus.com sẽ không phải là trang web tôi chọn vấn đề này.

Chỉnh sửa: Tài liệu cho std::removeđã được sửa chữa vì câu trả lời này đã được viết. Điều tương tự áp dụng cho list::remove.

Hãy để tôi cho bạn một ví dụ để cho bạn thấy làm thế nào cpluscplus.com có ​​thể hiểu sai.

Xem xét std::removechức năng từ <algorithm>.

Thực tế là std::removekhông loại bỏ các mục từ container. Đó là bởi vì nó chỉ std::removehoạt động với một cặp vòng lặp và không biết gì về container thực sự chứa các vật phẩm. Trong thực tế, không thể std::removebiết được container bên dưới, bởi vì không có cách nào nó có thể đi từ một cặp trình vòng lặp để khám phá về container mà trình lặp đó thuộc về. Vì vậy, std::removekhông thực sự loại bỏ các mặt hàng, đơn giản là vì nó không thể . Cách duy nhất để thực sự loại bỏ một mục khỏi một container là gọi một hàm thành viên trên container đó.

Vì vậy, nếu bạn muốn xóa các mục, hãy sử dụng Xóa thành ngữ :

 v.erase(std::remove(v.begin(), v.end(), 10), v.end()); 

Nhưng cplusplus.comcung cấp thông tin không chính xác về std::remove. Nó nói rằng

Lưu ý rằng chức năng này không làm thay đổi các thành phần qua đầu mới, giữ các giá trị cũ của chúng và vẫn có thể truy cập được .

Điều đó không đúng. Trình lặp trong phạm vi [new_end, old_end)vẫn có thể điều chỉnh được, nhưng điều đó KHÔNG có nghĩa là chúng giữ các giá trị cũ và vẫn có thể truy cập được. Chúng không được chỉ định.

Tương tự, cplusplus.comcung cấp thông tin không chính xáclist::remove là tốt. Nó nói ,

Lưu ý rằng một hàm thuật toán toàn cầu, loại bỏ, tồn tại với một hành vi tương tự nhưng hoạt động giữa hai lần lặp.

Điều đó là hoàn toàn sai. Loại bỏ toàn cầu cụ thể std::removelà không giống với list::remove, như chúng ta đã thấy rằng cái trước KHÔNG thực sự loại bỏ các mục khỏi container vì nó không thể , trong khi cái sau (chức năng thành viên) thực sự loại bỏ các mục vì nó có thể .

Câu trả lời này được sao chép từ một câu trả lời khác của tôi trong chủ đề sau, với một chút sửa đổi:

• STL loại bỏ không hoạt động như mong đợi?

Lưu ý: Vì tôi đã bắt gặp điều này gần đây khi tôi trả lời trong chủ đề trên, tôi nhớ nó. Có rất nhiều lỗi mà tôi đã gặp trong hai năm qua, mà tôi không nhớ. Tôi có thể thêm vài lần sau, nếu tôi gặp lại.

Tôi sẽ đưa ra một ý kiến ​​hơi ngược lại. Có rất nhiều thông tin tốt trên cplusplus.com. Chọn nó cho đến chết, và vâng, tất nhiên nó có vấn đề, nhưng trang web nào không? Chắc chắn không phải trang web này . Những người sống trong nhà kính không nên ném đá. Có rất nhiều thông tin sai ở đây, quá. Có những câu trả lời được chấp nhận là không đúng, câu trả lời bị bỏ qua (một số câu phủ định!) Là đúng tại chỗ.

Một vấn đề với cplusplus.com là nó là một trang web đóng; điều tương tự cũng xảy ra với hầu hết các trang web tham khảo khác được đề cập. Điều này đi ngược lại với các trang web do cộng đồng phát triển, chẳng hạn như Stack Overflow. Có được khả năng thực hiện các chỉnh sửa đáng tin cậy không mất nhiều thời gian và ngay cả những người mới nhất cũng có thể dễ dàng đưa ra đề xuất cải tiến. So sánh điều đó với cplusplus.com. Bạn là người mới vĩnh viễn nếu bạn không thuộc biên chế của họ. Ngay cả khi bạn là thành viên chủ chốt của WG21, bạn phải thông qua cơ chế báo cáo email của họ nếu bạn thấy một lỗi nào đó trong trang web đó. Vô cảm!

Một giải pháp sẽ là cho chúng tôi tại trang web này để phát triển tài liệu tham khảo C ++ của riêng chúng tôi. Điều này sẽ mất khá nhiều công việc. Chúng ta phải cẩn thận để không quá khoa trương / quá kỹ thuật; rõ ràng là cplusplus.com sử dụng ít nhất một vài biên tập viên kỹ thuật, những người giữ cho các nhà giáo ở lại. Chúng tôi phải giữ thông tin được tổ chức tốt; Câu hỏi thường gặp ở đây không được tổ chức tốt. Chúng tôi cũng phải hết sức cẩn thận để không phun quá nhiều trực tiếp từ tiêu chuẩn; đó là bất hợp pháp.

http://www.cplusplus.com/reference/cl Library / copes / strncpy /

Không thể đề cập rằng "Nếu việc sao chép diễn ra giữa các đối tượng trùng nhau, hành vi không được xác định." (4.11.2.4 trong tiêu chuẩn C89. Tôi không có bản sao của C90, đó là những gì C ++ 03 thực sự đề cập đến, nhưng chúng được cho là chỉ khác nhau ở những thứ như đánh số trang.)

Các tài liệu được cung cấp bởi cplusplus.com thường không chính xác hoặc không đầy đủ.

Một khi ví dụ như vậy là, atoitài liệu trên cplusplus.com.

atoi
Trong phần Trả về, không có đề cập đến giá trị trả về 0 nếu không có chuyển đổi nào có thể được thực hiện trong khi sử dụng hàm.

cplusplus.com Phần trả về trạng thái "... Nếu giá trị được chuyển đổi sẽ nằm ngoài phạm vi của các giá trị đại diện bởi một int, nó gây ra hành vi không xác định."

Điều này là chính xác, theo tiêu chuẩn " Nếu giá trị số của chuỗi không thể được biểu thị bằng int, thì hành vi không được xác định ".

Tuy nhiên, phần này không đầy đủ vì nó không đề cập đến 0 là giá trị trả về, có thể gây hiểu nhầm. Cụm từ "... không có chuyển đổi nào được thực hiện và trả về 0". được đáp ứng trước trong đoạn mô tả, nhưng điều cần thiết là phải có nó trong phần Trả về .

Nhiều mã nguồn mẫu được đưa ra trên cplusplus.com là không chính xác.
Nhiều người mới tìm đến các tài liệu tham khảo này đã dẫn đến việc mắc lỗi ballant.

Để trích dẫn một ví dụ:

EDIT: Ví dụ tôi đã trích dẫn trước đây là không chính xác.

Tài liệu cho type_info cố gắng giải thích typeidtrước, nhưng không thành công:

typeid có thể được áp dụng trực tiếp cho các loại, trong trường hợp đó nó trả về thông tin của nó; Hoặc cho các đối tượng, trong trường hợp đó, nó trả về thông tin về loại đối tượng.

Khi typeid được áp dụng cho một con trỏ được ước tính cho một đối tượng thuộc loại lớp đa hình (một lớp khai báo hoặc kế thừa một hàm ảo), nó xem xét kiểu động của nó (tức là loại của đối tượng dẫn xuất nhất).

Bây giờ đoạn thứ hai đã không đồng ý với đoạn đầu tiên. Trong typeid(*ptr), typeidđược áp dụng cho một biểu thức. Điều này là khá cần thiết, vì khái niệm staticvà dynamiccác loại chỉ có ý nghĩa trong bối cảnh biểu hiện, không phải đối tượng. Nó cũng bỏ lỡ trường hợp như thế typeid(foo()).

Hơn nữa, đoạn thứ hai bỏ qua các tài liệu tham khảo. Chúng cũng có thể có các kiểu tĩnh khác với kiểu động của đối tượng mà chúng tham chiếu.

Tài liệu của std::pair<T1,T2>::operator== nói rằng cả hai yếu tố được kiểm tra cho sự bình đẳng. Tài liệu std::pair<T1,T2>::operator<nói rằng các yếu tố thứ hai chỉ được xem xét nếu các yếu tố đầu tiên bằng nhau.

Từ "bằng" xuất hiện trong cả hai trường hợp. Tuy nhiên, chỉ trong trường hợp đầu tiên nó thực sự có nghĩa T::operator==. Trong trường hợp thứ hai, phương tiện bằng nhau!(a.first<b.first || b.first<a.first)