Talk:C++/CLI

Problematic sentence

The article has a sentence that reads as follows: "The importance of this change becomes crucial when managed and unmanaged code is mixed: where you previously saw a sea of pointers, you can now tell which objects are under garbage collection and which must be destroyed."

How is this possible? Regular C++ allows memory to be garbage-collected. Additionally, regular C++ supports smart pointers which are not manually destroyed. Given, then, that regular pointers may be garbage collected and may not need to be destroyed, I do not believe the sentence accurately describes the usefulness of handles compared to pointers. --Yamla 03:51, 16 January 2006 (UTC)[reply]

"Smart pointers" in regular C++? I think you're talking about references, which are nothing but a somewhat type-safe and cut down version of pointers. If such pointers exist and are really a feature of regular (standard) C++, not just a vendor extension, please enlighten me: I would surely use them!

Smart pointers are now part of TR1. TR1 is standard C++. They are also easy to add to C++ even if your compiler is behind the times. --Yamla 16:53, 16 January 2006 (UTC)[reply]

I don't know to which point is that TR1 incorporated into the C++ standards _and_ current C++ compilers. Do you mean that the only library I actually need to use is the standard C++ library (the one with vector<T>, cout, etc.)? Habbit 19:00, 16 January 2006 (UTC)[reply]

Assuming what I currently know (no such smart pointers) as true, "regular" C++ indeed allows memory to be garbage-collected (through new and delete). And so does C (through malloc and free). However, the new part in C++/CLI is automatic garbage collection: you just create the object with gcnew. When it goes out of scope (when all handles to it are no longer accesible), that object is elegible for automatic destruction that will be performed when memory is needed or System::GC::Collect() is called.

Oh, and, of course, you can do similar things with your own GC system, such as Boehm, but here you don't even have to worry about calling a modified version of new. If you try to create a managed object with new instead of gcnew, you'll receive an error.

Well, you do need gcnew instead of regular new. So wouldn't that be a modified version of new? Obviously, this depends on your point of view. --Yamla 16:53, 16 January 2006 (UTC)[reply]

By "modified version of operator new" i meant an overriden version of global operator new _or_ something that passes through one of the GC classes. If you use your own GC system, you can still create potential memory leaks by using the old (regular) version of operator new, which is impossible in C++/CLI because, as I said above, trying to create a managed object with operator new instead of operator gcnew or vice versa will throw a compile error. I don't know, however, what do keywords like int map to: the system-dependant length C++ int primitive or the 32-bit CLR System::Int32?. Habbit 19:00, 16 January 2006 (UTC)[reply]

Last but not least, that sentence is just comparing C++/CLI with its predecessor, Managed Extensions for C++, where both managed and unmanaged objects used the pointer (*) syntax and were created with operator new (String* a = new String()). In this new version, managed objects use the handle (^) syntax and are created with operator gcnew (String^ a = gcnew String()), while unmanaged objects keep their pointer syntax (CMyUnmanagedClass* a = new CMyUnmanagedClass()), thus making the distinction clearer: you don't have to worry about destroying objects with the handle syntax.

Habbit 16:49, 16 January 2006 (UTC)[reply]

I thought Managed Extensions for C++ also supported regular C++, in which case the sentence is worded somewhat difficultly. Anyway, please give me feedback on what I've written above and then perhaps I'll try suggesting an alternate wording here. --Yamla 16:53, 16 January 2006 (UTC)[reply]

You are partially right: Managed Extensions for C++ (MEC++) were conceived, as the name suggets, as a superset to standard C++ to support CLR. However, C++/CLI can be thought of as a different language whose syntax "happens" to be compatible with that of C++ for unmanaged code, and which output can either target a given machine (unmanaged code) or the .NET VM (managed code). That is, at least, my view... What do you think? Habbit 19:00, 16 January 2006 (UTC)[reply]

Using block

To Habbit: Examples in C# and C++/CLI are not equivalent. Reason: MyClass auto in C++ example "lives" to the end of function. If you want same behaviour in C# example, you should use using block over the entire function. That is the reason I modified using block in past. I found nothing strange about that modification. Can you explain to me what is so strange about that?

Jakiša Tomić 19:33, 5 April 2006 (UTC)[reply]

From that point of view, nothing, I just found strange that you made the using block encompass the other try/finally block. Besides, I added the comments to clarify the scope of the variables: I think the using block is clearer if it does not get mixed with the "user equivalent code" Habbit 23:22, 5 April 2006 (UTC)[reply]