Các lớp kiểu Java trong c ++


8

Tôi đã xem qua bài viết này đề xuất một phong cách mã hóa trong c ++ có vẻ hơi kỳ lạ lúc đầu. Nhưng sau khi đọc nó và suy nghĩ một chút, tôi thực sự đang cân nhắc thử nó.

Lợi ích hấp dẫn nhất là sự dễ dàng của các phương pháp tái cấu trúc. Tôi thấy mình liên tục thay đổi tên phương thức, tham số, v.v. trong khi viết một lớp mới và trong c ++, thật khó chịu khi phải thay đổi tên phương thức trong hai tệp (.h, .cpp).

Tôi đã cố gắng tìm một cái gì đó sai với phong cách này nhưng ngoài thực tế là mã sẽ trông và cảm thấy thực sự lạ đối với các lập trình viên c ++ dày dạn, tôi không thể phát hiện ra bất kỳ lỗ hổng lớn nào. Nhưng vì tôi là một lập trình viên c ++ thiếu kinh nghiệm, tôi hy vọng rằng ai đó ở đây có thể cảnh báo tôi về bất kỳ nguy hiểm tiềm tàng nào.

Vì vậy, câu hỏi của tôi là:

Có bất kỳ nhược điểm nghiêm trọng nào khi sử dụng phong cách mã hóa này không?


2
Bạn có thể sẽ có vấn đề với các mẫu.
Thomas Eding

1
và tên mangling
ratchet freak

@ThomasEding bạn có thể giải thích? Tôi đã thay đổi struct Btrong ví dụ thành một mẫu và nó được biên dịch tốt.
bughi

1
Tôi không hiểu ý của bài viết. Nó đi một lần nữa mọi thứ được coi là mã hiện đại tốt trong C ++ ...
Klaim

1
Tôi thích sự tách biệt của giao diện từ việc thực hiện. Rất dễ dàng để đọc tệp * .h và xem giao diện trong nháy mắt (vì nó nhỏ gọn). Tôi có lẽ không bao giờ cần phải xem tệp nguồn trừ khi đó là mã tôi đang chỉnh sửa. Kết hợp mọi thứ lại với nhau trong một tệp sẽ phá hủy một trong những tính năng của ngôn ngữ mà tôi thấy hữu ích nhất (vì vậy không cần cảm ơn).
Martin York

Câu trả lời:


13

Có, bạn sẽ nhầm lẫn các lập trình viên C ++ khác nếu bạn viết tất cả mã của mình như thế. Tôi chưa bao giờ thấy mã C ++ không phải mẫu được viết theo cách đó, với mọi thứ trong tệp tiêu đề. Điều này cũng đã được thảo luận sâu trong câu hỏi Stack Overflow .

Đối với các vấn đề kỹ thuật thực tế với nó, một vài điều đến với tâm trí.

  • Tất cả mã của bạn có hiệu quả trở thành inline. Thời gian biên dịch của bạn sẽ có khả năng tăng lên.
  • Mỗi biên dịch lại sẽ biên dịch thế giới đơn giản chỉ vì nó phải.
  • Bạn sẽ phải cẩn thận để không chạy afoul của Quy tắc Một Định nghĩa . Tên biến sẽ phải là duy nhất trên tất cả các tệp nguồn, vì nó thực sự trở thành một tệp khổng lồ.

Bạn cũng có thể muốn kiểm tra ngôn ngữ lập trình D , mà tôi nghe được giải quyết rất nhiều vấn đề này. Trình biên dịch D được thiết kế theo phong cách này và không có khả năng tương thích ngược 30 năm với C để hỗ trợ.


Chúng tôi thực sự đã viết C ++ theo cách đó (mọi thứ trong .h) trong các nghiên cứu đại học của tôi. Tôi cung không chăc tại sao. Tôi đã phải học cách tách những thứ ra và tự liên kết chúng đúng cách.
KChaloux

9

