Câu trả lời ngắn: Bạn đang pha trộn các khái niệm trước thời gian biên dịch và thời gian biên dịch có những điểm tương đồng trong mục đích của chúng. Các giao diện (các lớp trừu tượng và tất cả các triển khai mô hình hướng đối tượng) được tích hợp vào thời gian biên dịch . Các khái niệm là cùng một ý tưởng nhưng trong bối cảnh lập trình chung mà trong C ++ xảy ra TRƯỚC thời gian biên dịch . Chúng tôi chưa có tính năng cuối cùng này.
Nhưng hãy để tôi giải thích từ đầu.
Câu trả lời dài:
Trên thực tế, các khái niệm chỉ là thông tin ngôn ngữ và "dễ dàng hơn cho lập trình viên" về một thứ đã có trong ngôn ngữ, mà bạn có thể gọi là "gõ vịt".
Khi bạn chuyển một loại cho một hàm mẫu, đó là một hàm chung mà trình biên dịch sẽ tạo mã thực (nội tuyến) khi được gọi, loại đó cần phải có một số thuộc tính (đặc điểm?) Sẽ được sử dụng trong mã mẫu. Vì vậy, đó là ý tưởng gõ vịt NHƯNG tất cả được tạo ra và thực hiện vào thời gian biên dịch .
Điều gì xảy ra khi loại không có các thuộc tính cần thiết?
Vâng, trình biên dịch sẽ biết rằng chỉ có một vấn đề khi mã được tạo từ mẫu được biên dịch và bị lỗi. Điều đó có nghĩa là lỗi sẽ được tạo sẽ là một lỗi bên trong mã mẫu, lỗi này sẽ được hiển thị cho người lập trình là lỗi của anh ta. Ngoài ra, lỗi sẽ có hàng tấn thông tin do thông tin meta được cung cấp trong trường hợp tạo mã mẫu, để biết cách khởi tạo của mẫu mà chúng ta đang nói đến.
Một số vấn đề với điều đó: đầu tiên, hầu hết thời gian, mã mẫu là mã thư viện và hầu hết các lập trình viên là người sử dụng mã thư viện, không phải là người viết mã thư viện. Điều đó có nghĩa là loại lỗi khó hiểu này thực sự khó hiểu khi bạn không hiểu thư viện được viết như thế nào (không chỉ là thiết kế, cách nó được thực hiện). Vấn đề thứ hai là ngay cả khi lập trình viên đã viết mã mẫu, lý do thất bại vẫn có thể bị che khuất bởi vì trình biên dịch sẽ có thể nói rằng có một vấn đề quá muộn: khi mã được tạo đang được biên dịch. Nếu vấn đề liên quan đến các thuộc tính loại , thì nó nên kiểm tra ngay cả trước khi tạo mã.
Đó là những gì Khái niệm cho phép (và được thiết kế cho): cho phép lập trình viên (mã chung) chỉ định các thuộc tính của các loại được truyền dưới dạng tham số mẫu và sau đó cho phép trình biên dịch cung cấp các lỗi rõ ràng trong trường hợp các loại được cung cấp không đáp ứng yêu cầu.
Khi kiểm tra thành công, mã sẽ được tạo từ mẫu và sau đó được biên dịch, chắc chắn thành công.
Tất cả các kiểm tra Khái niệm xảy ra độc quyền trước thời gian biên dịch . Nó tự kiểm tra các loại, không phải các loại đối tượng . Không có đối tượng trước thời gian biên dịch.
Bây giờ, về "giao diện".
Khi bạn tạo một loại cơ sở trừu tượng hoặc ảo, bạn đang cho phép mã sử dụng nó để thao tác các đối tượng của các kiểu con mà không cần biết các triển khai thực sự của chúng. Để thực thi điều này, loại cơ sở phơi bày các thành viên ảo và có thể (hoặc phải) bị quá tải bởi các loại con.
Điều đó có nghĩa là trình biên dịch có thể kiểm tra tại thời điểm biên dịch rằng tất cả các đối tượng được truyền cho hàm yêu cầu tham chiếu đến lớp cơ sở phải 1. là một trong các kiểu con của lớp cơ sở, 2. kiểu con đó phải có các triển khai các hàm thuần ảo được khai báo trong các lớp cơ sở nếu có.
Vì vậy, tại thời gian biên dịch, trình biên dịch sẽ kiểm tra các giao diện của các loại đối tượng và báo cáo nếu thiếu một cái gì đó.
Đó là cùng một ý tưởng so với các khái niệm, nhưng nó xảy ra quá muộn , như đã nói trong phần mô tả Khái niệm. Nó xảy ra tại thời gian biên dịch. Chúng tôi không ở trong mã chung (mã mẫu), chúng tôi sau khi đã được xử lý và đã quá muộn để kiểm tra xem các loại có đáp ứng các yêu cầu chung hay không, có thể bị các lớp cơ sở ảo phơi bày. Trong thực tế, toàn bộ mô hình định hướng đối tượng trong C ++ thậm chí không tồn tại khi mã mẫu đang được xử lý. Không có đối tượng (chưa). Đó là
Các lớp mô tả các ràng buộc trên các đối tượng được sử dụng để kiểm tra các yêu cầu đối với các hàm thao tác với các đối tượng đó. Các khái niệm mô tả các ràng buộc về các loại (bao gồm các lớp) được sử dụng để kiểm tra các yêu cầu đối với mã chung để tạo mã thực từ các loại đó và kết hợp mã chung.
Vì vậy, một lần nữa, đó là "kiểm tra độ tỉnh" tương tự, nhưng trong một lớp khác của ngôn ngữ, đó là các mẫu. Mẫu là một ngôn ngữ đầy đủ (hoàn thành) cho phép lập trình meta, các loại lập trình ngay cả trước khi chúng xuất hiện trong mã được biên dịch. Nó hơi giống kịch bản trình biên dịch. Giả sử bạn có thể viết kịch bản, các lớp chỉ là các giá trị được thao tác bởi tập lệnh. Hiện tại, không có cách nào để kiểm tra các ràng buộc đối với các giá trị này ngoài việc phá vỡ tập lệnh theo cách không rõ ràng. Các khái niệm chỉ là: cung cấp nhập vào các giá trị này (mà trong mã được tạo là các loại). Không chắc là tôi rõ ...
Một sự khác biệt thực sự quan trọng khác giữa các lớp cơ sở ảo và các khái niệm là lớp thứ nhất buộc có mối quan hệ chặt chẽ giữa các loại, khiến chúng "bị ràng buộc bởi máu". Trong khi siêu lập trình mẫu cho phép "gõ vịt" mà các khái niệm chỉ cho phép làm cho các yêu cầu rõ ràng hơn.