Tại sao C ++ vẫn là người lai lai

Về một câu hỏi liên quan , nó đã được làm rõ tại sao C ++ không tương thích với C về nhiều mặt. Tuy nhiên, C ++ vẫn là ngôn ngữ "lai" *. Và thật không may, nhiều lập trình viên vẫn coi C ++ là "C có luồng và chuỗi tích hợp". Điều đó dẫn đến mã được viết rất tệ, đó không phải là C ++ hay C. IMHO, sẽ tốt hơn nếu ngôn ngữ / trình biên dịch buộc một số lập trình viên phải viết mã thanh lịch hơn. Vì vậy, có một lý do để giữ C ++ hiện đại (ví dụ C ++ 0x và các phiên bản trong tương lai) lai?

_{* Bằng cách lai tôi có nghĩa là tùy thuộc vào lập trình viên quyết định liệu anh ấy / cô ấy sẽ sử dụng: chuỗi và luồng tiêu chuẩn, lớp, không gian tên khác với mặc định, v.v.}

Vâng, có một lý do mạnh mẽ: mã C ++ hầu như luôn phải gọi mã C hiện có. Điều tốt nhất chúng ta có thể làm là làm cho nó dễ dàng để viết mã tốt. Không có gì một nhà thiết kế ngôn ngữ có thể làm để làm cho nó không thể viết mã xấu.

IMHO, sẽ tốt hơn nếu ngôn ngữ / trình biên dịch buộc một số lập trình viên phải viết mã thanh lịch hơn.

Không, nó sẽ không. Ở tất cả. Như một minh chứng tầm thường về lý do tại sao, xác định thanh lịch, và sau đó tôi cá rằng mười người sẽ đến để không đồng ý với bạn.

Phong cách mã hóa thực thi ngôn ngữ là thực sự, thực sự xấu. Chưa kể tất cả các mã di sản sẽ bị phá vỡ.

Đáng chú ý, các lớp chuỗi và luồng tiêu chuẩn thực sự hút . std::stringkhông có hỗ trợ Unicode và giao diện cồng kềnh tồi tệ nhất mà bạn có thể tưởng tượng. Các luồng có chi phí khủng khiếp và thiết kế nghèo nàn, thậm chí phải dùng đến sự kế thừa ảo, và các con trỏ hàm, const char*và xấu xí như thế. Tôi sẽ không phạt bất cứ ai vì đã thay thế hoàn toàn cả hai lớp / nhóm lớp này bằng các lớp tùy chỉnh.

Không sử dụng các lớp và không gian tên là tốt cho mã kiểu bảng trắng và có rất nhiều, nhiều thư viện cung cấp các hàm không có trong một lớp. Enforced-class là một ý tưởng thực sự tồi tệ.

C ++ là một phép lai không phải vì nó cho phép một người viết mã kiểu C, mà bởi vì nó hỗ trợ một số mô hình lập trình, chẳng hạn như thủ tục, hướng đối tượng và chung chung. C ++ không ép buộc bạn vào một cách làm việc, và đó là điểm mạnh của nó, bởi vì các vấn đề khác nhau có thể được giải quyết dễ dàng hơn bằng cách sử dụng các mô hình khác nhau.

IMHO, sẽ tốt hơn nếu ngôn ngữ / trình biên dịch buộc một số lập trình viên phải viết mã thanh lịch hơn.

Sau đó, trước tiên bạn phải xác định những gì có nghĩa là thanh lịch . Sau đó, bạn sẽ phải xem liệu định nghĩa thanh lịch của bạn có phù hợp với tất cả các miền và nền tảng vấn đề mà C ++ được sử dụng không. Một phong cách mã hóa thanh lịch để viết một trình xử lý văn bản cho Windows có thể hoàn toàn không phù hợp để viết một hệ thống nhúng.

