Có thể bắt chước giao diện Go trong C/C++ không?

Question

Trong Go, nếu kiểu có tất cả các phương thức mà giao diện được xác định thì nó có thể được gán cho biến giao diện đó mà không thừa kế một cách rõ ràng từ nó.

Có thể bắt chước tính năng này trong C/C++ không?

Answer 1

Yes. Bạn có thể sử dụng một lớp trừu tượng thuần túy và sử dụng một lớp mẫu để bọc các kiểu "triển khai" lớp trừu tượng để chúng mở rộng lớp trừu tượng. Dưới đây là ví dụ về barebones:

#include <iostream> 

// Interface type used in function signatures. 
class Iface { 
public: 
     virtual int method() const = 0; 
}; 

// Template wrapper for types implementing Iface 
template <typename T> 
class IfaceT: public Iface { 
public: 
     explicit IfaceT(T const t):_t(t) {} 
     virtual int method() const { return _t.method(); } 

private: 
     T const _t; 
}; 

// Type implementing Iface 
class Impl { 
public: 
     Impl(int x): _x(x) {} 
     int method() const { return _x; } 

private: 
     int _x; 
}; 


// Method accepting Iface parameter 
void printIface(Iface const &i) { 
     std::cout << i.method() << std::endl; 
} 

int main() { 
     printIface(IfaceT<Impl>(5)); 
} 

Answer 2

Tôi đoán một số tương đương thô có thể khả thi với GObject.

Answer 3

Có, tất nhiên.

Trong thực tế mã để xử lý các giao diện trong thời gian chạy được viết bằng C. http://code.google.com/p/go/source/browse/src/pkg/runtime/iface.c

Answer 4

Tôi đã sử dụng C++. Tôi đã kết thúc với một cái gì đó hoạt động, nhưng là một rạp xiếc vĩ mô: https://github.com/wkaras/c-plus-plus-misc/tree/master/IFACE. Giao diện là hai con trỏ, một con trỏ để đối tượng thành viên dữ liệu và một con trỏ tương đương với một bảng ảo (một cấu trúc con trỏ tới các hàm thunk gọi các hàm thành viên). Các bảng này (không may) được tạo vào thời gian chạy. Chuyển đổi từ giao diện sang giao diện con yêu cầu unordered_map tra cứu, vì vậy nó là O (1) độ phức tạp về thời gian trung bình. So với việc chuyển đổi một lớp con trỏ có nguồn gốc/tham chiếu đến một thành một lớp cơ sở, đó là O (1) trường hợp xấu nhất.

Nó không phải là rất có thể sử dụng, nhưng nó cho thấy rằng giao diện có thể được (sạch) thêm vào C + + với nỗ lực tương đối ít. Có những trường hợp giao diện tốt hơn OO dựa trên thừa kế, và con bò cũng ra khỏi chuồng càng xa càng cố gắng giữ cho C++ nhỏ.