Đây không hẳn là một ý tưởng mới. Các lập trình viên mới bắt đầu tránh các tuyên bố như bệnh dịch hạch, và chủ yếu tránh xa nó vì các chương trình của họ quá nhỏ. Hậu quả là bây giờ bạn phải lo lắng về thứ tự bạn xác định chức năng của mình. Hậu quả của việc lo lắng về trật tự định nghĩa là một sự cám dỗ để giảm thiểu vấn đề bằng cách làm cho các chức năng của bạn quá lớn.

Bạn cũng mất sự tách biệt tốt đẹp của giao diện và thực hiện. Bản thân tác giả than phiền các thành viên riêng là một phần của tệp tiêu đề, sau đó "giải quyết" vấn đề bằng cách làm cho tất cả các chi tiết triển khai trở thành một phần của tệp tiêu đề.


7

Nếu bạn muốn các lớp theo kiểu Java, thì hãy lập trình trong Java !

Ông đưa ra nhiều phỏng đoán trong bài viết của mình mà không sai. Không theo thứ tự đặc biệt:

Thời gian biên dịch

Đây cũng không phải là vấn đề. Giả sử bạn có tất cả các tiêu đề hệ điều hành và các thư viện toán học (STL) hoặc thư viện toán học được sử dụng thường xuyên trong các tiêu đề được biên dịch trước và giả sử rằng nếu chương trình của bạn thực sự rất lớn, bạn đã tách nó thành các thành phần như trên, số lượng mã còn lại hoàn toàn không đáng kể một trình biên dịch C ++ hiện đại.

Điều này là sai, và nó cho thấy rằng anh ta chưa bao giờ làm việc trên một chương trình C ++ quy mô lớn. Tải xuống bất kỳ chương trình C ++ mã nguồn mở lớn nào , biên dịch chương trình và cho tôi biết nếu bạn muốn đợi lâu như vậy mỗi khi bạn quên dấu chấm phẩy.

Khai báo trước khi sử dụng

Có một tính năng C ++ mà rất ít lập trình viên dường như biết về (hoặc ít nhất, đã khai thác): và đó là trong một lớp, khai báo trước khi sử dụng không giữ (!). Rõ ràng Bjarne đã nhận thức được vấn đề di sản này trong C ++ và đã sửa nó cho bên trong các lớp, nhưng không thể làm như vậy đối với các khai báo cấp cao nhất vì khả năng tương thích ngược với C (tại sao phải có một số điểm phức tạp tôi bị thiếu ở đây) .

[... nhiều hơn nữa, mỗi dòng đau đớn hơn lần trước ...]

Ok, trước hết, nó không phải là một tính năng mà "rất ít lập trình viên dường như biết đến." Thứ hai, đây là một sự hiểu lầm hoàn toàn về tuyên bố chuyển tiếp và nó được sử dụng để làm gì. Hướng dẫn về phong cách mã hóa của Google có phần giới thiệu khá nửa chừng: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Forward_Declarations

Chúng nhằm đơn giản hóa trình biên dịch và chúng giảm đáng kể thời gian biên dịch.


1
Bạn biết đấy, tôi vừa phải tải xuống liên kết đó đến Hướng dẫn về Phong cách của Google. Đó là một đống sai lầm khổng lồ. Chúng ta nên đưa vào danh sách đen, không liên kết với nó.
DeadMG

0

Điều đó đối với tôi chỉ là đưa ra một cái tên ngớ ngẩn để làm tuyên bố chuyển tiếp thay vì #include <blah>.

Lợi ích của các khai báo chuyển tiếp là thời gian biên dịch của bạn có thể nhanh hơn đáng kể, nhưng nhược điểm chính của IMO là bạn phải chú ý khi bạn có thể và không thể thoát khỏi khai báo chuyển tiếp, và khi bạn viết sai, bạn có thể nhận được thông báo lỗi dường như không thể hiểu cho một lỗi nhỏ.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.