Các tính năng của toàn bộ đội ngũ C ++ C ++?

Trong C ++, các tính năng như ngoại lệ ảnh hưởng đến toàn bộ chương trình của bạn: bạn có thể vô hiệu hóa chúng trong toàn bộ chương trình của mình hoặc bạn cần xử lý chúng trong toàn bộ mã của mình. Như một bài viết nổi tiếng trên Báo cáo C ++ đặt nó:

Theo trực giác, phần khó của các ngoại lệ mã hóa không phải là các cú ném và bắt rõ ràng. Phần thực sự khó khăn của việc sử dụng các ngoại lệ là viết tất cả các mã can thiệp theo cách mà một ngoại lệ tùy ý có thể truyền từ vị trí ném của nó sang trình xử lý của nó, đến nơi an toàn và không làm hỏng các phần khác của chương trình trên đường đi.

Vì thậm chí còn newném ngoại lệ, mọi hàm đều cần cung cấp an toàn ngoại lệ cơ bản - trừ khi nó chỉ gọi các hàm đảm bảo không ném ngoại lệ - trừ khi bạn vô hiệu hóa ngoại lệ hoàn toàn trong toàn bộ dự án của bạn .

Do đó, các trường hợp ngoại lệ là một tính năng "toàn chương trình" hoặc "toàn nhóm", vì mọi người trong nhóm phải sử dụng chúng. Nhưng không phải tất cả các tính năng của C ++ đều như vậy, theo như tôi biết.

Một ví dụ có thể là nếu tôi không nhận được các mẫu nhưng tôi không sử dụng chúng, tôi vẫn có thể viết đúng C ++ - hoặc tôi sẽ không?. Tôi thậm chí có thể gọi sortmột loạt các số nguyên và tận hưởng lợi thế tốc độ tuyệt vời của nó. C's qsort(vì không có con trỏ hàm nào được gọi), mà không gặp rủi ro - hay không? Có vẻ như các mẫu không phải là "toàn đội".

Có các tính năng C ++ khác mà mã tác động không trực tiếp sử dụng chúng và do đó là "toàn bộ nhóm" không? Tôi đặc biệt quan tâm đến các tính năng không có trong C.

Cập nhật : Tôi đặc biệt tìm kiếm các tính năng không có dấu hiệu thực thi ngôn ngữ mà bạn cần biết về chúng. Câu trả lời đầu tiên tôi đã đề cập đến tính chính xác, cũng là toàn đội, do đó mọi người cần tìm hiểu về nó; tuy nhiên, AFAICS nó sẽ chỉ ảnh hưởng đến bạn nếu bạn gọi một hàm được đánh dấu constvà trình biên dịch sẽ ngăn bạn gọi nó trên các đối tượng không phải là const, vì vậy bạn có thể lấy thứ gì đó cho google. Với các ngoại lệ, bạn thậm chí không có được điều đó; hơn nữa, chúng luôn được sử dụng ngay khi bạn sử dụng new, do đó các trường hợp ngoại lệ sẽ "quỷ quyệt" hơn. Vì tôi không thể diễn đạt điều này một cách khách quan, tuy nhiên, tôi sẽ đánh giá cao bất kỳ tính năng nào của toàn đội.

Cập nhật 2 : thay vì tính năng C ++, tôi nên viết một cái gì đó như "C ++ - tính năng cụ thể", để loại trừ những thứ như đa luồng áp dụng cho một lượng lớn ngôn ngữ lập trình chính thống.

Phụ lục: Tại sao câu hỏi này là khách quan (nếu bạn thắc mắc)

C ++ là một ngôn ngữ phức tạp, vì vậy nhiều dự án hoặc hướng dẫn mã hóa cố gắng chọn các tính năng C ++ "đơn giản" và nhiều người cố gắng đưa vào hoặc loại trừ một số tính năng theo tiêu chí chủ yếu. Các câu hỏi về điều đó được đóng lại thường xuyên ở đây trên SO.

Ở trên, thay vào đó, tôi đã xác định (chính xác nhất có thể) tính năng ngôn ngữ "toàn đội" là gì, cung cấp một ví dụ (ngoại lệ), cùng với bằng chứng hỗ trợ rộng rãi trong tài liệu về C ++ và yêu cầu các tính năng của cả nhóm trong C ++ ngoài trường hợp ngoại lệ.

Cho dù bạn nên sử dụng các tính năng "toàn đội" hay liệu đó có phải là một khái niệm có liên quan hay không, nhưng điều đó chỉ có nghĩa là tầm quan trọng của câu hỏi này là chủ quan, như mọi khi.

Tôi sẽ đề cử đồng thời là một tính năng 'toàn đội'.

Mặc dù có thể thiết kế phần mềm sao cho chỉ một số chuyên gia cần nhận thức được các vấn đề tương tranh và phần còn lại của nhóm có thể gặt hái những lợi ích mà không cần quan tâm đến sự phức tạp (như bạn có thể làm với các mẫu), nhưng thực tế nó có không làm việc theo cách đó Trong thực tế, nếu bạn có nhiều luồng, thì bạn phải phân tích cẩn thận cho từng biến bạn sử dụng nếu có vấn đề tương tranh tiềm ẩn với việc sử dụng đó.

