开发者

I want to allocate an object on the stack with C#

开发者 https://www.devze.com 2023-01-23 20:08 出处:网络
Say I have this C# class: public class HttpContextEx { public HttpContext context = null; public HttpRequest req = null;

Say I have this C# class:

public class HttpContextEx
{
    public HttpContext context = null;
    public HttpRequest req = null;
    public HttpResponse res = null;
}

How do I declare an object of it, inside a function, which will be allocated on the stack and not on the heap?

In other words I want to avoid using the 'new' keyword for this one. This code is bad:

HttpContextEx ctx = new HttpContextEx(); // << allocates on the heap!

I know what stack/heap are perfectly and I've heard of the wonderful C# GC, yet I insist to allocate th开发者_运维问答is tiny object, which is here only for convenience, on the stack.

This attitude comes from C++ (my main tool) so I can't ignore this, I mean it really ruins the fun for me here (:


If you changed it to a value type using struct and create a new instance within the body of a method, it will create it on the stack. However the members, as they are reference types will still be on the Heap. The language whether it be a value or a reference type will still require the new operator but you can use var to eliminate the double use of the type name

var ctx = new HttpContextEx(); 

Otherwise, take C# as it is since the GC does a great job.


You can't (and shouldn't) do that. Even if you would use a struct (which will be put on the stack), you'd have to use the new operator for the contained classes. On a serious note, if you switch to another language, also switch your attitudes.


You must come from C++. Things don't work like that in .Net.

All reference types are allocated on the managed heap, where they are tracked by the GC. For object references scoped by a function which exits quickly, allocated objects most likely remain only in Generation 0 of the Managed Heap, and this results in very efficient memory collections. The Managed Heap is tuned to handle short lived objects like this. It doesn't even have the same allocation strategy as the C++ heap you may be used to.

This is how the CLR works. If you want to work in another way, try an unmanaged runtime.


In .NET classes are reference types, and structures are value types.

If you really want the type allocated on the stack, you can make a structure. There are however several reasons not to:

  • Structures are more complicated to implement correctly. You should stick to classes until you have a good reason to create a structure.
  • Structures are intended for types that represent a single unit, while your type is just a container for three separate units.
  • A structure should not be larger than 16 bytes to work efficiently. On a 32 bit system you get under that limit, but on a 64 bit system the structure is larger than that.
  • A structure should be immutable to work well as a value type, which your type is not.

Finally, there isn't anything inherently bad about allocating small objects on the heap. The memory manager is actually specifially designed to handle small short-lived objects efficiently.

Here is an example of code that doesn't work if it's a structure, but works fine if it's a class:

public void SetContext(HttpContextEx ex) {
  ex.context = HttpContext.Current;
  ex.req = ex.context.Request;
  ex.res = es.context.Response;
}

HttpContextEx ctx = new HttpCoontextEx();
SetContext(ctx);
0

精彩评论

暂无评论...
验证码 换一张
取 消