managed-c++

Does managed C++ have an equivalent to C#'s lock() and VB's SyncLock? If so, how do I use it? The equivelent to a lock / SyncLock would be to use the Monitor class. In .NET 1-3.5sp, lock(obj) does: Monitor.Enter(obj); try { // Do work } finally { Monitor.Exit(obj); } As of .NET 4, it will be: bool taken = false; try { Monitor.Enter(obj, ref taken); // Do work } finally { if (taken) { Monitor.Exit(obj); } } You could translate this to C++ by doing: System::Object^ obj = gcnew System::Object(); Monitor::Enter(obj); try { // Do work } finally { Monitor::Exit(obj); } C++/CLI does have a 'lock'

What is exactly the difference between the "old" Managed C++ and the "new" C++/CLI? Managed C++ is the version in VS2002 and VS2003. It had race conditions and other serious bugs, as well as being confusing. It's no longer supported. In VS2005, Microsoft introduced C++/CLI, which has also been accepted as an ISO standard. It's also supported in VS2008 and the upcoming VS2010. Both of them had the same goal, which is to create .NET assemblies using the C++ language. The syntax is different (C++/CLI managed code is a lot easier to differentiate from standard C++ at a glance) and C++/CLI also has

I'm having a problem linking a C++ project in VS2008 when using the /clr compile option. I am getting the following build errors: Class1.obj : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (_PROPSHEETPAGEA): (0x0200046f). Class1.obj : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (_PROPSHEETPAGEW): (0x02000473). Class2.obj : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (_PROPSHEETPAGEA): (0x0200046f). Class2.obj :

How would one code the following C# code in Managed C++ void Foo() { using (SqlConnection con = new SqlConnection("connectionStringGoesHere")) { //do stuff } } Clarificaton: For managed objects. Assuming you mean C++/CLI (not the old Managed C++), the following are your options: (1) Mimic a using-Block with using automatic / stackbased objects: { SqlConnection conn(connectionString); } This will call the Destructor of the "conn" Object when the next enclosing block ends. Whether this is the enclosing function, or a block you manually add to limit scope doesn't matter. (2) Explicitly call

In the process of learning P/Invoke, I asked this previous question: How to P/Invoke when pointers are involved However, I don't quite understand the implications of using P/Invoke in C# over creating a wrapper in Managed C++. Creating the same DLL using P/Invoke in C# definately resulted in a cleaner interface since I could use DLLImport on an embedded resource, but would a Managed C++ wrapper for a native DLL, where I do the marshaling myself, have better performance? C++ wrapper should be faster, have a look at this MSDN page : C++ Interop uses the fastest possible method of data marshaling

Our project structure is like, native.dll :- This contains pure native code written in c\c++. This native.dll exposes some functions using *def file. Wrapper Library(wrapper.dll compiled with .Net framework v4.0) :- In order to use functionality of native.dll , a Wrapper lib(wrapper.dll) is written in C++\CLI using :clr\oldsyntax . This wrapper has all code of Interoperability and Marshalling . Application(Console App v4.0) directly uses wrapper.dll to use functionality provided by native.dll . Now this project needs to run in .Net Core . This means we will have an .Net Core application that

We're looking at writing a .Net-callable wrapper for some legacy C++ libraries using managed C++. It all looks pretty easy. Is there anything we need to watch out for? I found it generally quite easy to wrap some existing C++ libraries in C++/CLI and encountered comparatively few pitfalls. The ones I can remember were: Mixing unmanaged C++ code and C++/CLI code in the same executable/DLL is a really bad idea. I've run into problems with competing memory managers at shutdown time that way (basically the .NET runtime and the regular C++ runtime where stepping on each other's toes when it came to

I've got a WPF application on an ultrasound machine that displays ultrasound images generated in C++ at a speed upwards of 30 frames per second. From what I understand, the normal process for displaying images in WPF is to create a BitmapSource for your image and set the Source for your Image, which then causes it to invalidate and display. Since BitmapSources do not implement IDisposable, using this method forced me to create 30 BitmapSources a second. For a 640x480 image with 32bppArgb format, this is around 30MB/sec of memory being allocated a second and then garbage disposed every 10