Design of stack objects in C ++/CLI

Reproduced on Li Jianzhong's blog

Jefong 2005/0729

Design of stack objects in C ++/CLI
The new automatic deterministic destruction in C ++/CLI is regarded as an excellent design. The so-called C ++/CLI "New Bottle" is used to hold the old wine "raiI" proposed by Bjarne stroustrup ".

This is indeed good. Relatively speaking, this is much better than the using keyword in C # (dispose mode) and the hard-coded dispose method in Java. This feature is provided by the stack object (local object) in C ++/CLI. The local object itself is correct, and raiI is also the proper meaning of the local object.

But the problem is that the availability of stack objects in C ++/CLI will be greatly reduced for many reasons, the use is far from as smooth as in ISO-C ++. The following lists several major injuries that damage their availability:

#1. The C ++/CLI stack object is not really in the stack.

As long as the type is ref class, the stack object in C ++/CLI is still in the managed heap. The newobj il command is still used for allocation. If R does not define the Destructor (~ R) (Note: The destructor in C ++/CLI and the destructor in C # are completely different .)CodeIn fact, the same il code will be generated:

R;
R h = gcnew R;

It seems that herb Sutter once said that they may allocate R in the real method stack in the future-to be honest, I am afraid only people with the c ++ background will dare to "think about it" :) now they just want levelProgramClerk "feels" just like R is allocated from the stack. Another syntax SUGAR :)

Of course, to ensure the symmetry and semantics are perfect, sometimes % needs to be applied to R-although nothing is left behind :)

 

#2. C ++/CLI compilers do not automatically generate copy constructor and copy assignment operators by default.

This is very annoying, and it makes people almost "block stack objects ". Worse, all types of Bcl do not provide the copy constructor and the copy assignment operator-I am afraid only C ++/CLI will use them.

In other words, even if C ++/CLI will automatically generate a copy constructor and a copy assignment operator, it will be very troublesome to inherit from the type of bcl.

#3. If a function is to be called by other CLI languages, it cannot be designed as a stack object.

A. Static void add (r ){...}

A modopt metadata is compiled, so it can be called by other languages. However, if it is called by other languages, such as C #, other languages will pass references by passing values, c ++/CLI will pass object copy (to call the copy constructor), so the semantics is confusing and it is completely impossible to do so.

B. Static void add (R % R ){...}

The compiled modreq metadata cannot be called by other CLI languages.

 

#4. If a function is to be called by other CLI languages, it cannot be designed as a stack object.

A. Static R add (){...}

B. Static R % add (){...}

Both of them have a modreq metadata, so neither of them can be called by other CLI languages.

 

#5. When using BCl, if you want to pass the stack object, always use the "inexplicable" % Operator

For example:

String S ("ABC ");
Arraylist list;
List. Add (% s );

It is really bad, but it is better to use trace reference:

String ^ s = "ABC ";
Arraylist ^ list = gcnew arraylist ();
List-> Add (s );

Summary:

#1 and #5 have no significant impact on the availability of stack objects. After all, it is feasible to understand them at the semantic level.
However, the effects of #2, #3, and #4 are significant. #3 and #4 make it necessary to discard stack objects for interoperability. #2 makes Writing C ++/CLI code very inconvenient-unless you do not want to use stack objects in the future.

The question is, is the stack object in C ++/CLI only available for automatic deterministic resource recovery? Worth