Tôi muốn phát triển một ứng dụng cửa sổ. Nếu tôi sử dụng native C++ và MFC cho giao diện người dùng thì ứng dụng sẽ rất nhanh và nhỏ. Nhưng việc sử dụng MFC rất phức tạp. Ngoài ra Nếu tôi sử dụng C# thì ứng dụng sẽ chậm hơn so với mã gốc và Nó hỗ trợ .NET framework để chạy. Nhưng việc phát triển GUI rất dễ dàng bằng cách sử dụng WinForm. Bạn thích cái nào hơn?Tôi nên sử dụng nền tảng nào: native C++ hoặc C#?
"nhanh" và "chậm" là chủ quan, đặc biệt là với PC hiện tại. Tôi không nói cố ý làm cho điều này chậm, nhưng không có gần như là nhiều chi phí trong việc viết một ứng dụng được quản lý như bạn nghĩ. JIT vv hoạt động rất tốt để làm cho mã thực thi rất nhanh. Và bạn cũng có thể NGEN cho tốc độ khởi động thêm nếu bạn thực sự cần.
Trên thực tế, nếu bạn có thời gian để tìm hiểu nó, bạn có thể muốn xem xét WPF hơn là Winform - đây là một kỹ năng thiết lập khác nhau, nhưng cho phép bạn tận dụng rất tốt của phần cứng đồ họa vv
Cũng - .NET framework đi kèm với các cài đặt hệ điều hành mới, và vẫn còn rất phổ biến trên những cài đặt trước đó. Vì vậy, đối với tôi nó sẽ là một sự lựa chọn khá rõ ràng để phát triển với C# /. NET. Thời gian để phát triển mạnh mẽ và được kiểm tra đầy đủ Ứng dụng C++ (không có rò rỉ, v.v.) là (đối với tôi ít nhất) lớn hơn nhiều so với C#.
Yep, C# .net có vẻ giống như một sự lựa chọn thực tế hơn ở đây. – Kon
Tôi không nghĩ rằng "chủ quan chậm" được xác định bởi chi phí nữa - nhưng chủ yếu là do sự đáp ứng của giao diện người dùng. – peterchen
Làm cho một ứng dụng không bị rò rỉ là một điều dễ dàng .. Nếu bạn cấu trúc .. Tôi đã không bị rò rỉ trong nhiều năm. Điều đó nói rằng .. Tôi sẽ đi với C# quá .. Chỉ cần một thị trường lớn hơn. – baash05
Ứng dụng C# chậm hơn so với ứng dụng MFC, nhưng bạn có thể không nhận thấy sự khác biệt về tốc độ giữa hai ứng dụng khi ứng dụng được tải.
Điều đó đúng, nhưng CLR 4 (.NET 4.0) sẽ cải thiện đáng kể thời gian bắt đầu lạnh của một ứng dụng .NET. –
Cẩn thận để không tối ưu hóa quá sớm; bạn đề cập đến tốc độ của mã nhưng đối với hầu hết các hoạt động giao diện người dùng Windows, sự khác biệt là không đáng chú ý vì các nút cổ chai chính của bản vẽ và truy cập đĩa không khác nhau cho một trong hai cách tiếp cận.
Khuyến nghị của tôi là bạn sử dụng C# và WPF hoặc WinForms cho giao diện người dùng của bạn. Nếu bạn gặp phải một số chậm xuống, sử dụng một hồ sơ để xác định nơi và sau đó xem xét thay thế một số logic kinh doanh với mã nguồn gốc, nhưng chỉ khi có một lợi ích.
Có rất nhiều ứng dụng Windows có thể có và mỗi ứng dụng đều có các yêu cầu riêng.
Nếu ứng dụng của bạn cần phải nhanh (và những gì tôi làm việc trên đó), thì C++ gốc là một cách tốt để đi.
Nếu ứng dụng của bạn cần nhỏ (có thể để truyền thực sự nhanh qua các dòng chậm), thì hãy sử dụng bất cứ thứ gì nhỏ.
Nếu ứng dụng của bạn có khả năng được tải xuống rất nhiều, có thể bạn sẽ muốn có các phiên bản .NET sau này, mà người dùng của bạn có thể chưa có.
Nếu, giống như hầu hết, nó sẽ đủ nhanh và nhỏ trên các hệ thống có khả năng được sử dụng, sử dụng những gì sẽ cho phép bạn phát triển nhanh nhất và tốt nhất.
Trong hầu hết các trường hợp, điều đúng đắn để tối ưu hóa là nỗ lực của nhà phát triển. Sử dụng bất cứ điều gì có được một công việc chất lượng cao được thực hiện nhanh nhất và tốt nhất.
Không có thông tin về đơn đăng ký bạn dự định phát triển, tôi bầu cho WPF.
Lựa chọn ngôn ngữ hoặc công cụ cần được quyết định bởi các yêu cầu chức năng và hiệu suất của dự án và chuyên môn của bạn. Nếu hiệu suất là một sự cân nhắc thực sự cho bạn và bạn đã thực hiện một số phân tích để thích C++ hơn C#, thì bạn đã có một quyết định rồi. Lưu ý rằng mặc dù có ứng dụng dựa trên MFC là không hiệu quả khủng khiếp hoặc. Mặt khác, chi phí đầu vào.Các ứng dụng NET được ghi rõ.
Hiệu suất là một cái gì đó thực sự là một chức năng về mức độ bạn viết mã của bạn và những yêu cầu về khả năng mở rộng nào tồn tại. Nếu bạn chỉ phải làm việc với một máy khách với một bản ghi cơ sở dữ liệu tối đa là 1K, thì chúng ta không nên nói về hiệu suất.
Nếu dễ phát triển và bảo trì là quan trọng hơn, chắc chắn C# sẽ là lựa chọn.
Vì vậy, tôi không chắc đây là câu hỏi có thể được trả lời là lựa chọn A hoặc B với dữ liệu bạn đã cung cấp. Bạn cần phân tích các yêu cầu chức năng và phi chức năng và quyết định.
Cũng lưu ý rằng hầu hết máy tính Windows đã cài đặt .NET trên máy tính, do đó thực sự không phải là mối quan ngại.
Ngoài ra, ngoài cài đặt .NET, các ứng dụng .NET có xu hướng khá nhỏ.
Và đối với hầu hết ứng dụng có giao diện người dùng, tốc độ của Người dùng là yếu tố thời gian thực sự hạn chế.
Theo ý kiến của tôi, các yêu cầu sẽ giúp bạn quyết định nền tảng. Điều gì quan trọng hơn: Có một ứng dụng dễ bảo trì hoặc một ứng dụng phải cực kỳ nhanh và nhỏ?
Một lớp lớn các ứng dụng hiện nay có thể được viết bằng .NET và mã được quản lý và điều này mang lại lợi ích chung cho sự phát triển trong dài hạn. Theo kinh nghiệm của tôi, các ứng dụng .NET thường đủ nhanh cho hầu hết các trường hợp sử dụng và chúng đơn giản hơn để tạo ra. Native C++ vẫn có sử dụng, nhưng chỉ để "nhanh hơn và nhỏ hơn", khi "đủ nhanh và đủ nhỏ" là đủ không đủ âm thanh như một biện minh.
ứng dụngCũng Nếu tôi sử dụng C# sau đó ứng dụng sẽ chậm hơn so với mã nguồn gốc và Nó reqiures .NET framework để chạy
Một MFC đòi hỏi dll của MFC để chạy (và có lẽ VC runtime cũng !), do đó, chúng có thể cần phải được cài đặt, hoặc nếu chúng được liên kết tĩnh, bạn thêm vào kích thước của exe.
Đối số tốc độ giữa mã gốc và mã được quản lý phần lớn không phải là vấn đề tại thời điểm này. Mỗi bản phát hành của Khuôn khổ .NET làm cho các cải thiện hiệu suất so với các phiên bản trước và hiệu suất ứng dụng luôn là ưu tiên rất cao đối với các nhóm phát triển .NET.
Bắt đầu với Windows Vista và Windows Server 2008, Khuôn khổ .NET được cài đặt như một phần của hệ điều hành. Nó cũng là một phần của Windows Update nên hầu như bất kỳ hệ thống Windows XP nào cũng sẽ được cài đặt. Nếu yêu cầu khung được cài đặt trên máy đích thực sự là vấn đề thì cũng có các trình biên dịch về cơ bản sẽ nhúng các phần thời gian chạy cần thiết vào ứng dụng của bạn để tạo ra một exe duy nhất, nhưng chúng đắt tiền (và theo ý kiến của tôi, không thực sự đáng giá).
Blockquote
NET là dễ dàng hơn để làm việc với. Trừ khi bạn sẽ mất người dùng bằng cách sử dụng nó hoặc sẽ gặp sự cố khi di chuyển mã, bạn có thể nên sử dụng .NET. Rất khó có khả năng tốc độ này sẽ là một vấn đề cho việc này. Kích thước có lẽ cũng không quan trọng lắm.
MFC không khó để tìm hiểu, thực sự nó rất dễ dàng.
Hầu như bằng C#.
đồng ý .. Tôi muốn nói dễ dàng .. Và thậm chí tốt hơn bạn có thể đi sâu hơn vào mọi thứ nếu bạn cần. – baash05
hoàn toàn 100% không đồng ý, mọi dự án MFC tôi đã thấy là một mớ hỗn độn đẫm máu. mà không nói điều gì đó với các công cụ, không chỉ là nhà phát triển. –
Bạn quen thuộc với công nghệ nào hơn?
Thông tin bạn đã cung cấp không bao gồm bất kỳ thông tin nào có thể giúp quyết định. Có, các ứng dụng MFC có xu hướng nhỏ hơn (nếu bạn bao gồm kích thước thời gian chạy mà không phải là một biện pháp phù hợp trong thời gian dài), đáp ứng và mor tốn kém hơn để phát triển. Vậy cái gì?
Đầu tiên .. (mặc dù tôi là một coder cứng C++) Tôi phải thừa nhận C# là trong hầu hết các trường hợp hoàn toàn tốt khi tốc độ và kích thước có liên quan. Trong một số trường hợp, ứng dụng nhỏ hơn, bởi vì phần giải nghĩa đã có trên hệ thống đích. (đừng gửi thư rác cho tôi trên đó, một ứng dụng có dll nhỏ hơn, sau đó là ứng dụng tất cả trong một. Windows chỉ xảy ra với "DLL" đã có.)
Để viết mã .. Tôi thành thật không không nghĩ rằng có một sự khác biệt đáng kể. Tôi không dành nhiều thời gian để nhập mã. Hầu hết nó đang nghĩ ra một vấn đề. Phần mã là khá nhỏ. Tiết kiệm một vài dòng ở đây và ở đó .. Blahh nó không phải là một đối số cho tôi .. Nếu nó đã được tôi muốn được làm việc trong APL. Học STL, MFC và những gì có bạn có khả năng chỉ là chuyên sâu như học tập các thư viện C#. Cuối cùng họ đều giống nhau.
C# có một thứ cho nó .. Thị trường. Đó là kỹ năng "nóng" mới nhất và do đó có một thị trường cho nó. Việc tìm kiếm dễ tìm. Bây giờ hãy ghi nhớ java là một kỹ năng "nóng" một vài năm trước và bây giờ bao giờ tom tinh ranh và harry có nó trên sơ yếu lý lịch của họ. Điều đó làm cho nó khó hơn để thích hợp với chính mình.
Ok .. tất cả những gì đã nói .. Tôi yêu C++ .. Không có gì giống như bị bẩn khi tôi thực sự cần. Khi các libs MFC không thực hiện công việc, tôi nhìn vào những gì họ đang ngồi và vân vân .. Đó là một ngôn ngữ vĩnh cửu và tôi tin rằng nó vẫn ở hoặc gần lang được sử dụng nhiều nhất trên thế giới. Yah C++, Yah !.
Ứng dụng loại cửa sổ nào? các hệ điều hành mục tiêu của bạn là gì? Câu trả lời sẽ phụ thuộc rất nhiều vào mục tiêu của bạn. –