Tại sao C ++ không thể áp dụng cách tiếp cận của D để thực hiện khái niệm của nó?


19

Như nhiều bạn đã biết, các khái niệm , cách tiếp cận của C ++ để ràng buộc các kiểu có thể cho một đối số khuôn mẫu đã không được đưa vào C ++ 11.

Tôi đã học được rằng ngôn ngữ lập trình D 2.0 có một tính năng tương tự cho lập trình chung của nó. Giải pháp của nó có vẻ với tôi khá thanh lịch và đơn giản.

Vì vậy, câu hỏi của tôi là tại sao C ++ không thể sử dụng một cách tiếp cận tương tự .

  • Mục tiêu của khái niệm C ++ có thể lớn hơn những gì triển khai của D cung cấp?
  • Hoặc di sản của C ++ ngăn không cho nó áp dụng cách tiếp cận như vậy?
  • Hay bất cứ thứ gì khác?

Cảm ơn câu trả lời của bạn.

ps Để xem một số ví dụ về sức mạnh lập trình chung của D, vui lòng tham khảo điều này: /programming/7300298/metaprogramming-in-c-and-in-d/7303534#7303534


2
Câu hỏi này nên đã được di chuyển đến lập trình viên. (Tôi đã bỏ phiếu cho điều đó, nhưng 3 phiếu là "không mang tính xây dựng").
iammilind

3
Tôi nghĩ rằng câu hỏi có thể không được viết theo cách xây dựng nhất, nhưng có giá trị về nó. Tôi rất thích ai đó giải thích cách D quản lý các khái niệm và có thể so sánh nó với hai cách tiếp cận chính mà ủy ban C ++ đã thực hiện trước khi họ quyết định hoãn hoàn toàn tính năng này ... Nếu điều này bị đóng lại, thì nó nên ít nhất được chuyển đến lập trình viên
David Rodríguez - dribeas

2
@David: Tôi đã bình chọn để mở lại (và sau đó có thể, nó có thể được chuyển đến trang web lập trình viên)
Nawaz

1
Đồng ý với David. Tôi thấy không có lý do gì để nói "không mang tính xây dựng" trước khi bất cứ ai thậm chí có thể cố gắng xây dựng một cái gì đó. với 0 câu trả lời, "tính xây dựng" là 0/0 do đó không xác định được.
Emilio Garavaglia

1
@ jj1: Bạn có thể cung cấp một lời giải thích ngắn về cách tiếp cận của D cho những người trong chúng ta không biết ngôn ngữ không?
David Rodríguez - dribeas

Câu trả lời:


9

Tiêu chuẩn của C ++ là một tài liệu quy phạm, đặt ra các quy tắc sẽ vẫn còn (hầu hết không bị ảnh hưởng) trong các tài liệu trong tương lai. Do đó, ủy ban đã có một cách tiếp cận rất thận trọng đối với các cập nhật của nó.

Việc bổ sung vào thư viện tiêu chuẩn có phần dễ dàng. Một số thư viện đã ở trong Boost trong một thời gian dài: nó đã được chứng minh rằng họ đã làm việc.

Tuy nhiên, việc bổ sung các khái niệm cốt lõi trong ngôn ngữ khó khăn hơn nhiều để thử nghiệm, bởi vì trước tiên nó yêu cầu sửa đổi trình biên dịch. Một tính năng C ++ 03 (xuất khẩu các mẫu) đã được chỉ định mà không có hỗ trợ trình biên dịch ... kết quả thật tồi tệ. Những người triển khai trình biên dịch EDG đã báo cáo nó là một nhiệm vụ lớn (vài năm) cho lợi ích rất ít. Không có trình biên dịch nào khác từng cố gắng thực hiện nó. Đó không phải là một tình huống thoải mái.

Các tính năng như constexprhoặc static_assertdễ dàng (và đã được các thư viện mô phỏng). Lambdas được hiểu khá rõ và thực hiện bằng nhiều ngôn ngữ khác nhau, đã có nghiên cứu sâu rộng, vì vậy chủ yếu là vấn đề cú pháp.

Mặt khác, các khái niệm được đánh giá là quá mớichưa được thử nghiệm . Họ hầu như không được chỉ định kịp thời, không có bằng chứng về khái niệm ... và do đó họ đã bị từ chối, thay vì chờ đợi họ (hoặc phạm sai lầm).

Tại sao không theo D? Không có gì để nói rằng nó sẽ không. Ủy ban đã khuyến khích mọi người suy nghĩ lại từ đầu, không có thời hạn thúc giục và thử đưa chúng vào một trình biên dịch để xem cách chúng tương tác với các tính năng khác trong ngôn ngữ. Đáng chú ý có câu hỏi về phân tách khái niệm và bản đồ khái niệm: chúng có nên được bó lại thành một hay không?

FYI: Hiện tại có một chi nhánh của Clang dành riêng cho thử nghiệm này, dẫn đầu bởi Larisse Voufo từ trường đại học Indiana.


Nhận xét nhỏ: từ khóa xuất thực sự là một tính năng c ++ 98 (tiêu chuẩn hóa ban đầu). Bản sửa lỗi năm 2003 chủ yếu đề cập đến các tính năng của thư viện.
ex0du5

@ ex0du5: Phải, '03 là bản sửa đổi nhỏ của Tiêu chuẩn C ++ 98, chủ yếu liên quan đến chỉnh sửa.
Matthieu M.

3