Xem xét việc viết mã C ++ để chạy trên DSP. Đầu tiên, trình biên dịch C ++ cho DSP đó có thể đơn giản là không hỗ trợ một số tính năng C ++ nhất định, như các luồng. Thứ hai, bạn bị hạn chế nghiêm trọng bởi tốc độ CPU và có thể cả bộ nhớ, vì vậy một số tính năng C ++ có thể chỉ đơn giản là giết chết hiệu suất của bạn. Ví dụ, bạn có thể phải tránh các chức năng ảo vì lợi ích của tốc độ. Những cân nhắc như vậy sẽ thay đổi hoàn toàn phong cách lập trình của bạn, so với những gì bạn sẽ sử dụng trên PC và C ++ cho phép điều đó.

Tóm lại, C ++ là một ngôn ngữ khổng lồ và phức tạp với nhiều tính năng. Có nhiều lý do tại sao bất kỳ tập hợp con của các tính năng này có thể không áp dụng được cho một dự án cụ thể: tốc độ, tính di động, hỗ trợ trình biên dịch hoặc thậm chí là kinh nghiệm lập trình và sự quen thuộc. Vì lý do đó, ngôn ngữ buộc nhà phát triển sử dụng một số tính năng nhất định so với các ngôn ngữ khác cho bất kỳ tác vụ nhất định nào là một ý tưởng tồi. Hãy nghĩ về Java, nơi ngôn ngữ bắt buộc mọi hàm phải là một phương thức của một lớp. Có rất nhiều trường hợp khi tạo một lớp chỉ để bọc một phương thức là khó xử và không cần thiết, nhưng bạn phải làm điều đó bởi vì ngôn ngữ buộc bạn phải làm.

IMHO, sẽ tốt hơn nếu ngôn ngữ / trình biên dịch buộc một số lập trình viên phải viết mã thanh lịch hơn.

Không ai bắt buộc ai phải sử dụng C ++ ngay từ đầu. Nếu ngôn ngữ không phù hợp với bạn thì hãy sử dụng một ngôn ngữ khác - có nhiều ngôn ngữ được lập hóa đơn là "C ++ không có C".

Triết lý thiết kế của C ++ là để cho lập trình viên quyết định. Nếu họ muốn tự bắn vào chân mình thì hãy để họ. Điều này cho phép nhiều điều xấu được thực hiện, nhưng cũng cho phép rất linh hoạt. Chẳng hạn, không chắc rằng Boost có thể được viết bằng một ngôn ngữ như Java vì nó tận dụng các tính năng và thực tiễn ngôn ngữ thường bị xa lánh. Cũng không chắc rằng C ++ sẽ phát triển lớn như ngày nay - có quyền truy cập vào thư viện C rộng lớn là một điểm cộng rất lớn, hãy lấy nó hoặc bỏ nó.

Khả năng tương thích của C ++ với C chắc chắn là một trong những điểm yếu nhất của nó, nhưng cũng nên nhớ rằng đó là một trong những điểm tốt nhất của nó.

Tôi sẽ thêm vào một trích dẫn tuyệt vời của Jon Purdy mà tôi cảm thấy rất phù hợp:

Tất cả bắt nguồn từ chủ nghĩa thực dụng so với sự thanh lịch, và đối với tôi, mặc dù tôi bị ám ảnh bởi mã đẹp, chính xác, viết một chương trình xấu xí hoạt động tốt hơn là viết một chương trình đẹp mà không làm gì cả.

Loại bỏ các hybrid có thể cải thiện sự thanh lịch, nhưng nó cản trở khả năng.

Nếu ủy ban cố gắng buộc mọi người sử dụng (khái niệm của ai đó) một ngôn ngữ thanh lịch hơn, có lẽ nó sẽ bị bỏ qua. Mọi người sẽ tiếp tục làm những gì họ muốn, và các nhà cung cấp trình biên dịch sẽ theo dõi thị trường (nhưng các nhà cung cấp trình biên dịch có đủ đại diện trong ủy ban để ngăn chặn điều này).

