Tại sao không thể quá tải toán tử gán gán trong C #?


11

Tiêu đề là sai lệch, vì vậy xin vui lòng đọc toàn bộ câu hỏi :-) .

op=Ví dụ, bằng "toán tử gán gán", tôi có một cấu trúc như thế này +=. Toán tử gán thuần túy ( =) không thuộc về câu hỏi của tôi.

Bởi "tại sao" tôi không có nghĩa là một ý kiến, nhưng tài nguyên (sách, bài viết, v.v.) khi một số nhà thiết kế, hoặc đồng nghiệp của họ, v.v. bày tỏ lý lẽ của họ (tức là nguồn gốc của sự lựa chọn thiết kế).

Tôi bối rối bởi sự bất đối xứng được tìm thấy trong C ++ và C # ( vâng, tôi biết C # không phải là C ++ 2.0 ) - trong C ++, bạn sẽ quá tải toán tử +=và sau đó gần như tự động viết +toán tử thích hợp dựa vào toán tử được xác định trước đó. Trong C # thì ngược lại - bạn quá tải ++=được tổng hợp cho bạn.

Nếu tôi không nhầm, cách tiếp cận sau này sẽ giết chết cơ hội tối ưu hóa trong trường hợp thực tế +=, bởi vì đối tượng mới phải được tạo. Vì vậy, phải có một số lợi thế lớn của cách tiếp cận như vậy, nhưng MSDN quá ngại để nói về nó.

Và tôi tự hỏi lợi thế đó là gì - vì vậy nếu bạn phát hiện ra lời giải thích trong một số cuốn sách C #, video nói về công nghệ, mục blog, tôi sẽ biết ơn sự tham khảo.

Điều gần nhất tôi tìm thấy là một bình luận trên blog Eric Lippert Tại sao các toán tử quá tải luôn tĩnh trong C #? bởi Tom Brown. Nếu quá tải tĩnh được quyết định trước tiên, nó chỉ đơn giản chỉ ra các toán tử nào có thể bị quá tải cho các cấu trúc. Điều này tiếp tục chỉ ra những gì có thể bị quá tải cho các lớp.


3
Bạn có một liên kết cho phong cách C ++ mới? Ngây thơ, quá tải +=đầu tiên có vẻ vô lý; Tại sao bạn lại quá tải một hoạt động kết hợp chứ không phải là các bộ phận của nó?
Telastyn

1
Tôi tin rằng thuật ngữ này là "toán tử gán ghép".
Ixrec

2
@greenoldman Telastyn có lẽ ngụ ý rằng việc thực hiện + = về mặt + có vẻ tự nhiên hơn so với cách khác, vì về mặt ngữ nghĩa + = là một thành phần của + và =. Theo hiểu biết tốt nhất của tôi , có + gọi + = phần lớn là một mẹo tối ưu hóa.
Ixrec

1
@Ixrec: Đôi khi, a + = b có ý nghĩa, trong khi a = a + b không: Xem xét rằng danh tính có thể quan trọng, A không thể được sao chép, bất cứ điều gì. Đôi khi, a = a + b có ý nghĩa, trong khi a + = b không: Xem xét các chuỗi bất biến. Vì vậy, một người thực sự cần khả năng quyết định cái nào sẽ quá tải riêng. Tất nhiên, tự động tạo ra cái còn thiếu, nếu tất cả các khối xây dựng cần thiết tồn tại và nó không bị vô hiệu hóa rõ ràng, là một ý tưởng tốt. Không phải là C # cho phép atm, afaik.
Ded repeatator

4
@greenoldman - Tôi hiểu động lực đó, nhưng cá nhân tôi, tôi sẽ thấy việc thay *=đổi một loại tham chiếu là không chính xác về mặt ngữ nghĩa.
Telastyn

Câu trả lời:


12

Tôi không thể tìm thấy tài liệu tham khảo cho điều này, nhưng sự hiểu biết của tôi là nhóm C # muốn cung cấp một tập hợp con quá tải của toán tử. Vào thời điểm đó, quá tải nhà điều hành đã có một bản rap tồi. Mọi người khẳng định rằng nó làm xáo trộn mã, và chỉ có thể được sử dụng cho mục đích xấu. Vào thời điểm C # đang được thiết kế, Java đã cho chúng ta thấy rằng không có quá tải toán tử nào gây khó chịu.

Vì vậy, C # muốn cân bằng quá tải toán tử để làm điều ác khó hơn, nhưng bạn cũng có thể tạo ra những điều tốt đẹp. Thay đổi ngữ nghĩa của bài tập là một trong những điều được coi là luôn luôn xấu xa. Bằng cách cho phép +=và thân nhân của nó bị quá tải, nó sẽ cho phép loại điều đó. Ví dụ: nếu làm thay +=đổi tham chiếu thay vì tạo một tham chiếu mới, nó sẽ không tuân theo ngữ nghĩa dự kiến, dẫn đến lỗi.


Cảm ơn bạn, nếu bạn không phiền tôi sẽ giữ câu hỏi này mở lâu hơn một chút và nếu không ai đánh bại bạn với lý do thiết kế thực tế, tôi sẽ đóng nó bằng cách chấp nhận câu hỏi của bạn. Cảm ơn bạn một lần nữa.
greenoldman

@greenoldman - cũng như bạn nên. Tôi cũng hy vọng ai đó đi kèm với một câu trả lời với các tài liệu tham khảo cụ thể hơn.
Telastyn

Vì vậy, đây là một nơi mà việc không thể nói cả về con trỏ và con trỏ thoải mái và rõ ràng là đầu của nó? Xấu hổ chết đi được.
Ded repeatator

"Mọi người đã khẳng định rằng nó làm xáo trộn mã" - mặc dù vậy, điều đó vẫn đúng, bạn đã thấy một số thư viện F # chưa? Tiếng ồn của người vận hành. Ví dụ: quanttec.com/fparsec
Den
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.