Declaring an instance of something in Managed C++

[SunnyD]

In Managed C++, if you simply declare an instance of an object using:

CObject cobj;

Does this actually implicitly create an instance of CObject on the managed heap? Or can that only be explicitly done using gcnew?

 

[imported_Dhaval00]

Anything not initialized in the CLR world points to nothing on the heap (assuming it is a reference type). Meaning, cobj from that statement is "null".

 

[SunnyD]

Sorry, I should have mentioned "assuming the class definition of CObject was __gc"... ie: CObject is managed.

 

[SunnyD]

Originally posted by: Dhaval00
Anything not initialized in the CLR world points to nothing on the heap (assuming it is a reference type). Meaning, cobj from that statement is "null".

Not true in Visual C++ 2005.

Prior to Microsoft Visual C++ 2005, an instance of a reference type could only be created using the new operator, which created the object on the garbage collected heap. However, beginning in Microsoft Visual C++ 2005, you can create an instance of a reference type using the same syntax that you would use to create an instance of a native type on the stack. So, you do not need to use gcnew) to create an object of a reference type and that when the object goes out of scope, the compiler will call the object's destructor.

It does indeed work, however the results are confusing. For example, I can create an Forms:penFileDialog using the stack semantics, and it works fine. However, if I try to create a System::String using stack semantics, it complains about not having a top level ^.

Of course I could just read:

The following reference types are not available for use with stack semantics:

delegate

array (Visual C++)

String

 

[imported_Dhaval00]

Well, I am not sure about the semantics in C++, but my initial reply was based on my understanding of the CLR. My guess is any other "semantic" add-ons would probably be Microsoft specific. Moreover, the IL generated after compiling that code will be identical to the IL generated in any other .NET language. Were you able to find out if any object declared using stack semantics actually goes on the stack, even though it is a reference type (if it goes on the stack, it would be a value type then... LOL)?

Nevertheless, this is useful knowledge

 

[SunnyD]

Originally posted by: Dhaval00
Well, I am not sure about the semantics in C++, but my initial reply was based on my understanding of the CLR. My guess is any other "semantic" add-ons would probably be Microsoft specific. Moreover, the IL generated after compiling that code will be identical to the IL generated in any other .NET language. Were you able to find out if any object declared using stack semantics actually goes on the stack, even though it is a reference type (if it goes on the stack, it would be a value type then... LOL)?

Nevertheless, this is useful knowledge

Per the MSDN article...

When you create an instance of a reference type using stack semantics, the compiler does internally create the instance on the garbage collected heap (using gcnew).

In essence, it's the same as explicitly declaring with gcnew, though you use the . operator to access members. Also, the reference tracking operator % basically makes it the same as a standard style C reference. But I agree, I think it's probably more confusing AND Microsoft specific. Though .Net "is" Microsoft "specific" so to speak.

 

[imported_Dhaval00]

Though .Net "is" Microsoft "specific" so to speak.

The Framework is. Not the stack on which it sits - the CLR is a standard. There's .NET and then there is MONO

 

[SunnyD]

Originally posted by: Dhaval00

Though .Net "is" Microsoft "specific" so to speak.

The Framework is. Not the stack on which it sits - the CLR is a standard. There's .NET and then there is MONO

Of course - my terminology stinks. But look at all Microsoft dev tools. Almost all of them have non-standard Microsoft-specific things in them.

 

[imported_Dhaval00]

Sure, most of them do. But then it is hard to integrate such huge projects - think about all the work that goes in integrating tools like Integration Services, Reporting Services, Analysis Services, SQL Server, etc. into a single environment (all of these are separate teams within Microsoft). I actually think that most of the newer teams at M$ have done a terrific job, and kudos to them for integrating these tools in the best way they can.

I use Integration Services, SourceSafe, Reporting Services, Analysis Services, and C#. I am able to do 90% of coding from within Visual Studio, including debugging. Think of these things in realistic terms... can your company achieve this level of integration (assuming you have such huge teams)? I know mine can't