Canvas.Children.Add(<allocated memory>)?

[GregJ7]

Am I correct in thinking that the object line will not be allocated on the stack, because the compiler recognizes that myCanvas.Children.Add(line) only passes a reference to the line and must not be popped off the stack when the function exits?

// concept code, not tested
public void MyAddLine(float x1, float y1, float x2, float y2)
{
    Line line;
    line.Visibility = Visibility.Visible;
    line.StrokeThickness = 1;
    line.Stroke = Brushes.Orange;
    line.X1 = x1;
    line.Y1 = y1;
    line.X2 = x2;
    line.Y2 = y2;
    myCanvas.Children.Add(line);

If I am being dumb, then my question really is, do I need to keep a copy of objects (Lines) in memory that I add to the Canvas.Children collection, because Add() does not copy the line information, but only a reference, which will be needed when the lines are redrawn (such as if the window is resized)?

Thanks.

 

[Skydiver]

This is what happens when learning C# is trumped by leaning how to do graphics in .NET. *sigh*.

Reference types (like classes) do not live on the stack. They are created in the heap when you call new. I'm surprised that your code above works without calling new between lines 4 and 5. If there are no more references to the object after you leave the scope of your MyAddLine(), then the object will be eligible for garbage collection. But at line 12, you are giving a reference of the object to the canvas for it to also retain a reference. So in this case, when the scope leaves your method, the object will not be eligible for garbage collection because there are still references to the object.

 

[GregJ7]

I confused this problem with one I had earlier. Coming from a C and C++ background I'm well aware of the difference between value and reference types (which doesn't mean I know C# all that well, lol; and since C++ has changed so much from when I used it professionally, I can't say I know it anymore, either). The problem I confused it with was that I was doing a "PointF p" in a function, which is a struct, but I was getting a compile error using it until I made it into PointF p = new(); Why is that? In my mind PointF, being a struct, is no different than doing an "int p" (for which "= new()" is not needed). I can recreate the actual code if my above description from memory is insufficient.

Regarding the OP, I forgot counts are kept of referenced objects. Thanks.

 

[GregJ7]

"PointF p" in a function, which is a struct, but I was getting a compile error using it until I made it into PointF p = new(); Why is that?

Gah. Just found out struct instances are boxed. Not sure why structs even exist in C#. Seems too much like a class except with methods disallowed. (I'm sure I'll discover reasons, eventually.)

I guess I need a greater paradigm shift to C# than I thought. So used to everything being value types and unmanaged memory, except when explicitly otherwise (pointers, reference types).

 

[Skydiver]

Value types a great when you just need them for a short lifetime because they live on the stack and don't use up heap space and cause memory fragmentation. Also they are great when put into arrays or in the default implementation of lists in the heap so that you can get spans of them. When they are in contiguous blocks of memory, the CPU can ahead memory cache successful most of the time and you get a speed boost. If you also happen to use the new Span<T> or Memory<T> can can further boost performance by not having to move chunks of data around.

All of these memory boosts though should be considered only after having a solid grounding on programming in C#.

 

[Skydiver]

Seems too much like a class except with methods disallowed.

Methods are allowed on structs. Fir example, the DateTime struct.

DateTime Struct (System)

Represents an instant in time, typically expressed as a date and time of day.

learn.microsoft.com