Deterministic Destruction in C++/CLI

Introduction

Many C++ programmers were rather unhappy with the non-deterministic finalization feature they were provided with by the .NET Garbage Collection algorithm. C++ programmers were so much used to the RAII (Resource Acquisition Is Initialization) idiom where they expected a destructor to get called when an object went out of scope or when delete was explicitly called on it, that a non-deterministic destructor simply didn't fit their expectations or requirements. Microsoft alternatively offered the Dispose pattern where classes had to implement IDisposable and then call Dispose on their objects when they went out of scope. The basic issue here was that this required the programmer to manually and consistently call Dispose whenever the object needed to be finalized and it became worse when the object had managed member objects that themselves would need to have Dispose called on them, which then meant they too needed to implement IDisposable. Tiresome sounding, isn't it?

Guess what? In C++/CLI, the Microsoft VC++ team is giving us a destructor that internally gets compiled to the Dispose method and the old finalizer gets an alternate syntax, so we basically have finalizers and destructors as two separate entities that behave differently as they should have in the previous version. The designers of C# made the unfortunate initial mistake of calling their finalizer a destructor and I presume there must be tens of thousands of C# coders out there who have no inkling of the fact that they have got a basic concept in object life-time maintenance absolutely confused with the wrong thing.

Note

It's easy to wrongly call automatic objects as stack objects in C++/CLI, but it should be remembered that the seemingly stack based objects actually reside on the CLR heap, as they are still normal garbage collected ref objects. It's a C++ compiler trick that allow us to treat these variables just as we used to treat stack based objects in unmanaged C++ during the good old days.

The new syntax

In C++/CLI, destructors follow the same syntax used in the pre-managed times, where ~classname would be the method name for the destructor. It also brings out a new naming syntax, !classname which is the method name for the finalizer. Here is what a typical class would look like :-

ref class R1
{
public:
    R1()
    {
        Show("R1::ctor");
    }
    ~R1()
    {
        Show("R1::dtor");
    }
protected:
    !R1()
    {
        Show("R1::fnzr");
    }    
};

The destructor (~R1) gets compiled into a Dispose method in the generated IL.

.method public newslot virtual 
        final instance void 
        Dispose() cil managed
{
  .override [mscorlib]System.IDisposable::Dispose
  // Code size       17 (0x11)

  .maxstack  1
  IL_0000:  ldstr      "R1::dtor"
  IL_0005:  call       void [mscorlib]
        System.Console::WriteLine(string)
  IL_000a:  ldarg.0
  IL_000b:  call       void [mscorlib]
        System.GC::SuppressFinalize(object)
  IL_0010:  ret
} // end of method R1::Dispose

The C# equivalent of the above would be :-

public void Dispose()//IDisposable::Dispose

{
      Console.WriteLine("R1::dtor");
      GC.SuppressFinalize(this);
}
 

There is a call made to GC::SuppressFinalize in the generated Dispose method. This is done to ensure that the finalizer does not get called during the garbage collection cycle that claims this object's memory. If that sounds confusing, remember that we are still restricted by the environment which we are targeting, which happens to be the CLR. In the CLR, reference objects are allocated on the CLR heap and their memory is reclaimed when they are out of use by the Garbage Collector, there is no way the programmer can free up the memory on his/her own. So, even if our destructor gets called, the memory will be released only during the next GC cycle and at that point we don't want the GC trying to call Finalize on our object. GC::SuppressFinalize basically removes the object from the finalization queue.

How it's implemented

void _tmain()
{   
    R1 r;
}

I've declared r as an automatic variable. Now let's see the IL that gets generated for this :-

.method public static int32  
        main() cil managed
{
  .vtentry 1 : 1
  // Code size       16 (0x10)

  .maxstack  1
  .locals (class R1 V_0)
  IL_0000:  ldnull
  IL_0001:  stloc.0
  IL_0002:  newobj     instance void R1::.ctor()
  IL_0007:  stloc.0
  IL_0008:  ldloc.0
  IL_0009:  call       instance void R1::Dispose()
  IL_000e:  ldc.i4.0
  IL_000f:  ret
} // end of method 'Global Functions'::main

The C# equivalent for that would be :-

