WinRT thực sự có thể được sử dụng tại các ranh giới không?

Microsoft (chủ yếu, Herb Sutter ) khuyến nghị khi sử dụng WinRT với C ++ / CX để giữ WinRT ở ranh giới của ứng dụng và giữ cốt lõi của ứng dụng được viết theo tiêu chuẩn ISO C ++.

Tôi đã viết một ứng dụng mà tôi muốn để lại di động, vì vậy chức năng cốt lõi của tôi đã được viết bằng C ++ tiêu chuẩn và hiện tôi đang cố gắng viết một giao diện người dùng kiểu Metro cho nó bằng C ++ / CX. Tuy nhiên, tôi đã có một chút vấn đề với cách tiếp cận này. Ví dụ: nếu tôi muốn đẩy một vectơ các loại C ++ do người dùng định nghĩa sang điều khiển ListView XAML, tôi phải bọc loại do người dùng xác định trong loại ref / value của WinRT để nó được lưu trữ trong a Vector^. Với cách tiếp cận này, tôi chắc chắn sẽ rời đi với việc gói một phần lớn các lớp C ++ của mình với các lớp WinRT.

Đây là lần đầu tiên tôi thử viết một ứng dụng gốc di động trong C ++. Có thực sự thiết thực để giữ WinRT dọc theo ranh giới như thế này không? Làm thế nào khác loại lõi di động có ranh giới dành riêng cho nền tảng này có thể được xử lý?

c++ portability winrt

— Bret Kuhns
nguồn

Một cái gì đó giống như MVVM, trong đó Model là tiêu chuẩn C ++, V và VM là các đối tượng xen kẽ WinRT?

— Tối đa

"nhưng mỗi VM thực sự biến thành một trình bao bọc xung quanh các mô hình tiêu chuẩn của tôi." - đó là khá phổ biến cho các mô hình xem trong bất kỳ kịch bản.

— MattDavey

@ GlenH7, tôi tin rằng hầu hết các ý kiến đã trả lời điều này cho tôi. Tôi đã đi đến kết luận tương tự, nhưng hy vọng ai đó có một ý tưởng thông minh hơn trong đầu. Nói chung, mọi thứ chỉ là như vậy. Bạn có thể cố gắng hết sức để cô lập các phần của mã của mình, nhưng đối với hầu hết các phần, cuối cùng bạn sẽ cần phải viết lại các phần mã cụ thể của nền tảng (chẳng hạn như trong các ví dụ ViewModel ở trên).

— Bret Kuhns

@ GlenH7 Có lẽ cách duy nhất để giữ mã ứng dụng của bạn nhất quán trên các nền tảng là viết lớp trừu tượng nền tảng của riêng bạn, nhưng những lớp đó cuối cùng sẽ là điều tôi cố gắng tránh ở nơi đầu tiên. Nó chỉ đơn giản là di chuyển vấn đề xung quanh với một sự trừu tượng hóa lớp để cô lập mọi thứ. Có lẽ sẽ giúp, nhưng cuối cùng bạn vẫn đang làm việc.

— Bret Kuhns

Chúng tôi đã thử một lần để tạo ra một "viên đạn bạc" để dán liền mạch thư viện C vào Java trên Android. Cuối cùng, nó có thể hoạt động, sau khi dành thêm ~ × 10 thời gian nữa và sử dụng các kỹ thuật sửa lỗi kỳ lạ (để khắc phục các hành vi bất thường ở biên giới). Chắc chắn, đó là niềm vui.

— Alex Cohn

Câu trả lời:

IMHO (lập trình viên cũ; làm việc tại Microsoft nhưng đây là ý kiến cá nhân): trước khi tôi có thể trả lời câu hỏi này, bạn phải trả lời câu hỏi khác này:

Mã di chuyển đến đâu? Nếu bạn đang gắn bó với một nền tảng duy nhất (trong trường hợp này là WinRT), thì hãy gần với nền tảng đó - và điều đó có nghĩa là sử dụng các khái niệm trừu tượng hiện có. Theo ví dụ của bạn, mã của bạn sau đó sẽ sử dụng Vector ^ để phù hợp với nhu cầu WinRT.

OTOH, nếu bạn đang di chuyển đi nơi khác (đá VMS!), Thì các tiêu chuẩn dựa trên có ý nghĩa.

Cho rằng ba nền tảng di động, giống như máy tính bảng lớn nhất trên thị trường đều sử dụng các ngôn ngữ khác nhau cho các tác vụ lập trình phổ biến, di chuyển mã có thể không phải là một lựa chọn có giá trị.

— PESMITH_MSFT
nguồn

Tôi đồng ý. Tôi đã bắt đầu dự án nhắm mục tiêu WinRT, nhưng biết Android / iOS sẽ là nền tảng hấp dẫn để chuyển đến, điều này đã đặt ra câu hỏi này. Kể từ đó tôi đã quyết định chỉ viết riêng cho WinRT. Nếu dự án tự thu hút đám đông, tôi sẽ lo lắng về việc chuyển (hoặc đúng hơn là viết lại sang nền tảng khác).

— Bret Kuhns

Như @alexcohn đã chỉ ra, nếu chức năng cốt lõi đủ nặng vào thời điểm tôi quyết định chuyển sang nền tảng chéo, thì nó sẽ có giá trị gói mã di động với các lớp cụ thể của nền tảng. Mặt khác, tôi sẽ chỉ viết lại mã và sử dụng các bộ kiểm tra để xác minh hành vi trên các nền tảng khác nhau (khi thích hợp).

— Bret Kuhns

Bạn không phải sử dụng C ++ / CX, thay vào đó bạn có thể sử dụng WRL ( Thư viện thời gian chạy Windows ) giống như các mẫu ATL cũ, không phải là 'giả vờ' C ++ là C ++ / CX. Đây là cách tiếp cận "cấp thấp" từ MS đến tiêu thụ các đối tượng WinRT và hoàn toàn là C ++ tiêu chuẩn như Grandad đã từng viết!

Nó có thể không "đẹp" như C ++ / CX nhưng đó là vấn đề quan điểm - ý kiến cá nhân của tôi là C ++ / CX là nỗ lực thứ 3 tại C ++ mở rộng và là thất bại thứ 3. Bỏ qua nó và hy vọng nó đi theo cách tương tự như 2 hóa thân khác.

— gbjbaanb
nguồn