2011-12-12 22 views
21

Định dạng của đầu ra là type_info::name() là cài đặt cụ thể.Có một trình bao bọc di động cho C++ type_info chuẩn hóa định dạng chuỗi kiểu tên không?

namespace N { struct A; } 

const N::A *a; 

typeid(a).name(); // returns e.g. "const struct N::A" but compiler-specific 

Có ai đó viết một gói trả về thông tin đáng tin cậy, có thể đoán trước giống nhau trên các trình biên dịch. Nhiều chức năng templated sẽ cho phép người dùng để có được thông tin cụ thể về một loại. Vì vậy, tôi có thể sử dụng:

MyTypeInfo::name(a); // returns "const struct N::A *" 
MyTypeInfo::base(a); // returns "A" 
MyTypeInfo::pointer(a); // returns "*" 
MyTypeInfo::nameSpace(a); // returns "N" 
MyTypeInfo::cv(a); // returns "const" 

Các chức năng này chỉ là ví dụ, người có kiến ​​thức tốt hơn về hệ thống loại C++ có thể thiết kế API tốt hơn. Người tôi quan tâm ở số base(). Tất cả các hàm sẽ tăng ngoại lệ nếu RTTI bị vô hiệu hóa hoặc một trình biên dịch không được hỗ trợ được phát hiện.

Điều này có vẻ giống như những thứ mà Boost có thể triển khai, nhưng tôi không thể tìm thấy nó ở bất kỳ đâu. Có thư viện di động nào không?

+0

Tôi không biết gì cả, nhưng có vẻ như đó là một ý tưởng hay. (Chính thức, tiêu chuẩn cho phép thực hiện trả về '" "' cho tất cả các loại, nhưng thực tế, hầu hết các triển khai trả về một cái gì đó trực tiếp có thể sử dụng được, và những cái không trả lại tên bị xáo trộn, có thể bị phân tách.) –

+1

Tôi có thể thấy là chuỗi này hoàn toàn được triển khai cụ thể và không được đảm bảo để thể hiện chính xác loại chính nó. Thậm chí tệ hơn, nó thậm chí có thể không phải là duy nhất. –

+0

@Matthieu - thư viện phát hiện các trình biên dịch như vậy và cuộc gọi không thành công. Người gọi phải sống với nó.Các trình biên dịch mà hầu hết chúng ta sử dụng cung cấp thông tin hữu ích trong 'type_info'. – paperjam

Trả lời

2

Có một số hạn chế để thực hiện những việc như vậy trong C++, vì vậy bạn có thể sẽ không tìm thấy chính xác những gì bạn muốn trong tương lai gần. Siêu thông tin về các kiểu mà trình biên dịch chèn vào trong mã được biên dịch cũng được triển khai cụ thể cho RTL được trình biên dịch sử dụng, do đó sẽ rất khó cho thư viện của bên thứ ba thực hiện công việc tốt mà không dựa vào các tính năng không có giấy tờ của từng trình biên dịch cụ thể có thể bị hỏng trong các phiên bản sau.

Khuôn khổ Qt, theo kiến ​​thức của tôi, điều gần nhất với những gì bạn dự định. Nhưng họ làm điều đó hoàn toàn độc lập với RTTI. Thay vào đó, họ có "trình biên dịch" của riêng họ để phân tích cú pháp mã nguồn và tạo ra các mô-đun nguồn bổ sung với siêu thông tin. Sau đó, bạn biên dịch + liên kết các mô-đun này cùng với chương trình của bạn và sử dụng API của chúng để nhận thông tin. Hãy nhìn vào http://doc.qt.nokia.com/latest/metaobjects.html

+0

Tôi không thấy nhiều vấn đề. Có một cái gì đó mà làm việc ít nhất với * một số * trình biên dịch là tốt hơn so với không có gì, imho. – zerm

+0

Tôi nghĩ rằng điều này có thể được thực hiện mạnh mẽ trên tất cả các trình biên dịch vì tự kiểm tra là tầm thường với chi phí thời gian chạy thấp. – paperjam

+0

@paperjam: và unittests luôn luôn có giá trị nó anyway :) –

1

Jeremy Pack (từ Boost khuôn khổ plugin mở rộng) có vẻ đã viết một điều như vậy:

http://blog.redshoelace.com/2009/06/resource-management-across-dll.html

  3. RTTI không phải lúc nào hoạt động như mong đợi qua các biên giới DLL . Hãy xem các lớp type_info để xem cách tôi giải quyết vấn đề đó.

Vì vậy, bạn có thể xem ở đó.


PS. Tôi nhớ vì tôi đã từng sửa một lỗi trong khu vực đó; vẫn có thể thêm vào này thông tin vì vậy đây là liên kết: https://stackoverflow.com/a/5838527/85371

+0

Tôi không chắc chắn điều này không hoàn toàn những gì tôi yêu cầu - Tôi quan tâm đến chuỗi tên loại thực tế, không so sánh các loại. – paperjam

Các vấn đề liên quan