Tôi biết C # cung cấp cho lập trình viên khả năng truy cập, sử dụng con trỏ trong bối cảnh không an toàn. Nhưng điều này là cần thiết khi nào?
Trong những trường hợp nào, việc sử dụng con trỏ trở nên không thể tránh khỏi?
Nó chỉ vì lý do hiệu suất?
Ngoài ra, tại sao C # lại bộc lộ chức năng này thông qua một ngữ cảnh không an toàn và loại bỏ tất cả các lợi thế được quản lý khỏi nó? Về mặt lý thuyết, liệu có thể có con trỏ sử dụng mà không làm mất bất kỳ lợi thế nào của môi trường được quản lý?
Câu trả lời:
Khi nào điều này là cần thiết? Trong những trường hợp nào thì việc sử dụng con trỏ trở nên không thể tránh khỏi?
Khi chi phí ròng của một giải pháp an toàn được quản lý là không thể chấp nhận được nhưng chi phí ròng của một giải pháp không an toàn lại có thể chấp nhận được. Bạn có thể xác định chi phí ròng hoặc lợi ích ròng bằng cách lấy tổng chi phí trừ đi tổng lợi ích. Những lợi ích của một giải pháp không an toàn là những thứ như "không lãng phí thời gian cho việc kiểm tra thời gian chạy không cần thiết để đảm bảo tính đúng đắn"; chi phí là (1) phải viết mã an toàn ngay cả khi hệ thống an toàn được quản lý bị tắt, và (2) phải đối phó với khả năng làm cho bộ thu gom rác kém hiệu quả hơn, vì nó không thể di chuyển xung quanh bộ nhớ có con trỏ không được quản lý vào nó.
Hoặc, nếu bạn là người viết lớp điều phối.
Nó chỉ vì lý do hiệu suất?
Có vẻ như việc sử dụng con trỏ trong ngôn ngữ được quản lý vì những lý do khác ngoài hiệu suất.
Bạn có thể sử dụng các phương thức trong lớp Marshal để xử lý việc tương tác với mã không được quản lý trong đại đa số các trường hợp. (Có thể có một số trường hợp khó hoặc không thể sử dụng thiết bị điều chỉnh để giải quyết vấn đề liên động, nhưng tôi không biết về bất kỳ trường hợp nào.)
Tất nhiên, như tôi đã nói, nếu bạn là người viết lớp Marshal thì rõ ràng bạn không thể sử dụng lớp Marshal để giải quyết vấn đề của mình. Trong trường hợp đó, bạn cần triển khai nó bằng cách sử dụng con trỏ.
Tại sao C # lại để lộ chức năng này thông qua một bối cảnh không an toàn và loại bỏ tất cả các lợi thế được quản lý khỏi nó?
Những lợi thế được quản lý đó đi kèm với chi phí hiệu suất. Ví dụ: mỗi khi bạn yêu cầu mảng cho phần tử thứ mười của nó, thời gian chạy cần thực hiện kiểm tra xem có phần tử thứ mười hay không và đưa ra một ngoại lệ nếu không có. Với con trỏ rằng chi phí thời gian chạy được loại bỏ.
Cái giá phải trả cho nhà phát triển tương ứng là nếu bạn làm sai thì bạn phải đối phó với lỗi hỏng bộ nhớ định dạng đĩa cứng của bạn và làm hỏng quy trình của bạn một giờ sau đó thay vì xử lý một ngoại lệ sạch đẹp tại điểm xảy ra lỗi.
Có thể sử dụng con trỏ mà không làm mất bất kỳ lợi thế nào của môi trường được quản lý, về mặt lý thuyết?
Theo "ưu điểm", tôi giả sử bạn muốn nói đến các lợi thế như thu gom rác, an toàn kiểu và tính toàn vẹn tham chiếu. Vì vậy, câu hỏi của bạn về cơ bản là "về lý thuyết có thể tắt hệ thống an toàn nhưng vẫn nhận được những lợi ích của hệ thống an toàn đang được bật?" Không, rõ ràng là không. Nếu bạn tắt hệ thống an toàn đó vì bạn không thích nó đắt tiền như thế nào thì bạn sẽ không nhận được những lợi ích của nó!
Con trỏ là một mâu thuẫn cố hữu đối với môi trường được quản lý, thu gom rác thải.
Một khi bạn bắt đầu nhầm lẫn với các con trỏ thô, GC không có manh mối gì đang xảy ra.
Cụ thể, nó không thể cho biết liệu các đối tượng có thể truy cập được hay không, vì nó không biết con trỏ của bạn đang ở đâu.
Nó cũng không thể di chuyển các đối tượng xung quanh trong bộ nhớ, vì điều đó sẽ phá vỡ các con trỏ của bạn.
Tất cả điều này sẽ được giải quyết bởi các con trỏ được GC theo dõi; đó là những gì tài liệu tham khảo.
Bạn chỉ nên sử dụng con trỏ trong các kịch bản tương tác nâng cao lộn xộn hoặc để tối ưu hóa rất phức tạp.
Nếu bạn phải hỏi, có lẽ bạn không nên.
interior_ptr
GC có thể di chuyển các tham chiếu xung quanh; sử dụng không an toàn sẽ giữ một đối tượng nằm ngoài tầm kiểm soát của GC và tránh điều này. "Cố định" ghim một đối tượng, nhưng cho phép GC quản lý bộ nhớ.
Theo định nghĩa, nếu bạn có một con trỏ đến địa chỉ của một đối tượng và GC di chuyển nó, con trỏ của bạn không còn hợp lệ.
Về lý do tại sao bạn cần con trỏ: Lý do chính là làm việc với các tệp DLL không được quản lý, ví dụ như những tệp được viết bằng C ++
Cũng lưu ý, khi bạn ghim các biến và sử dụng con trỏ, bạn dễ bị phân mảnh đống.
Biên tập
Bạn đã đề cập đến vấn đề cốt lõi của mã được quản lý và không được quản lý ... làm thế nào để bộ nhớ được giải phóng?
Bạn có thể trộn mã cho hiệu suất như bạn mô tả, bạn chỉ không thể vượt qua ranh giới được quản lý / không được quản lý với con trỏ (tức là bạn không thể sử dụng con trỏ bên ngoài ngữ cảnh 'không an toàn').
Về cách chúng được làm sạch ... Bạn phải quản lý bộ nhớ của chính mình; các đối tượng mà con trỏ của bạn trỏ đến đã được tạo / cấp phát (thường trong C ++ DLL) bằng cách sử dụng (hy vọng) CoTaskMemAlloc()và bạn phải giải phóng bộ nhớ đó theo cách tương tự, gọi CoTaskMemFree(), nếu không bạn sẽ bị rò rỉ bộ nhớ. Lưu ý rằng chỉ có bộ nhớ được cấp phát với CoTaskMemAlloc()có thể được giải phóng với CoTaskMemFree().
Giải pháp thay thế khác là hiển thị một phương thức từ dll C ++ gốc của bạn lấy một con trỏ và giải phóng nó ... điều này cho phép DLL quyết định cách giải phóng bộ nhớ, hoạt động tốt nhất nếu nó sử dụng một số phương pháp khác để cấp phát bộ nhớ. Hầu hết các hình nền gốc mà bạn làm việc đều là các hình nền của bên thứ ba mà bạn không thể sửa đổi và chúng thường không có (mà tôi đã thấy) các chức năng như vậy để gọi.
Một ví dụ về giải phóng bộ nhớ, được lấy từ đây :
string[] array = new string[2];
array[0] = "hello";
array[1] = "world";
IntPtr ptr = test(array);
string result = Marshal.PtrToStringAuto(ptr);
Marshal.FreeCoTaskMem(ptr);
System.Console.WriteLine(result);
Một số tài liệu đọc thêm:
Bộ nhớ deallocate C # được tham chiếu bởi IntPtr Câu trả lời thứ hai giải thích các phương pháp phân bổ / deallocation khác nhau
Làm thế nào để giải phóng IntPtr trong C #? Củng cố nhu cầu phân bổ theo cùng một cách bộ nhớ đã được cấp phát
http://msdn.microsoft.com/en-us/library/aa366533%28VS.85%29.aspx Tài liệu MSDN chính thức về các cách khác nhau để cấp phát và phân bổ bộ nhớ.
Tóm lại ... bạn cần biết bộ nhớ được cấp phát như thế nào để giải phóng nó.
Chỉnh sửa
Nếu tôi hiểu chính xác câu hỏi của bạn, câu trả lời ngắn gọn là có, bạn có thể chuyển dữ liệu cho các con trỏ không được quản lý, làm việc với nó trong bối cảnh không an toàn và có sẵn dữ liệu khi bạn thoát khỏi ngữ cảnh không an toàn.
Điều quan trọng là bạn phải ghim đối tượng được quản lý mà bạn đang tham chiếu với một fixedkhối. Điều này ngăn không cho bộ nhớ bạn đang tham chiếu bị GC di chuyển khi ở trong unsafekhối. Có một số vấn đề phức tạp ở đây, chẳng hạn như bạn không thể gán lại con trỏ được khởi tạo trong một khối cố định ... bạn nên đọc các câu lệnh không an toàn và cố định nếu bạn thực sự muốn quản lý mã của riêng mình.
Tất cả những gì đã nói, lợi ích của việc quản lý các đối tượng của riêng bạn và sử dụng con trỏ theo cách bạn mô tả có thể không giúp bạn tăng hiệu suất nhiều như bạn nghĩ. Lý do tại sao không:
HTH,
James
GC.AddMemoryPressurevà GC.RemoveMemoryPressure. Bạn sẽ vẫn phải tự giải phóng bộ nhớ, nhưng bằng cách này, trình thu gom rác sẽ tính đến bộ nhớ không được quản lý khi đưa ra quyết định lên lịch.
Những lý do phổ biến nhất để sử dụng con trỏ một cách rõ ràng trong C #:
Lý do tại sao cú pháp liên kết với con trỏ bị xóa khỏi C # (theo hiểu biết và quan điểm của tôi - Jon Skeet sẽ trả lời tốt hơn B-))) hóa ra nó không cần thiết trong hầu hết các tình huống.
Từ quan điểm thiết kế ngôn ngữ, một khi bạn quản lý bộ nhớ bằng bộ thu gom rác, bạn phải đưa ra những hạn chế nghiêm trọng về những gì được và những gì không thể làm với con trỏ. Ví dụ, việc sử dụng một con trỏ để trỏ vào giữa một đối tượng có thể gây ra các vấn đề nghiêm trọng cho GC. Do đó, khi các hạn chế được áp dụng, bạn chỉ có thể bỏ qua cú pháp bổ sung và kết thúc với các tham chiếu "tự động".
Ngoài ra, cách tiếp cận siêu nhân từ được tìm thấy trong C / C ++ là một nguồn lỗi phổ biến. Đối với hầu hết các tình huống, nơi hiệu suất vi mô không quan trọng chút nào, tốt hơn nên đưa ra các quy tắc chặt chẽ hơn và hạn chế nhà phát triển có lợi cho ít lỗi hơn mà rất khó phát hiện ra. Vì vậy, đối với các ứng dụng kinh doanh thông thường, môi trường được gọi là “được quản lý” như .NET và Java phù hợp hơn so với các ngôn ngữ được cho là hoạt động với cỗ máy thô sơ.
obj->Property, obj.Propertythay vào đó sẽ hoạt động. Sẽ làm rõ câu trả lời của tôi.
Giả sử bạn muốn giao tiếp giữa 2 ứng dụng bằng IPC (bộ nhớ dùng chung) thì bạn có thể sắp xếp dữ liệu vào bộ nhớ và chuyển con trỏ dữ liệu này cho ứng dụng khác thông qua tin nhắn cửa sổ hoặc một cái gì đó. Khi nhận ứng dụng, bạn có thể lấy lại dữ liệu.
Cũng hữu ích trong trường hợp chuyển dữ liệu từ .NET sang các ứng dụng VB6 cũ, trong đó bạn sẽ điều chỉnh dữ liệu vào bộ nhớ, chuyển con trỏ tới ứng dụng VB6 bằng cách sử dụng win msging, sử dụng VB6 copymemory () để tìm nạp dữ liệu từ không gian bộ nhớ được quản lý sang bộ nhớ không được quản lý của ứng dụng VB6 không gian..