AUTOMATIC DETERMINISTIC DESTRUction is considered an excellent design in C / CLI. This is the "old wine" that uses the so-called C / CLI this "new bottle" to install Bjarne Stroustrup.
This is true, relatively, this is much better than the USING keyword (Dispose mode) in C #, and the hard-code DISPOSE method in Java. This feature is provided by the C / CLI in the stack object (local object), and the local object itself is incapable, and the RAII is also the meaning of the local object.
But the problem is that the availability of stack objects in C / CLI is a lot of discounts, which is far less smooth as ISO-C because many reasons. There are several great hard injuries that damage their availability:
#1. Stack of C / CLI is not really in the stack
As long as the type is REF CLASS, the stack object in the C / CLI is still in the hosted stack. Still using the Newobj IL instruction to allocate. If r does not define a destructor (~ r) (note: the destructor in the C / CLI and the destructor in the C # completely two things), then the following two lines of code will actually generate exactly the same IL code:
R r; r h = gcnew r;
It seems that Herb Sutter has said that they may allocate r in the real method stack in the future, I am afraid that only c background people dare to be "cousc" :) They just want to make programmers "feel" Like R is the same as that is assigned from the stack. Another Syntax Sugar :)
Of course, for the perfection of symmetrics and semantics, sometimes it needs to apply% on R - although there is still nothing behind :)
#2. C / CLI compiler does not automatically generate copy constructor and copy assignment operators without automatically by default
This is very annoying, almost lets "look the stack of objects". Worse, all types in the BCL do not provide copy constructor and copy assignments - because I am afraid that only C / CLI will use them.
If you come back, even if the C / CLI will automatically generate copy constructor and copy assignment operators, it will be very troublesome of the type of BCL.
# 3. If the function is to be called by other CLI languages, then its parameter is designed as a stack object.
a. static void add (r r) {...}
Compiled with a modopt metadata, so you can be called by other languages, but if you are called by other languages, such as C #, then other languages will be delivered in the way, and the C / CLI will be the transfer object copy (to call Copy the constructor), so the semantics is confusing, it can not do this.
b. static void add (r% r) {...}
Since there is a modReq metadata due to compilation, it cannot be called in other CLI language.
# 4. If the function is to be called by other CLI languages, then it cannot return its return value as a stack object
a. static r add () {...}
b. static R% add () {...}
There is a ModReq metadata compiled out, so you can't be called in other CLI languages.
# 5. When using BCL, if you want to transfer a stack object, you always use "inexplicable"% operator.
such as:
String S ("ABC"); arraylist list; list .add (% s);
It's really bad, or it is better to use tracking reference:
String ^ s = "abc"; arraylist ^ list = gcnew arraylist (); list-> add (s); summary:
# 1 and # 5 The effect of the usability of the stack object is not big, after all, is understood from the semantic level, or it is available. However, the influence of # 2, # 3, and # 4 is great. # 3 and # 4 allow us to give up the use of stack objects to perform interoperability. And # 2 will make the C / CLI code very inconvenient - unless you don't want to use the stack object in the future.
The problem now is whether the stack object in the C / CLI is just to get the automatic deterministic resource recovery? Is it worth doing?