public static int main()
{
      R1 r = null;
      r = new R1();
      r.Dispose();
      return 0;
}

Pretty straightforward stuff as you can see with Dispose being called when the object goes out of scope. You might be a little surprised that there is no try-catch block in there, but that's because our code fragment was too simple. try-catch blocks are used only if they are required, in the above case, it's not so. Let's see the following code snippet :-

void _tmain()
{   
    R1 r;
    int y=100;
}

The IL generated :-

.method public static int32 
        main() cil managed
{
  .vtentry 1 : 1
  // Code size       28 (0x1c)

  .maxstack  1
  .locals (class R1 V_0,
           int32 V_1)
  IL_0000:  ldnull
  IL_0001:  stloc.0
  IL_0002:  newobj     instance void R1::.ctor()
  IL_0007:  stloc.0
  .try
  {
    IL_0008:  ldc.i4.s   100
    IL_000a:  stloc.1
    IL_000b:  leave.s    IL_0014
  }  // end .try

  fault
  {
    IL_000d:  ldloc.0
    IL_000e:  call       instance void R1::Dispose()
    IL_0013:  endfinally
  }  // end handler

  IL_0014:  ldloc.0
  IL_0015:  call       instance void R1::Dispose()
  IL_001a:  ldc.i4.0
  IL_001b:  ret
} // end of method 'Global Functions'::main

The moment the compiler realizes that there is a probable contingency where control might not reach the line that calls Dispose, it implements a try block and in case of any exception, calls Dispose within the fault handler. The C# equivalent would be :-

public static int main()
{
      R1 r = null;      
      int y;
      r = new R1();
      try
      {
            y = 100;
      }
      catch
      {
            r.Dispose();
      }
      r.Dispose();
      return 0;
}

You could also declare the object as a handle object and then manually call delete on it which equates to calling Dispose on your object.

void _tmain()
{      
   R1^ r = gcnew R1();   
   delete r;   
}

The generated IL is a little more complex for this case (I am not fully sure why an unnecessary int variable is introduced for instance.)

.method public static int32  
        main() cil managed
{
  .vtentry 1 : 1
  // Code size       27 (0x1b)

  .maxstack  1
  .locals (class [mscorlib]System.IDisposable V_0,
           class R1 V_1,
           int32 V_2)
  IL_0000:  ldnull
  IL_0001:  stloc.1
  IL_0002:  newobj     instance void R1::.ctor()
  IL_0007:  stloc.1
  IL_0008:  ldloc.1
  IL_0009:  stloc.0
  IL_000a:  ldloc.0
  IL_000b:  brfalse.s  IL_0017
  IL_000d:  ldloc.0
  IL_000e:  callvirt   
    instance void [mscorlib]System.IDisposable::Dispose()
  IL_0013:  ldnull
  IL_0014:  stloc.2
  IL_0015:  br.s       IL_0019
  IL_0017:  ldnull
  IL_0018:  stloc.2
  IL_0019:  ldc.i4.0
  IL_001a:  ret
} // end of method 'Global Functions'::main

As I mentioned, I am truly puzzled by the V_2 int32 variable. Here is the C# equivalent for those of you who don't like looking at IL.

public static int main()
{
      int v2;
      R1 r = null;
      r = new R1();
      IDisposable d = r;
      if (disposable1 != null)
      {
            d.Dispose();
            v2  = 0;
      }
      else
      {
            v2 = 0;
      }
      return 0;
}

My best guess is that this is to help the CLR Execution Engine do run-time optimizations; in the above case, the entire if loop might possibly be skipped if r is not null.

How member objects are handled

See the following code snippet :-

#define Show(x) Console::WriteLine(x)

ref class R1
{
public:
   R1()
   {
      Show("R1::ctor");
   }
   ~R1()
   {
      Show("R1::dtor");
   }
protected:
   !R1()
   {
      Show("R1::fnzr");
   }   
};

ref class R
{
public:
   R()
   {
      Show("R::ctor");
   }
   ~R()
   {
      Show("R::dtor");
   }
   R1 r;
protected:
   !R()
   {
      Show("R::fnzr");
   }   
};

Let's take a look at R's constructor in the generated IL :-

