Tôi nghe ở đâu đó rằng Microsoft sẽ tập trung nỗ lực của họ vào C# thay vì C++ cho nền tảng .NET. Tôi có thể thấy các dấu hiệu của điều này là đúng bởi vì các nhà thiết kế GUI đã có sẵn cho C# nhưng không phải là C++.C++ .NET có chết không?
Vì vậy, tôi muốn biết liệu C++ trong .NET có đang chết hay không và liệu nó có tiếp tục đứng thứ hai sau C# trong tương lai hay không.
Nếu bạn đang nhắm mục tiêu Khuôn khổ .NET trong phát triển ứng dụng thì có C++/CLI là công dân hạng hai so với C#. C# được thiết kế đặc biệt là ngôn ngữ cho .NET framework trong khi phần mở rộng C++/CLI có sẵn để cho phép các nhà phát triển kết nối mã nguồn gốc và được quản lý.
Tuy nhiên, đừng nhầm lẫn giữa C++ với C++/CLI (C++ .NET là điều tương tự ...). C++ vẫn hoạt động tốt trong các lĩnh vực như hạt nhân, trò chơi, ứng dụng hiệu suất cao và ứng dụng máy chủ (ví dụ: máy chủ SQL), tất cả các ứng dụng này đều không thay đổi. Mặt khác, hầu hết các công cụ GUI '.NET' sẽ không sử dụng C++.
Tôi không biết bạn có thể truy cập vào khung công tác với native C++ (đó là lý do tại sao bạn nói nó giống với C++ .NET?). – Unknown
Anh ấy nói "C++ CLR" giống với "C++ .NET" – sharkin
Bạn cần cung cấp cờ/clr cho trình biên dịch C++ nếu bạn muốn sử dụng mã được quản lý và mã gốc trong cùng một assembly. Về cơ bản, thêm cờ này làm cho trình biên dịch thêm siêu dữ liệu .NET framework vào assembly. Bạn cũng có thể sử dụng/clr: safe và/clr: các cờ thuần túy để tạo các assembly .NET chỉ có MSIL, trong đó trường hợp C# và C++ là bằng ở đây (ditto cho VB.NET, J #, v.v.). – Serguei
Quản lý C++ không bao giờ thực sự trở thành những gì MS nghĩ. C# có thể làm (gần) cùng một điều, với cú pháp trực quan và thân thiện hơn rất nhiều. Ngoài ra, C++/CLI sẽ không được hỗ trợ trong một thời gian dài vì đây là cách dễ dàng để tạo ra sự tương tác giữa các hội đồng .NET và các phiên bản C++. Đó là về tất cả nó được sử dụng cho dù (tôi chắc chắn có 0,001% của C + +/CLI phát triển ra có những người không đồng ý: P).
Vì vậy, bạn có nói rằng bạn không thể thực hiện interop giữa C# và native C++? Tôi nghĩ rằng p/gọi điều là hoàn toàn có thể sử dụng trong C# – Unknown
@ Không biết anh ta không nói rằng bạn không thể, anh ấy nói "C + +/CLI là cách dễ dàng". Tôi không biết nếu tôi đồng ý, mặc dù, vì không có gì trong C + +/CLI trông dễ dàng với tôi. –
C++/CLI cực kỳ dễ dàng ... ít nhất, so với việc viết lại các tiêu đề SDK từ đầu cần thiết để sử dụng P/Invoke. – Shog9
C++/CLI chỉ là cách Microsoft thu hút các nhà phát triển bản địa C++ thành .NET. Nó giống như một lớp trung gian giữa native C++ và C#, nhưng tôi khá chắc chắn rằng các nhà phát triển thích chọn một trong hai native C++ hoặc C#.
Microsoft sẽ không để C++/CLI chết, ít nhất là trong tương lai gần, tuy nhiên, không có hỗ trợ cộng đồng, C++/CLI sẽ không thể phát triển.
Trong thế hệ này, không phát triển có nghĩa là gần chết.
Mặt khác, có vẻ với tôi như thế giới lập trình đã trưởng thành rất nhiều, và tôi không mong đợi một sự tăng trưởng toàn bộ trong thập kỷ tới. Không có lý do tại sao một công nghệ đáng kể không thể tồn tại trong một thời gian dài trên một cơ sở người dùng tương đối liên tục. –
Tôi e là vậy.
Lý do cho việc này không phải là C# (không mang bất cứ điều gì đặc biệt và mặc dù đó là một ngôn ngữ mới, nó không dẫn đến các tính năng ngôn ngữ mới nhưng chỉ đơn thuần là các tính năng của người khác).
Đó chủ yếu là do nỗ lực đầu tiên của MS để bật C++ cho nền tảng .NET - Quản lý C++ - là một thảm họa.
Sau này họ thuê Herb Sutter, C++ guru, tạo nên công việc tuyệt vời khi thiết kế thay thế Managed C++ callled C++/CLI. Tại sao và bao nhiêu thiết kế C++/CLI vượt trội so với thiết kế Managed C++, bạn có thể tìm hiểu bằng cách đọc A Design Rationale for C++/CLI được viết bởi Herb.
Nhân tiện, Herb đã thực hiện trình biên dịch vc một trong những trình biên dịch tuân thủ tiêu chuẩn tốt nhất cho Windows sau nhiều năm, đây là trình biên dịch tồi tệ nhất đối với sự phù hợp tiêu chuẩn.
Tôi cho rằng Tiện ích được quản lý khá tốt, tốt hơn C++/CLI. Thật không may, nó đã thêm phần mở rộng vui nhộn và mọi người không thích điều đó, vì vậy họ đặt các phần mở rộng khác nhau (thở dài) và phá vỡ khả năng tiêu thụ tài nguyên được quản lý "nguyên bản" (nghĩa là trên vùng gốc mà không đặt^ở khắp mọi nơi). Herb tốt, nhưng tôi không nghĩ anh ấy đã làm tốt như vậy với C++/CLI. – gbjbaanb
Bạn đã đọc "Lý do thiết kế cho C++/CLI" chưa? Từ những gì bạn đang nói tôi đoán bạn đã không ... –
Er, gbjbaanb, nếu tôi không nhầm, tài nguyên được quản lý chưa bao giờ có trên vùng heap gốc. Toán tử^được thêm vào để tạo ra một sự phân biệt giữa các đối tượng được quản lý và không được quản lý, bởi vì trước đây, các đối tượng được quản lý vẫn nằm trên vùng được quản lý, nhưng không có cú pháp để chỉ ra điều đó. –
Tôi không nghĩ rằng nó nhất thiết phải biến mất, nhưng lý do để sử dụng nó hầu như luôn luôn đi xuống cho dù bạn có cần các lợi ích hiệu suất đi kèm với nó hay không. Nếu C# có thể làm điều tương tự ở 90% hiệu quả của C++, thì điều đó có thực sự đủ tốt không?
No. Nó được sinh ra đã chết.Nó luôn luôn được coi là một citezen hạng hai không có lộ trình sức sống.
Thuê chính trong cuộc sống, nhờ C++/CX có cú pháp * rất * tương tự. Họ thậm chí còn thêm hỗ trợ IntelliSense trở lại. –