Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "what are the functions of C# 7.2 and 8.0". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Read-only references and read-only structures [7.2 prototype]

The first ones mentioned are read-only references and structures. In a nutshell, this feature allows C # to use parameters similar to const to improve performance. Like the "ref read-only parameters" and the simple "in parameters" as we know them, these features enable large structures to be passed by reference and do not allow modification.

Part of this proposal is a read-only structure. After the developer marks a structure as read-only, it means that no method can modify the structure. This will greatly improve performance because it tells the compiler that it can skip copy operations that are usually used to prevent accidental modification of read-only variables.

Blittable type [7.2proposal]

Wikipedia describes the blittable type as follows:

In Microsoft's .NET Framework, the memory representation of data in managed code is quite different from that in unmanaged code. However, the blittable type is defined as the representation of data in memory is exactly the same in these two different environments and can be shared directly.

Non-blittable types include Boolean, string, char, and all reference types. If a structure contains one of these types, then the structure itself is non-blittable.

Currently, the C # compiler infers whether a type is blittable by checking its structure. This has caused some problems in the past, because sometimes adding a new field makes a blittable type non-blittable, but in some cases this change can be fatal.

It is mentioned in the Blittable type proposal that you can explicitly define a structure as blittable using the keyword "blittable". If its type is later changed to non-blittable, the compiler will report an error.

To ensure long-term backward compatibility, structures defined as blittable can only contain structures that are also explicitly defined as blittable. In addition, StructLayout (LayoutKind.Auto)] cannot be used in the structure. It represents the arrangement of structures in physical memory. Both Explicit layout and sequential layout are available.

Note: LayoutKind or Pack that can modify a structure is considered a breakthrough because it improves the way unmanaged code accesses the structure.

Microsoft is worried about the transition of this feature. Lower-level class libraries must adopt explicit blittable types before higher-level class libraries can use them.

Security Enhancement during compilation of ref-like types [proposal 7.2]

This feature is also called "interior pointer" or "ref-like type (ref-like types)". The proposal allows the compiler to require that only certain types, such as Span, appear on the stack. The following reasons are listed:

Span semantically represents a structure (ref T data, int length) that contains a reference and a scope. Regardless of its implementation, writing to this type of structure is not atomic. Concurrently "tearing" this structure may result in a mismatch between its length and data, which may lead to out-of-range (out-of-range) and type insecurity, which may eventually lead to heap crashes at GC, even though the code appears to be "safe".

In some Span implementations, its fields contain a managed pointer (managed pointer). Managed pointers do not support fields of heap objects, and pointing managed pointers to code placed on the GC heap crashes during JIT (Just-in-time).

Span allows you to reference data in local stack frames: individual local variables or arrays allocated on the stack. When the life cycle of an instance of Span exceeds the referenced data, this leads to undefined behavior, including type safety violations and heap crashes.

The ref-like type has the following usage restrictions:

Ref-like type cannot be an element of an array

Ref-like types cannot be used as generic type parameters

Ref-like variable cannot be boxed

Ref-like type cannot be used as a field of normal non-ref-like type

Some indirect restrictions, such as not allowing the use of ref-like types in asynchronous methods, and asynchronous methods do not support ref-like type fields

In fact, this means that ref-like types can only be used as parameters, local variables, and return values in some cases. The ref-like type can contain another ref-like type.

All ref-like types are read-only structures (as described above).

Like the ref type, the ref-like type may eventually become a "single-assignment" type. The proposal also mentions other ways to ensure security, but this method is the least burden on the compiler.

C # 8.0 prototype

Two new features of C# 8 have reached the prototype stage:

Nullable reference types (Nullable Reference Types): this feature makes all reference types non-nullable by default. If you could use non-empty types, would you still use T (template)? Just like you would use an empty structure.

Default interface method (Default Interface Methods): this feature allows C # to introduce limited forms of multiple inheritance.

This is the end of the content of "what are the functions of C# 7.2 and 8.0". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.