.method public specialname rtspecialname 
        instance void  .ctor() cil managed
{
  // Code size       28 (0x1c)

  .maxstack  2
  IL_0000:  ldarg.0
  IL_0001:  call       instance void [mscorlib]System.Object::.ctor()
  IL_0006:  ldarg.0
  IL_0007:  newobj     instance void R1::.ctor()
  IL_000c:  stfld      class R1 modopt(
      [Microsoft.VisualC]Microsoft.VisualC.IsByValueModifier) R::r
  IL_0011:  ldstr      "R::ctor"
  IL_0016:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_001b:  ret
} // end of method R::.ctor

Equivalent C# code would be :-

public R()
{
      this.r = ((R1 modopt(Microsoft.VisualC.IsByValueModifier)) new R1());
      Console.WriteLine("R::ctor");
} 

The compiler inserts a custom modopt modifier into the instantiation of the R1 object which would give the JIT compiler some idea of how to treat it. In this case, it has marked it with Microsoft.VisualC.IsByValueModifier which presumably means that this object is to be treated as a pass-by-value object. Anyway, that's beyond the scope of this article and what I wanted to put forth here is that the R object's constructor also instantiates and constructs the R1 member object.

Now let's see the R class destructor :-

.method public newslot virtual final instance void 
        Dispose() cil managed
{
  .override [mscorlib]System.IDisposable::Dispose
  // Code size       42 (0x2a)

  .maxstack  1
  .try
  {
    IL_0000:  ldstr      "R::dtor"
    IL_0005:  call       void [mscorlib]System.Console::WriteLine(string)
    IL_000a:  leave.s    IL_0018
  }  // end .try

  fault
  {
    IL_000c:  ldarg.0
    IL_000d:  ldfld      class R1 modopt(
       [Microsoft.VisualC]Microsoft.VisualC.IsByValueModifier) R::r
    IL_0012:  call       instance void R1::Dispose()
    IL_0017:  endfinally
  }  // end handler

  IL_0018:  ldarg.0
  IL_0019:  ldfld      class R1 modopt(
       [Microsoft.VisualC]Microsoft.VisualC.IsByValueModifier) R::r
  IL_001e:  call       instance void R1::Dispose()
  IL_0023:  ldarg.0
  IL_0024:  call       void [mscorlib]System.GC::SuppressFinalize(object)
  IL_0029:  ret
} // end of method R::Dispose

Equivalent C# code is :-

public void Dispose()
{
      try
      {
            Console.WriteLine("R::dtor");
      }
      catch
      {
            this.r.Dispose();
      }
      this.r.Dispose();
      GC.SuppressFinalize(this);
}
 

As you can see, Dispose is called on the member object as well. The compiler sure does generate a lot of code for us, eh?

In the above discussed case, the member object was also an automatic variable. But what if we had a handle variable as a member? In that case, we should manually delete the member variable in our destructor, otherwise there won't be so much benefit out of the deterministic destruction if the member objects will then have to wait for an unpredictable GC cycle before they get disposed. So, this is what we need to do for such cases :-

ref class R
{
public:
    R()
    {
        r = gcnew R1();
        Show("R::ctor");
    }
    ~R()
    {
        delete r;
        Show("R::dtor");
    }
    R1^ r;
protected:
    !R()
    {
        Show("R::fnzr");
    }    
};

Warning

Do not delete member objects manually from your finalizer, because there is every chance that by the time the finalizer is called on your object, its member objects might already have been finalized.

Performance boost

By using destructors whenever possible instead of finalizers, you would see a small-to-medium performance boost in your code. Problem with finalizers it that, the GC promotes objects that need to be finalized to at least Generation 2, and then the finalizer thread will have to run the Finalize method on objects that need finalizatioon, and then the GC has to reclaim the memory in a future cycle.

Points to remember when using destructors

• You cannot have a method named Dispose in your class, for obvious reasons
• ~classname is the destructor and !classname is the finalizer
• Destructors get called when the object goes out of scope, but the memory won't be freed up until the next GC cycle
• The destructor and finalizer won't get called for the same object
• For automatic member variables you don't need to do anything special
• For handle member variables, make sure to delete them manually in the destructor

Conclusion