Phần lớn những gì bạn ủng hộ thực sự là một vấn đề của sự phán xét, dựa trên lĩnh vực vấn đề nào. Có rất nhiều chương trình nhỏ không cần (ví dụ) không gian tên. Cố gắng buộc tôi sử dụng một không gian tên khi tôi đang viết bộ lọc văn bản 30 dòng sẽ thật ngu ngốc và kiêu ngạo. Ngay cả khi bạn đã quyết định nó sẽ chỉ áp dụng khi có nhiều hơn X dòng mã hoặc hàm Y hoặc bất cứ thứ gì có liên quan, nó vẫn thường phản tác dụng. Không gian tên được thiết kế cho một lý do, để ngăn ngừa / chữa các vấn đề cụ thể. Cố gắng ép buộc sử dụng chúng trong trường hợp không có những vấn đề đó sẽ không có ích gì cho bất cứ ai.

Đồng thời, tôi nghĩ rằng đáng chú ý là có khá nhiều người thực sự đã dành rất nhiều thời gian và nỗ lực để không chỉ tạo ra sự tao nhã trong C ++, mà còn dạy và dẫn mọi người sử dụng các khả năng đó để viết mã tốt hơn (ví dụ: nhiều người đóng góp Boost). Do đó, những người tiếp tục khăng khăng viết mã của họ là "C với các lớp" gần như không để ý đến những gì ngoài kia. Tôi nghĩ rằng họ sẽ thoải mái bỏ qua các trình biên dịch mới vì họ đang bỏ qua mọi thứ đã được học về cách sử dụng C ++ trong thập kỷ qua trở lên (ví dụ: Modern C ++ Design đã được xuất bản 11 năm trước - nhưng hầu hết mọi người bạn đang nói về dường như chưa nghe về nó, ít đọc hoặc hiểu ngay cả những phần đơn giản nhất của nó).

Ý tưởng của bạn cấu thành phần lớn lý do thiết kế đằng sau Java. Java buộc bạn phải sử dụng các lớp, tổ chức phân cấp tệp theo phân cấp gói, bắt ngoại lệ, v.v. Mọi người vẫn quản lý để viết mã giống như C trong đó.

Là lập trình viên, đôi khi chúng ta quên mất giải pháp tốt nhất có thể không phải là một kỹ thuật. Đánh giá ngang hàng là giải pháp được biết đến nhiều nhất trong trường hợp này.

C ++ không có "một cách chân thực"; mọi cách tiếp cận đều có điểm mạnh và điểm yếu. Các giải pháp có thể được viết một trăm cách khác nhau.

Bạn là một nhà phát triển phần mềm phải quyết định cách tiếp cận nào là tốt nhất cho nhiệm vụ sắp tới.

Tôi nghĩ rằng thực tế là tất cả những thứ bạn liệt kê là tùy chọn sẽ tạo ra tiềm năng cho sự thanh lịch hơn chứ không phải ít hơn. Một tính năng được sử dụng không cần thiết là không phù hợp trong mắt tôi.

Các vấn đề mà chúng ta cần giải quyết bằng cách sử dụng lập trình rất không giống nhau.
Một số được giải quyết tốt bằng cách sử dụng các nguyên tắc OO (ví dụ: GUI), một số cho vay tốt hơn đối với việc xử lý chức năng thuần túy (ví dụ: công cụ số), trong khi một số được thể hiện tốt nhất bằng ngôn ngữ "gần với silicon" ở mức độ thấp.

Rất nhiều phần mềm cần giải quyết các bài toán con được giải quyết tốt nhất theo bất kỳ một trong những cách đó. Buộc giải pháp thành một hình thức cụ thể sẽ chỉ dẫn đến mã không phù hợp với mục đích của nó (thậm chí bạn có thể nói "kém thanh lịch").

Đây là lý do tại sao tính năng lai của C ++ là một điều tốt - nó cho phép chúng ta giải quyết một loạt vấn đề lớn theo cách phù hợp với vấn đề , chứ không phải giáo điều hiện tại.
Tất nhiên nó có thể bị sử dụng sai - bất cứ khi nào bạn có một thứ linh hoạt, có nguy cơ bạn bẻ cong nó theo cách xấu - nhưng sự thanh lịch đến từ suy nghĩ và kinh nghiệm cẩn thận, không phải từ việc tuân thủ bất cứ điều gì là mốt nhất thời.