shared pointers and memory cycles in C++ and Swift

[andr1972]

We have

public class Elem
{
       public Elem()
       {
       }
       public void Init(string label)
       {
              Label = label;
       }
       string() Label;
       Elem Next;
       public Elem GetNext() => Next;
       public void SetNext(Elem value) { Next = value; }
}


class Test
{
	Elem make3cyclic()
	{
		Elem# A = new Elem();
		A.Init("A");
		Elem# B = new Elem();
		B.Init("B");
		Elem C = new Elem();
		C.Init("C");
		A.SetNext(B);
		B.SetNext(C);
		C.SetNext(A);
		return A;
	}

	Elem make3nonCyclic()
	{
		Elem() A;
		A.Init("A");
		Elem() B;
		B.Init("B");
		Elem() C;
		C.Init("C");
		A.SetNext(B);
		B.SetNext(C);
		return A;
	}
}

in C++ code, both methods (make3cyclic and make3nonCyclic) have no cycles becuse all elements are freed but return pointer to freed memory.
My idea: in second function where is Elem() A should be denied return elem, allowed in first where is Elem# A = new Elem()
next: everywhere use shared_ptr's instead of raw pointer, although this can lead to memory cycles.
Must be class to detect and analyze cycles. If will both next and prev fields - only one must be strong, rest mu be weak - keyword weak. Similar : in tree child list is strong, parent is weak (I don't now how compiler can avoid reverse situation : parent strong, childs list weak).
Probably is impossible detect all cycle situation, in cyclic list, before end block in c++ can be

int main()
{
    Test test;
    std::shared_ptr<Elem> a = test.make3cyclic();
    std::cout << "before << std::endl;
    a->getPrev().lock()->setNext(nullptr);    //<-------------here 
    std::cout << "in middle" << std::endl;
}

All unclear cycle situation compiler must deny.
ASK: only in c++/swift code, Garbage Collector can handle all ? or better deny at all these unclear situation (compiler will more permissive than Rust anyway (?))

[pfusik]

Minor: Your code doesn't compile:

C:\0\ci>cito -o 53.cs 53.ci
53.ci(25): ERROR: Dynamically allocated object must be assigned to a Elem# reference

Major:

1. Why code a singly-linked list if you can use List<T>() ? It's faster, takes less memory and supports several operations.

2. Why allocate every element on the heap if you can have them owned by the List ?

Consider this code:

public class Elem
{
   public Elem()
   {
   }
   public void Init(string label)
   {
          Label = label;
   }
   string() Label;
}


class Test
{
    List<Elem()>() MyList;

    void Init()
    {
        MyList.Add();
        MyList.Add();
        MyList.Add();
        MyList[0].Init("A");
        MyList[1].Init("B");
        MyList[2].Init("C");
    }
}

It's shorter, more performant and doesn't have any leaks or dangling references.

in second function where is Elem() A should be denied return elem

Implemented in 9589f83. Thanks!

allowed in first where is Elem# A = new Elem()

This is also wrong. You should return Elem#.

everywhere use shared_ptr's

Not sure what you mean? Remove object storage, read-only and read-write references from Ć? I expect them to be used much often than dynamic references.