Đối với tiêu chuẩn năm 2011, các khái niệm C ++ là những gì đang được thực hiện và cuối cùng chúng đã bị loại bỏ khỏi tiêu chuẩn đó, vì chúng không "nướng đủ". Công việc tiếp tục trên các khái niệm C ++ có thể dẫn đến việc đưa chúng vào tiêu chuẩn tiếp theo. Tuy nhiên, có thể một số người sẽ làm việc theo đề xuất cho tiêu chuẩn tiếp theo tương tự như các ràng buộc mẫu của D. Cho dù điều đó xảy ra hay không vẫn còn được nhìn thấy. Theo như tôi biết, không có đề xuất nào cho tiêu chuẩn năm 2011, vì vậy không có cơ hội nào để đưa nó vào tiêu chuẩn đó bất kể giá trị của nó là gì, nhưng điều gì sẽ hoặc không biến nó thành tiêu chuẩn tiếp theo là hoàn toàn không biết tại điểm này.

Tôi không biết bất kỳ lý do chính nào khiến cho một số điều tương tự như các ràng buộc mẫu của D không thể được triển khai cho C ++, mặc dù C ++ thường bị hạn chế hơn về những gì nó có thể làm trong thời gian biên dịch, có thể khó hơn để làm cho chúng hoạt động hoàn toàn như cũng như họ làm trong D (mặc dù việc giới thiệu những thứ như constexprchắc chắn có ích).

Vì vậy, thực sự, tôi nghĩ rằng câu trả lời ngắn gọn là không có lý do kỹ thuật tại sao một cái gì đó tương tự như các ràng buộc mẫu của D không thể có trong C ++.

Câu hỏi đặt ra là liệu một đề xuất như vậy sẽ được thực hiện cho tiêu chuẩn tiếp theo hay không và nó sẽ so sánh với bất kỳ đề xuất tương tự nào được đưa ra (ví dụ như các đề xuất liên quan đến các khái niệm). Giả sử rằng một đề xuất có thể chấp nhận có thể được thực hiện, tôi hoàn toàn mong đợi rằng một cái gì đó tương tự như các khái niệm hoặc các ràng buộc mẫu của D sẽ biến nó thành tiêu chuẩn tiếp theo đơn giản chỉ vì có rất nhiều mong muốn về nó. Câu hỏi đặt ra là liệu có ai có thể đưa ra một đề xuất đủ vững chắc và "nướng đủ" để được chấp nhận hay không.


2

Ý bạn là ràng buộc mẫu của D?

Theo như tôi biết, các khái niệm C ++ đã được đề xuất thay mặt cho khái niệm boost ::. Vấn đề ở đây là boost là một thư viện được viết cho C ++ 03. C ++ 11 có các khả năng cú pháp khác cho phép thực hiện một số điều theo một cách khác mà C ++ 03 cho phép (do đó, bản thân boost có thể được viết lại bằng cách tận dụng cú pháp mới).

Ủy ban tiêu chuẩn đã bỏ các khái niệm vì sẽ mất quá nhiều thời gian để chỉ định chúng (do đó trì hoãn lại việc phê duyệt c ++ 11). Họ có thể sẽ đi trong phiên bản C ++ tiếp theo.

Trong khi đó, cú pháp D khác với C ++ và bản thân D giữ lại một số khả năng đánh giá biểu thức tại thời điểm biên dịch C ++ không thể luôn có mà không phá vỡ một số mã kế thừa (thứ D không có, có lịch sử ngắn hơn). Bản thân C ++ hiện đã có static_assertcostexprcho phép cải thiện khả năng đánh giá thời gian biên dịch. Có thể trong tương lai sẽ đạt đến một mức độ tương tự.


2

Đây là một QA với Herb Sutter, anh ấy nói về các khái niệm ở mốc 15 phút.

http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Questions-and-Answers

Nếu bạn thích điều đó, đây là một cái khác: http://channel9.msdn.com/Shows/Going+Deep/Conversation-with-Herb-Sutter-Perspectives-on-Modern-C0x11

Bây giờ như câu hỏi của bạn. Tại sao không phải là phiên bản D? Vâng tại sao sử dụng nó? C ++ là một ngôn ngữ rất phức tạp và ổn định. Mỗi tính năng cần phải được lựa chọn cực kỳ cẩn thận, bởi vì nó thường phải được hỗ trợ trong nhiều thập kỷ. Nếu bạn nhìn vào tiêu chuẩn C ++ đầu tiên và tuân theo các sửa đổi, có một số tính năng không dùng nữa, nhưng ngay cả những tính năng này vẫn phải được hỗ trợ. Vì vậy, nó có ý nghĩa để thiết kế các khái niệm để phù hợp với C ++ 100%.

Về lý do tại sao nó không được bao gồm trong C ++ 0x. Vâng vì nó rất lớn. Đề xuất dài 100 trang và rất khó thực hiện. Nó đã được quyết định rằng tính năng này cần thêm thời gian để trưởng thành cho đến khi nó được đưa vào tiêu chuẩn.


2

Nói một cách đơn giản, C ++ có nhiều hành lý lịch sử hơn D. Nó sẽ dễ dàng thực hiện hơn rất nhiều điều nếu thực tế là C ++ có số lượng lớn mã lịch sử phải tiếp tục hoạt động chính xác và như mong đợi. D không có vấn đề này.


Có thể bạn đã hiểu sai, nhưng vấn đề không phải là mã kế thừa, vấn đề là bất kỳ tính năng mới nào sẽ có mặt trong ngôn ngữ trong nhiều thập kỷ và phải được hỗ trợ. Điều đó có nghĩa là mỗi tính năng mới phải được lựa chọn rất cẩn thận.
Let_Me_Be

@Let_Me_Be: Đúng vậy, vấn đề nằm ở mã kế thừa, chúng tôi sẽ giảm mười năm nếu chúng ta đưa ra các khái niệm ngay bây giờ.
David Thornley
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.