Is there a C#'s unsafe equivalent in C++/CLI?

Question

I am trying to port C++/CLI code into Verifiable Type-Safe C++/CLI code (Use clr:safe flag) so I can get a AnyCPU assembly. The main compilation problem I find is that, I get a lot of C4956 errors and I think, that might be solved by explicitly tell the compiler I expect this to be unsafe. Suggestions?

I dind't work wit C++\CLI, but the language itself is not managed unless you use __gc dirrective, if I'm not mistake. — Tigran, Jul 22 '11 at 15:31
@BoldClock: I assume he means /clr:pure - See http://msdn.microsoft.com/en-us/library/85344whh.aspx — shf301, Jul 22 '11 at 15:42
Sorry for the confusion, I updated a bit my question. @shf301: I actually meant /clr:safe so it will yield a MSIL-only assembly. — Anzurio, Jul 22 '11 at 15:53
Just to clarify, I think you mean **Warning**, not Error [C4956](http://msdn.microsoft.com/en-us/library/xswzdb8c(VS.80).aspx). — Gustavo Mori, Jul 22 '11 at 20:11
@Gustavo: From that page: "This warning is issued as an error" — Ben Voigt, Jul 22 '11 at 21:19

score 2 · Answer 1 · answered Jul 22 '11 at 15:34

2

You shouldn't have many problems porting unsafe code from C# to CLI, just be sure to use IntPtr which is a CLS-compliant architecture agnostic pointer.

If you run into specific problems or if you're unsure about something, update the question with more details.

answered Jul 22 '11 at 15:34

Brandon Moretz

7,512
3
33
43

Of course, you should be using `IntPtr` in C# already, so I'm not really sure where the change is. – Cody Gray - on strike Jul 22 '11 at 15:56
@Cody I realize that, that's why the general answer was "you shouldn't have any problems due to the limitations on unsafe code blocks" assuming he's using IntPtr, instead of something like "int a = 4; ( *( int * )&a ) = 1;"... It's stating the obvious, but It's a pretty vague question. – Brandon Moretz Jul 22 '11 at 16:07
Wasn't a criticism; it just looked like you were implying that `IntPtr` wouldn't be used in C#. I agree that there should be virtually no problems porting code. – Cody Gray - on strike Jul 22 '11 at 16:09

score 2 · Answer 2 · answered Jul 22 '11 at 15:42

2

C++/CLI can be freely mixed with C++ code and is inherently unsafe, so there's no equivalent needed except the language itself. Use pin_ptr to pin down garbage collected objects and buffers and you now have a C++ style pointer to use. You can also use C++ STL, unsafe casts, etc. on such pointers.

answered Jul 22 '11 at 15:42

Ed Bayiates

11,060
4
43
62

He's using the `/clr:safe` compiler option, which prevents using most of those features. – Ben Voigt Jul 22 '11 at 20:08
He added that after my answer. Anyway he can work around that with #pragma. – Ed Bayiates Jul 22 '11 at 20:35

score 2 · Accepted Answer · answered Jul 22 '11 at 20:07

2

This has been covered here

Basically, this is what /clr:pure was supposed to provide, because it also generates a pure MSIL assembly. Unfortunately it still causes a dependency on a particular bitness, so isn't compatible with AnyCPU.

answered Jul 22 '11 at 20:07

Ben Voigt

277,958
43
419
720

Actually, there's nothing about the code that makes the MSIL incompatible (unless you invoke interop); it's the various libraries (MFC, ATL, CRT) that cause the problem. If you are willing to go without those (and interop), you can have a C++/CLI AnyCPU /clr:pure module no problem. See http://stackoverflow.com/a/9004833/147511 – Glenn Slayden Jan 27 '12 at 08:42
@GlennSlayden: As you mentioned in your answer, the compiler and linker still generate an assembly with locked bitness. There's no way to make the compiler generate an unsafe AnyCPU assembly, you need an external tool like `corflags`. – Ben Voigt Jan 27 '12 at 15:18

score 1 · Answer 4 · answered Jul 22 '11 at 16:44

For your reference on answering this question we have:

/clr:safe Creates an MSIL-only verifiable assembly. You can’t have native types in your code, and if you try to use them, the compiler will throw an error. This compilation mode produces assemblies that are equivalent to what C# (regular mode) and VB.NET would produce.

In order to work with type-safe code you need to use handles (using gcnew) instead of pointers (using new)

Also, safe_cast operator is new to C++/CLI and replaces __try_cast in the old syntax. safe_cast is guaranteed to produce verifiable MSIL. You can use safe_cast wherever you would typically use dynamic_cast, reinterpret_cast, or static_cast. At runtime, safe_cast checks to see if the cast is valid

You should grab a copy of: C++/CLI in Action by Nishant Sivakumar Very nice reference of C++/CLI

`safe_cast` is only a replacement for `static_cast`, definitely not for `dynamic_cast`. — ildjarn, Jul 22 '11 at 19:40

Is there a C#'s unsafe equivalent in C++/CLI?

4 Answers4

Linked