Câu trả lời rõ ràng là consttính chính xác: vì const/ trình volatileđộ là truyền nhiễm, một khi một phần của mã bắt đầu sử dụng nó, mọi mã gọi (trực tiếp hoặc gián tiếp) cũng phải constchính xác hoặc bỏ đi constmột cách rõ ràng.

Tuy nhiên, như ngoại lệ, đây rõ ràng là một điều tốt . Hơn nữa, vì không giống như an toàn ngoại lệ, nó được trình biên dịch xác minh nghiêm ngặt.

Con trỏ.

• Con trỏ có trỏ đến bộ nhớ trên ngăn xếp không?
• Liệu con trỏ trỏ đến bộ nhớ trên heap?
• Con trỏ có trỏ đến một đối tượng không?
• Con trỏ có trỏ đến một mảng không?
• Con trỏ có trỏ đến một vị trí ở giữa một mảng không?
• Con trỏ có hợp lệ không?
• Là con trỏ đọc sai?
• Mã nào "sở hữu" con trỏ?
• Đối tượng được tham chiếu có nên được giải quyết bằng tay? Nếu vậy thì thế nào?

Một khả năng khác là quá tải toán tử. Khi một phần của cơ sở mã bắt đầu sửa đổi các toán tử quá tải, mọi người có xu hướng bắt đầu đoán thứ hai chính xác bất kỳ đối tượng cụ thể nào mà họ đang làm việc thực sự đang làm. Nó không truyền bá rõ ràng thông qua cơ sở mã theo cách ngoại lệ và tính đúng đắn, nhưng chắc chắn điều gì đó có thể bắt đầu gây ra vấn đề nếu cả nhóm không ở cùng một trang về thời điểm, cách thức và lý do sử dụng nó.

Điều duy nhất bên cạnh sự đúng đắn (nhìn thấy ở trên) xuất hiện trong tâm trí là trạng thái stream (ing). Nếu bạn viết mã C ++ trong đó bạn sử dụng các đối tượng và các tiểu dự án và phân cấp đối tượng thì cuối cùng bạn sẽ muốn gửi hoặc nhận dữ liệu đến / từ nhà điều hành chương trình. Bạn có thể viết các hoạt động phát trực tuyến đơn giản sẽ biên dịch và sẽ chính xác về mặt ngữ nghĩa ...

std::ostream& operator<< (std::ostream&, MyClass const&) {...}
std::istream& operator>> (std::istream&, MyClass&) {...}

... Nhưng một khi bạn làm như vậy, bạn sẽ không bao giờ có bất kỳ đảm bảo nào rằng những gì bạn đang cố gắng viết (hoặc quan trọng nhất là đọc) tuân theo định dạng giống như những gì khách hàng đang gửi cho bạn. Có quá nhiều trường hợp kỳ lạ xảy ra với các luồng, thậm chí còn tệ hơn nếu bạn phải truyền luồng hoặc cờ luồng khi các đối số xuống chuỗi gọi hàm của bạn, đó là cách truyền phát các lớp thường được thực hiện. Vì vậy, phát trực tuyến có thể được định nghĩa là "quỷ quyệt" như bạn đã sử dụng thuật ngữ ở trên, hoặc thậm chí là "virus" ( _{mặc dù không phải ở bất kỳ nơi nào có cùng mức độ với độ chính xác} ).

Có một thành viên sâu bên dưới hệ thống phân cấp lớp của bạn đó là một string? Surprise, khách hàng tốt hơn gửi một đơn từ, hoặc khác. Có một số số bạn muốn nối tiếp? Bạn nên kiểm tra, lưu và khôi phục các cờ luồng ở mọi độ sâu của hàm gọi, bởi vì bạn không bao giờ biết ai là kẻ ngốc chỉ đặt luồng của mình thành đầu ra bát phân trước khi gọi hàm của bạn. Hoặc tệ hơn - những người vừa gọi một cái gì đó giống như setfillvà setwdo đó đã phá vỡ định dạng đầu vào / đầu ra của bạn - và chỉ các thành viên không thể tách rời đầu tiên của bạn vì những trạng thái đó không lan truyền . Oh và chúng ta đừng hỏi về stream và quốc tế hóa.

Không có cảnh báo bằng ngôn ngữ nào cho dù bạn đang truyền phát đúng cách hay sai cách hay thậm chí là phát trực tuyến cả . Đã hỏi mã máy khách để truyền phát để ghi dữ liệu sao lưu vào? Bạn thực sự không có cách nào để biết rằng luồng chỉ đến /dev/null. ( _{Mặt khác, bạn có thể yêu cầu tốc độ sao lưu và tốc độ nén đáng kinh ngạc theo cách đó!} )