Essentially the C++/CLI deterministic destructor implementation is internally a syntactically pleasant form of the Dispose-Pattern and the compiler generates just about all the code that we require. I believe C# 2.0 has a slightly inferior form where they use the using-keyword. The big plus about the C++/CLI destructor syntax is that it fits in naturally to what a native C++ programmer expects his/her destructor to do, and he/she needn't even be aware of the Dispose pattern that's being used internally. Thanks to Herb Sutter and his team :-)

You must Sign In to use this message board.

FAQ    Noise Tolerance Very HighHighMediumLowVery Low   Layout Expand Posts & RepliesThread ViewNo JavascriptNo JS + Preview   Per page 102550

Msgs 1 to 24 of 24 (Total in Forum: 24) (Refresh) FirstPrevNext

On why the int variable is declared in MSIL Renjith mohan 1:23 2 Nov '07   Is this because you have a return 0 at the end of main. I wrote the simplest program of all times int main () { return 0; } and the MSIL read .method assembly static int32 main(string[] args) cil managed { // Code size 6 (0x6) .maxstack 1 .locals ([0] int32 V_0) IL_0000: ldc.i4.0 IL_0001: stloc.0 IL_0002: ldc.i4.0 IL_0003: stloc.0 IL_0004: ldloc.0 IL_0005: ret } // end of method 'Global Functions'::main notice the .locals variable. Sign In·View Thread·PermaLink Slight errors in "C# equivalent" code rb126 1:53 2 May '06   Hi, Thanks for the article. There a few obvious errors in your translated pseudocode, however. For example, in your fifth code snippet: public static int main() { R1 r = null; int y; r = new R1(); try { y = 100; } catch { r.Dispose(); } r.Dispose(); return 0; } if an exception is thrown, Dispose() is clearly being called twice. This isn't what the IL says, however. The endfinally opcode doesn't return control to the program like the leave.s opcode does, so code after the fault block is not executed. A better translation would be something like: public static int main() { R1 r; int y; r = null; r = new R1(); try { y = 100; } finally { r.Dispose(); } return 0; } even though the control flow in the IL is slightly more complex than this with the repetition of the call to Dispose(). This translation is also more faithful because neither the original code nor the IL catch the exception, and your translation using a catch statement implies the exception is caught. There's a similar error in a listing further down the page, too. Sign In·View Thread·PermaLink Question of the structure on C++/CLI Antti Keskinen 12:05 21 Aug '04   Hello there ! I know what I am going to ask may sound like a very basic question to you, but perhaps you might know. I tried running through the C++/CLI specification, but couldn't find a clear answer. The execution of a standard C++ program starts from main. The execution of a Windows program starts from WinMain. On both occasions, the linker will include a certain, specific library (libraries) from which the starting point function is called. I have seen myself that the execution of a C++/CLI console application starts from _tmain or main as well (#typedef in Visual C++ 2005 Express). But, if I had a Windows application that used the CLR objects, where would it's execution begin ? The wizards (Windows Forms application) create application skeletons that start their execution from Mainthis entry-point ? Can you create a normal Win32-application that starts from WinMain, and link it with the CLR to enable the use of .Net Framework ? So, how does it all work ? (tm) -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible. Sign In·View Thread·PermaLink Re: Question of the structure on C++/CLI Nishant S 7:51 22 Aug '04   Hi Antti MSIL supports global methods that are part of a module. The C++ main() function gets compiled to public static int32 main() cil managed in the generated MSIL and it is marked using the .entrypoint IL directive. The latest version of the alpha I have will not link to the CRT library statically, only dynamic linking is supported. My best guess is that the CRT library would be loaded prior to execution starting from the entrypoint function. Regards Nish My blog on C++/CLI, MFC/Win32, .NET - void Nish(char* szBlog); My MVP tips, tricks and essays web site - www.voidnish.com Sign In·View Thread·PermaLink Re: Question of the structure on C++/CLI Antti Keskinen 7:21 23 Aug '04   Hello ! Thanks for this informative piece. The actual problem I was facing was a bit different. You see, I created an empty project in Visual C++ 2005 Express. Then I made it target the Windows subsystem, wrote WinMain and called the .Net Framework from inside this function. The application, upon returning, caused System.ExecutionEngineException. I was at a complete loss, until I discovered that the Visual C++ 2005 Express doesn't install Platform SDK files when it's installed. So, all the Windows headers and libraries required were missing. After I manually altered the directories to point to my "old" Visual Studio .Net 2003 directories and added the required definitions and includes to use the Platform SDK, then it started working properly. I believe the reason was that my first WinMain function didn't have the HINSTANCE parameters at all.. So, problem solved. Thanks for your help and ideas. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible. Sign In·View Thread·PermaLink Basic Question Jörgen Sigvardsson 1:30 18 Aug '04   Suppose I have an object on which Dispose() have been called. Is it an error to call any method on that object after the call to Dispose()? -- Denn du bist, was du isst! Und ihr wisst, was es ist! Es ist mein Teil...? Sign In·View Thread·PermaLink Re: Basic Question Nishant S 1:51 18 Aug '04   Jörgen Sigvardsson wrote: Suppose I have an object on which Dispose() have been called. Is it an error to call any method on that object after the call to Dispose()? C++ won't let you call Dispose directly, since it won't let you have a Dispose method in your class. Dispose is called when the object goes out of scope, after which obviously you cannot access the object. But consider this situation :- R^ r1 = nullptr; { R r; r1 = %r; //Dispose gets called on r } //Now using r1 will have unexpected results But then this is a programmer error. Since object r goes out of scope, Dispose is called, but since r1 still references object r, the object won't be GC'd during the next GC cycle. Now we have a situation where we have an object r1 that references a valid object on the CLI heap whose Dispose method has been called. Pretty ugly situation eh? My blog on C++/CLI, MFC/Win32, .NET - void Nish(char* szBlog); My MVP tips, tricks and essays web site - www.voidnish.com Sign In·View Thread·PermaLink 5.00/5 (2 votes) When would you use a finalizer? Don Clugston 15:11 17 Aug '04   Pardon my ignorance, but I can't understand what you would use finalizers for once you have proper destructors. In standard C++, I've personally never used destructors for anything other than RAII. I thought that finalizers were a poor man's destructors. Since you mention that performance should be better with destructors than with finalizers, I'm baffled as to why finalizers need to exist at all. Have I missed something? Sign In·View Thread·PermaLink Re: When would you use a finalizer? Nishant S 18:13 17 Aug '04   Don Clugston wrote: I'm baffled as to why finalizers need to exist at all. Hello Don, Imagine that you are distributing a C++/CLI library where a method returns a ref object. Now assume that a C# written app uses this method. Obviously the C# app has no means to call delete on the ref object, so it'd be a pretty good thing to have some finish-up stuff in the finalizer. Or imagine a class with a member ref object. Now assume that an instance of the class is shallow-copied, which now means more than one instance of the class references the same member ref object. Now we don't want any one of these instances to delete the member object since this would mean other instances referencing the same object would break. In such a situation you'd be best to leave it to the GC to clean up the object - again, the finalizer comes into play. [of course, you could do some kind of reference counting and stuff on your own, but that'd be extra work which might not be worth the time for your specific purpose] Okay, that's just two situations I thought up, there must be other similarly valid situations where a finalizer is actually useful Nish My blog on C++/CLI, MFC/Win32, .NET - void Nish(char* szBlog); My MVP tips, tricks and essays web site - www.voidnish.com Sign In·View Thread·PermaLink 5.00/5 (1 vote) Re: When would you use a finalizer? Don Clugston 22:17 17 Aug '04   Thanks Nish. Both your scenarios make sense, but they're a bit disturbing. > Obviously the C# app has no means to call delete on the ref object, so it'd be a pretty good thing to have some finish-up stuff in the finalizer. I assume then that they're not going to add destructors to C# ? It could be a bit nasty if destructors and finalizers have different behaviours (eg, if your destructor releases a resource but the finalizer forgets to..) I can see some very nasty bugs in there. (I suspect that Microsoft will have trouble adding new features to any of the CLI languages without causing problems for the others). The second scenario is interesting. I think that if a scarce resource is involved, you probably want a destructor and reference counting smart pointer or similar, but if you're only using memory, a garbage collector is the best solution (and in this case, a finalizer is not required). I can only see finalisers being useful when a resource is limited but relatively plentiful, and you must clean up "eventually". But I still have trouble imagining resources that behave like that. -Don. Sign In·View Thread·PermaLink Re: When would you use a finalizer? Nishant S 23:28 17 Aug '04   Don Clugston wrote: I assume then that they're not going to add destructors to C# ? It could be a bit nasty if destructors and finalizers have different behaviours (eg, if your destructor releases a resource but the finalizer forgets to..) I can see some very nasty bugs in there. (I suspect that Microsoft will have trouble adding new features to any of the CLI languages without causing problems for the others). Hey Don, I just googled on what the C# 2.0 using keyword does and apparently, the using keyword ends up calling Dispose on the object at the end of the using-block. Of course this only works for objects that have a IDisposable::Dispose method. But C# is not the only CLI language out there. So, there are going to be CLI languages that would have to depend on finalization for object-cleanup. So, it's essentially upto the developer to design his finalizer properly. He needs to make sure that all native resources needs to be freed in the finalizer, whereas in the destructor he needs to free both native and managed objects. Assuming that it's going to be far rarer for a class to be using native objects compared to managed objects, in the majority of situations, I believe that well-designed classes won't need a finalizer. And I do agree with you that in the second case, it's smarter to use a reference counting mechanism than rely on a non-deterministic GC cycle to clean up your scarce resources. But now I believe, the thread is slipping into a different topic - whether Garbage Collection actually does anyone any good Nish My blog on C++/CLI, MFC/Win32, .NET - void Nish(char* szBlog); My MVP tips, tricks and essays web site - www.voidnish.com Sign In·View Thread·PermaLink 5.00/5 (2 votes) Accessing a disposed object/dangling reference Jörgen Sigvardsson 5:52 14 Aug '04   Consider: Class func() { Class obj; return obj; } ... Class obj = func(); obj.DoSomething(); What will happen when calling DoSomething and copying the return value of func()? In ordinary C++, the above code would copy the object returned by the function before killing it. If it differs from ordinary C++, then I'm wondering if this new mechanism is such a good thing after all. I'd rather be forced to use reference semantics than shooting myself in the foot without realizing that I did shoot myself in the foot. -- Denn du bist, was du isst! Und ihr wisst, was es ist! Es ist mein Teil...? Sign In·View Thread·PermaLink 5.00/5 (1 vote) Re: Accessing a disposed object/dangling reference Stephane Lajoie 16:16 14 Aug '04   You're right, this looks a bit dangerous. However, it would be very easy for the compiler to provide a warning in this case. Hopefully it will. You might want to submit this to the MSDN feedback center if it isn't there already. I'm waiting for beta2 before I really dig into C++/CLI myself... Sign In·View Thread·PermaLink Re: Accessing a disposed object/dangling reference Nishant S 1:57 18 Aug '04   Stephane Lajoie wrote: However, it would be very easy for the compiler to provide a warning in this case. Hopefully it will. Even better, it won't even compile it as there is no default copy ctor in C++/CLI for ref classes My blog on C++/CLI, MFC/Win32, .NET - void Nish(char* szBlog); My MVP tips, tricks and essays web site - www.voidnish.com Sign In·View Thread·PermaLink Re: Accessing a disposed object/dangling reference Nemanja Trifunovic 6:25 16 Aug '04   Good point. I find this "pseudo-stack" syntax problematic too. Maybe it would be better to use a separate keyword for deterministic ddestruction of object (like in D) Also, I am not sure I like the idea of mapping destructors to Dispose(). Dispose() has a well-defined role that is really a subset of what destructors are meant for. My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it. Sign In·View Thread·PermaLink Re: Accessing a disposed object/dangling reference Nishant S 23:37 17 Aug '04   Hi Jörgen ref classes do not have a compiler generated copy constructor. So you are not going to shoot yourself in the foot. Nish My blog on C++/CLI, MFC/Win32, .NET - void Nish(char* szBlog); My MVP tips, tricks and essays web site - www.voidnish.com Sign In·View Thread·PermaLink Re: Accessing a disposed object/dangling reference Jörgen Sigvardsson 23:44 17 Aug '04   So basically, it's pretty much impossible to return a (valid) "stack object" from a function? Or does it detect that the object is returned, thus omitting the "destruction" of it? I assume the earlier case since resolving aliased references may be a pretty hard problem. -- Denn du bist, was du isst! Und ihr wisst, was es ist! Es ist mein Teil...? Sign In·View Thread·PermaLink Re: Accessing a disposed object/dangling reference Nishant S 1:22 18 Aug '04   Jörgen Sigvardsson wrote: So basically, it's pretty much impossible to return a (valid) "stack object" from a function? Hey Jörgen, Well, you can write your own copy-constructor; this will now let you return a pseudo-stack object from a function. But of course, this is again a C++ compiler trick. Your function's return type is changed to void in the generated IL and a new parameter is added (which is of the type of the object you are trying to return). So if you had RefClass GetObject() in your C++ code, the compiler compiles it into void GetObject(RefClass^ r) in the IL. And wherever in your code that you use RefClass x = GetObject(), the IL is changed to RefClass^ x; GetObject(x); Sneaky, ain't it? Nish My blog on C++/CLI, MFC/Win32, .NET - void Nish(char* szBlog); My MVP tips, tricks and essays web site - www.voidnish.com Sign In·View Thread·PermaLink 5.00/5 (2 votes) Re: Accessing a disposed object/dangling reference Jörgen Sigvardsson 1:27 18 Aug '04   Nishant S wrote: Sneaky, ain't it? Very! I can only assume that Microsoft will add compiler generated copy constructors in the final release of the compiler. If they are set on mimicing "true" C++ behaviour, they ought to do it 100%. If they manage that, I wouldn't have any problems with any of their "sneaky tricks" -- Denn du bist, was du isst! Und ihr wisst, was es ist! Es ist mein Teil...? Sign In·View Thread·PermaLink Re: Accessing a disposed object/dangling reference Nishant S 1:37 18 Aug '04   Jörgen Sigvardsson wrote: I can only assume that Microsoft will add compiler generated copy constructors in the final release of the compiler I don't think they will. Brandon Bray said that the reason they decided thus was that other CLI languages do not emit default copy ctors. And one of the aims for the VC++ team is to make sure that managed types generated by C++ should be as similar as possible to managed types generated by higher-level languages like C# or VB.NET. But of course, they don't stop you from writing your own copy ctors. Nish My blog on C++/CLI, MFC/Win32, .NET - void Nish(char* szBlog); My MVP tips, tricks and essays web site - www.voidnish.com Sign In·View Thread·PermaLink Re: Accessing a disposed object/dangling reference msalters 22:47 18 Aug '04   WG21 has received a proposal which would allow the generation of default implementations by adding "default" to the member declaration. So a default copy ctor could be defined by declaring "default C( C const& src );" inside class C. Even if not added to ISO C++, it is useful for C++/CLI. Sign In·View Thread·PermaLink C++ 2005 Beta 2 Anonymous 23:58 12 Aug '04   Hi, with interest I've read this article. I noticed that you have shown the stack-based semantic for reference types. As I've installed VS 2005 Beta 2 I know that this functionality isn't currently available in the C++ compiler. How did you get that compiled ? Is there any new version of the C++ 2005 compiler available ?? Best regards andi Sign In·View Thread·PermaLink Re: C++ 2005 Beta 2 Nishant S 0:11 13 Aug '04   Hello You must have installed beta 1, beta 2 is not out yet. Beta 2 is supposed to support automatic variables. As for me, I used an alpha version of the compiler that supports this feature. Nish My blog on C++/CLI, MFC/Win32, .NET - void Nish(char* szBlog); My MVP tips, tricks and essays web site - www.voidnish.com Sign In·View Thread·PermaLink Re: C++ 2005 Beta 2 Tanveer Badar 6:16 28 Jan '05   Actually the CTP(community technical preview) release of VC++ 2005 supports stack semantics for ref classes.The download is about 37 MB available from the VS 2005 site. Sign In·View Thread·PermaLink 2.00/5 (1 vote)

Last Visit: 14:36 23 Nov '09     Last Update: 14:36 23 Nov '09 1