Để bắt đầu, sẽ luôn có một số vấn đề được giải quyết tốt hơn bằng ngôn ngữ này hơn ngôn ngữ khác. Sẽ luôn có những ngôn ngữ giải quyết các vấn đề cụ thể "tốt hơn" so với bất kỳ ngôn ngữ nào khác, đối với một số định nghĩa về "tốt hơn". Tuy nhiên, một số lượng rất lớn các vấn đề có nhu cầu rất giống nhau (một số I / O, một số tính toán) và phải đối mặt với các yêu cầu tương tự (độ tin cậy hợp lý, hiệu suất hợp lý).
Như bạn đã biết C, đối với phần lớn các vấn đề ngoài kia, tôi nói rằng C ++ không cung cấp nhược điểm đáng kể và một số cải tiến đáng kể. Dũng cảm? Một số người dường như nghĩ như vậy, nhưng thực sự là như vậy. Hãy bắt đầu bằng cách xóa một vài hiểu lầm rất phổ biến về C ++:
C ++ chậm hơn C. Sai! Nhiều chương trình C cũng là chương trình C ++ hợp lệ - và một chương trình C như vậy sẽ chạy ở tốc độ giống hệt nhau khi được biên dịch bằng trình biên dịch C hoặc trình biên dịch C ++.
Các tính năng cụ thể của C ++ yêu cầu phí. Sai rồi! Cái gọi là chi phí được giới thiệu bởi một số tính năng cụ thể của C ++ (như các cuộc gọi hoặc ngoại lệ của hàm ảo), có thể so sánh với chi phí bạn tự giới thiệu nếu bạn triển khai một tính năng tương tự trong C.
C ++ là hướng đối tượng. Sai rồi! Ngôn ngữ C ++ chứa một số phần mở rộng ngôn ngữ tạo điều kiện cho lập trình hướng đối tượng và lập trình chung. C ++ không bắt buộc thiết kế hướng đối tượng ở bất cứ đâu - nó chỉ cho phép nó. C cũng cho phép lập trình hướng đối tượng, C ++ chỉ làm cho nó đơn giản hơn và ít bị lỗi hơn.
Vì vậy, nếu bạn tin tôi, chúng tôi đã chứng minh rằng "C ++ không tệ hơn đáng kể so với C". Chúng ta hãy xem điều gì làm cho C ++ trở nên tốt hơn:
Gõ mạnh hơn Hệ thống loại trong C ++ mạnh hơn so với C. Điều này ngăn ngừa nhiều lỗi lập trình phổ biến - kết hợp với tính năng rất quan trọng tiếp theo, hệ thống loại mạnh hơn thậm chí còn không gây bất tiện.
Các kiểu tham số hóa Từ khóa mẫu cho phép lập trình viên viết các triển khai thuật toán chung (loại bất khả tri). Trong C, người ta có thể viết một triển khai danh sách chung với một phần tử như:
struct element_t {
struct element_t *next, *prev;
void *element;
};
C ++ cho phép một người viết một cái gì đó như:
template <typename T>
struct element_t {
element_t<T> *next, *prev;
T element;
};
Việc triển khai C ++ không chỉ ngăn ngừa các lỗi lập trình phổ biến (như đưa một phần tử sai loại vào danh sách), nó còn cho phép trình biên dịch tối ưu hóa tốt hơn! Ví dụ: triển khai sắp xếp chung có sẵn trong cả C và C ++ -
thói quen C được định nghĩa là:
void qsort(void *base, size_t nmemb, size_t size,
int(*compar)(const void *, const void *));
trong khi thói quen C ++ được định nghĩa là
template void sort(RandomAccessIterator first, RandomAccessIterator last);
Sự khác biệt, ví dụ như sắp xếp một mảng các số nguyên, trong trường hợp C, sẽ yêu cầu một hàm gọi cho mỗi so sánh, trong khi việc thực hiện C ++ sẽ cho phép trình biên dịch thực hiện các cuộc gọi so sánh số nguyên, vì thói quen sắp xếp thực tế là tự động khởi tạo tại thời gian biên dịch bởi trình biên dịch, với các loại chính xác được chèn trong các đối số mẫu.
- Thư viện chuẩn C ++ lớn hơn cho phép sử dụng toàn bộ thư viện chuẩn C. Tất nhiên điều này rất quan trọng, vì thư viện chuẩn C là một nguồn tài nguyên vô giá khi viết các chương trình trong thế giới thực. Tuy nhiên, C ++ bao gồm Thư viện mẫu tiêu chuẩn. STL chứa một số mẫu hữu ích, như thói quen sắp xếp ở trên. Nó bao gồm các cấu trúc dữ liệu phổ biến hữu ích như danh sách, bản đồ, bộ, v.v. Giống như thói quen sắp xếp, các thói quen và cấu trúc dữ liệu STL khác được "điều chỉnh" theo nhu cầu cụ thể của lập trình viên - tất cả các lập trình viên phải làm là điền vào các loại.
Tất nhiên, STL không phải là viên đạn bạc - nhưng nó cung cấp một sự trợ giúp rất thường xuyên, khi giải quyết các vấn đề chung. Bạn có thường xuyên thực hiện một danh sách trong C không? Bao lâu thì cây RB sẽ là một giải pháp tốt hơn, nếu chỉ có bạn có thời gian để làm điều đó? Với STL, bạn không cần phải thực hiện các thỏa hiệp như vậy - sử dụng cây nếu nó phù hợp hơn, dễ dàng như sử dụng danh sách.
Ok, vì vậy tôi chỉ thảo luận về những phần tốt. Có bất kỳ nhược điểm? Tất nhiên là có. Tuy nhiên, số lượng của họ đang thu hẹp từng ngày. Hãy để tôi giải thích:
Không có trình biên dịch C ++ tốt. Nó đã như thế này trong một thời gian dài. Nhưng bạn phải nhớ rằng, ngôn ngữ đã được chuẩn hóa vào năm 1998 - đó là một ngôn ngữ phức tạp, phức tạp hơn C. Phải mất một thời gian dài để các trình biên dịch bắt kịp tiêu chuẩn. Nhưng khi viết bài này, có những trình biên dịch tốt có sẵn cho các nền tảng được sử dụng rộng rãi nhất hiện có; GCC trong các phiên bản 3.X thường rất tốt và nó chạy trên nền tảng GNU / Linux và hầu hết UNIX. Intel có một trình biên dịch tốt cho Win32 - nó cũng khá tốt, nhưng thật không may, nó vẫn dựa vào MS STL là ngang bằng.
Mọi người không biết C ++ tốt Đây không phải là một khiếu nại thường được nghe, nhưng đó là điều mà tôi thấy rất nhiều. C ++ là một ngôn ngữ lớn và phức tạp - nhưng nó cũng từng là ngôn ngữ được thổi phồng rất nhiều, đặc biệt là trong "OOP giải quyết nạn đói, chữa khỏi AIDS và ung thư". Kết quả có vẻ là rất nhiều mã C ++ thực sự kém, về cơ bản là C kém với một vài khai báo lớp ở đây và ở đó, đang ở ngoài đó và đang được sử dụng làm tài liệu học tập. Điều này có nghĩa là rất nhiều người tin rằng họ biết C ++ thực sự viết mã thực sự nhảm nhí. Điều đó thật tệ, và đó là một vấn đề, nhưng tôi nghĩ thật không công bằng khi đổ lỗi cho C ++.
Vì vậy, hai vấn đề lớn duy nhất với C ++ là kết quả của C ++ là một ngôn ngữ trẻ. Trong thời gian họ sẽ biến mất. Và đối với hầu hết các vấn đề ngoài kia, nếu bạn có thể có được những lập trình viên giỏi (hoặc tự học C ++ tốt), thì vấn đề không thực sự là một vấn đề ngày nay.