The design problem of stack object in C++/CLI

The new automated Deterministic resource recovery (Automatic deterministic destruction) in C++/CLI is considered an excellent design. Is the use of the so-called C++/CLI this "new bottle" to install Bjarne Stroustrup proposed raii this "old wine."

This is really good, relatively speaking, which is much better than the using keyword in C # (Dispose mode), and the Dispose method of hard-coded in Java. This feature is provided by the Stack object (local object) in the C++/CLI, the local object itself is correct, and the raii is the meaning of the local object.

But the problem is that the usability of the stack object in C++/CLI is greatly compromised for many reasons and is far less fluent than the iso-c++. Here's a list of some of the major damage to their usability:

#1, C++/CLI stack objects are not really located in the stack

The Stack object is still in the managed heap as long as the type is in ref CLASS,C++/CLI. is still allocated using the newobj IL directive. If R does not define a destructor (~r) (note: The destructor in C++/CLI is completely different from the destructor in C #), the following two lines of code will actually produce exactly the same IL code:

R R;

R h=gcnew R;

Seems to remember Herb Sutter once said that they might in the future in the true method stack distribution r--Tell the truth I'm afraid only C + + background people dare so "cranky":) They are now just trying to make the programmer "feel" at the grammatical level as if r were allocated from the stack. Another syntax sugar:

Of course, for the sake of symmetry and semantic perfection, sometimes it is necessary to apply%--on R Although there is still nothing to do behind the scenes:

#2, C++/CLI compiler does not automatically generate copy constructors and copy assignment operators by default

This is very disturbing, almost let people "look at the stack object and deterred." What's worse is that none of the types in BCL provide copy constructors and copy assignment operators--because I'm afraid only c++/cli will use them.

In other words, even if c++/cli automatically produces copy constructors and copy assignment operators, it can be cumbersome to inherit from the BCL type.

#3, if a function is to be called by another CLI language, its parameters cannot be designed as stack objects

A. static void Add (R r) {...}

Compiled to have a modopt meta data, so it can be invoked in other languages, but if it is called by other languages, such as C #, then other languages will be passing the reference in the form of a value, and C++/CLI will be the transfer of the object copy (to invoke the copy constructor), so the semantic clutter is completely out of the way.

B. static void Add (r% R) {...}

Because it is compiled with a modreq metadata, it cannot be invoked by other CLI languages.

#4, if the function is to be called by another CLI language, you cannot design its return value as a stack object

a. static R add(){...}
b. static R% add(){...}

Both are compiled with a modreq metadata, so they cannot be invoked by other CLI languages.

#5. When using BCL, if you want to pass the stack object, always use the "inexplicably"% operator

Like what:

String s("abc");
ArrayList list;
list.Add(%s);

It's really bad, or it's better to use a tracking reference:

String^ s="abc";
ArrayList^ list=gcnew ArrayList();
list->Add(s);

To sum up:

#1和 #5 The availability of the stack object is not large, after all, from the semantic level to understand, or can be done.

However, #2, #3, #4的影响就很大. #3和 #4 allows us to discard the use of stack objects for interoperability. and #2会让编写C ++/CLI code is very inconvenient--unless you want to use the Stack object later.

The question now is, does the stack object in the C++/CLI exist only to obtain automatic deterministic resource recycling? Is it worth doing this?