2010-09-05 25 views
8

Hãy tưởng tượng bạn đã được cung cấp hai System.Type và bạn muốn xác định xem có chuyển đổi loại ẩn hoặc rõ ràng từ cái này sang cái khác không.Kiểm tra xem loại có hỗ trợ chuyển đổi loại ẩn hoặc rõ ràng sang loại khác với .NET

Nếu không kiểm tra cụ thể các phương pháp tĩnh, có phương pháp tích hợp để xác định loại hỗ trợ hoặc chuyển đổi này không?

Tôi biết đây là nội dung ngắn gọn cho câu hỏi nhưng tôi nghĩ kịch bản tương đối dễ giải thích, hãy cho tôi biết nếu không.

Xin cảm ơn trước, Stephen.

+0

Ý bạn là gì khi 'chuyển đổi loại' - khả năng gán các phiên bản hoặc khả năng chuyển đổi theo nghĩa 'TypeConverter'? –

+0

Cụ thể là các toán tử ngầm/rõ ràng được viết bằng C# (xem http://msdn.microsoft.com/en-us/library/z5z9kes2(VS.71).aspx và http://msdn.microsoft.com/en-us/ library/xhbhezf4 (VS.71) .aspx) – meandmycode

+0

bản sao có thể có của [Làm thế nào để kiểm tra xem có ẩn hay rõ ràng cast tồn tại?] (http://stackoverflow.com/questions/1815452/how-to-check-if-implicit- or-explicit-cast-exist) – nawfal

Trả lời

8

Expression.Convert có thể tìm kiếm toán tử chuyển đổi do người dùng xác định, nhưng tiếc là nó sẽ chỉ ném ngoại lệ nếu không tìm thấy. Bạn có thể sử dụng nó như thế này:

public static bool CanConvert(Type fromType, Type toType) 
{ 
    try 
    { 
     // Throws an exception if there is no conversion from fromType to toType 
     Expression.Convert(Expression.Parameter(fromType, null), toType); 
     return true; 
    } 
    catch 
    { 
     return false; 
    } 
} 
+0

Cảm ơn Quartermeister, đây chắc chắn là một giải pháp! – meandmycode

+2

@meandmycode: Nếu bạn muốn thực hiện cùng một điều mà không có chi phí của một ngoại lệ, bạn có thể chạy Reflector on Expression.Convert để xem chính xác những gì nó làm. Các phương thức thú vị là HasIdentityPrimitiveOrNullableConversion, HasReferenceConversion và GetUserDefinedCoercionMethod trong System.Dynamic.Utils.TypeUtils. – Quartermeister

+0

Rất tốt, cảm ơn vì nỗ lực nghiên cứu, tôi không hoàn toàn tránh được mã được đề xuất của bạn, ngay cả khi tôi triển khai các phương thức như TypeUtils, nó có thể kết thúc nhiều công việc để duy trì điều đó hơn là chỉ bắt ngoại lệ. – meandmycode

0

Bạn có thể thử đúc mỗi người sang người kia và bắt ngoại trừ

+0

Thật không may là tôi chỉ có quyền truy cập vào đối tượng Type, không phải chính các đối tượng thực tế, vì vậy tôi sẽ không thể thực hiện việc này. – meandmycode

0

Tôi nghĩ Type.IsAssignableFrom nên cung cấp cho bạn những gì bạn cần.

[sửa] lưu ý rằng điều này KHÔNG xem xét các toán tử chuyển đổi, vì vậy có thể điều này không hữu ích đối với bạn. Đáng nói đến anyway.

+0

Điều đó sẽ không xem xét bất kỳ nhà điều hành chuyển đổi tùy chỉnh nào. Nó chỉ nhìn vào hệ thống phân cấp kiểu. – driis

+0

Tôi không chắc chắn điều này xử lý các toán tử chuyển đổi loại tiềm ẩn/rõ ràng mà bạn có thể xác định bằng C#. Ví dụ nếu tôi viết typeof (XName) .IsAssignableFrom (typeof (string)) tôi nhận được sai. Nhưng XName không có chuyển đổi kiểu ngầm từ chuỗi. – meandmycode

7

Tôi không nghĩ vậy. Bạn sẽ phải sử dụng sự phản chiếu và tìm kiếm những phương pháp tốt ol 'op_Implicitop_Explicit tĩnh trên mỗi loại.

này sẽ trả về các câu hỏi rất thú vị: trong đó có một tác động hiệu suất cao hơn, phản ánh (câu trả lời này) hoặc sử dụng ngoại lệ cho dòng điều khiển (Quartermeister's)? Tôi thành thật không thể đoán được. Bạn có thể muốn cấu hình mỗi và tìm ra cho chính mình.

+0

Eep, có lẽ đây không phải là một điều xấu, tôi đã lo lắng rằng việc tìm kiếm những phương pháp đặc biệt có tên là mong manh, nhưng mặt khác tôi sẽ không bao giờ mong đợi những tên phương pháp này thay đổi! – meandmycode

+0

@meandmycode: Vâng, tôi không chắc liệu chúng có thực sự được chỉ định hay không; nhưng tôi nghĩ về chúng như là trong cùng một thể loại như 'get_' và' set_' phương pháp cho các thuộc tính - * rất * không thay đổi (mặc dù tôi chia sẻ sự khó chịu của bạn với cách tiếp cận "dưới mui xe"). –

+0

Tôi không chắc chắn 100% nhưng gần :) Tôi nghĩ bạn sẽ bỏ lỡ một số xây dựng trong chuyển đổi nếu bạn chỉ tìm kiếm các phương pháp này như int để dài và bắt nguồn từ cơ sở/giao diện. Shich sẽ làm tăng sự mong manh của giải pháp vì những thay đổi khác so với việc thay đổi tên của phương pháp sau đó sẽ là một sự thay đổi đột phá –

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