Die Laufvariable bei foreach darf man nicht ändern, soweit richtig.
Den Inhalt sehr wohl, das machst du bei Klassen sicher ständig. Auch in dem Beispiel wird das mit einer Klasse gemacht.
Und es wird mit einem Struct versucht. Beim Struct schlägts aber fehl. Warum nur beim struct und nicht bei class?

Wie erklärst du das foreach Beispiel?

Er versucht s einen neuen Wert zuzuweisen, obwohl ich nur den Inhalt verändert habe.

class TestClass
{
    public int Value;
}

struct TestStruct
{
    public int Value;
}

class Programm
{
    static void Main()
    {
        TestClass[] array1 = new TestClass[]{ new TestClass() };
        TestStruct[] array2 = new TestStruct[]{ new TestStruct() };

        foreach( TestClass c in array1 )
            c.Value = 5;

        foreach( TestStruct s in array2 )
            c.Value = 5;
    }
}

Wertetypen sind prinzipiell imutable. Genau dieses verhalten ahmt string nach. Selbst wenn die Übergabe prinzipiell per Referenz funktionieren würde, und ref immer eine Referenz auf eine Referenz übergeben würde (so wie es eben beim String Typ passiert), hast du durch die Unveränderbarkeit exakt das gleiche Verhalten wie im Moment.

Ich bestreite ja garnicht, dass es hinter dem Code unterschiede gibt. Nur wenn man das Verhalten des ref keywords diskutiert, sollte man auch nur das Verhalten betrachten.

Nein, Wertetypen und Referenztypen werden in diesem Aspekt genau gleich behandelt.

Nur gibt es bei Wertetypen keine Änderungen, sie sind unveränderbar und werden deswegen immer neu zugewiesen wenn du etwas "änderst". Deswegen kommen Änderungen nicht Auße an, es gibt sie nämlich nicht.

Das ist der einzige Unterschied und der hat nichts mit dem ref keyword zu tun.

Mir ist klar, dass unter der Haube ein Wertetyp als Kopie übergeben wird. Aber selbst wenn nicht wäre genau das gleiche Verhalten zu beobachten, das ist mein Punkt. Siehe die string Klasse.

Versuche z.B. mal ein foreach über ein Array von structs und "ändere" das struct. Hier wird dir genau dieses Verhalten auf die Füße fallen.

IsBackground sorgt lediglich dafür, dass die background Threads automatisch beendet werden, wenn es keine foreground Threads mehr gibt. Sprich wenn deine Anwendung beendet wird.

Ich glaube immernoch dein Algorithmus ist fehlerhaft.
Es gibt nur 2 Gründe um überhaupt Threads anzulegen:

1. Asynchrone Ein-/Ausgabe. Dazu reicht ein Thread pro Ein-/Ausgabe, manchmal auch weniger. So kann man mit einem Thread z.B. mehrere Sockets abfragen.
2. Parallele Verarbeitung. Das aber auch nur solange du weniger Threads als Prozessoren hast.

Zumal die vielen Threads ein ordentliches Profiling recht schwer machen.
Von ner theoretischen Laufzeitanalyse mal ganz zu schweigen.

Der Performanceverlust ist nur durch schlecht angepassten Code zu erklären.
Dein Code ist dafür gemacht eben mit 3000 Threads zu arbeiten und nicht ohne weiteres auf 20 Threads zu übertragen.

Oder um es anders zu formulieren: Du hast ein Dreieck gebaut, setzt dies nun in eine Viereckige Form, und wunderst dich, dass es wackelt.

Original von Cord Worthmann
Alleinig die ref Anweisung würde entscheiden, ob Parameter "überschreibbar" oder nur "benutzbar/veränderbar" wären - die Adressierungsfrage wäre jedoch einwandfrei geklärt.

Ähm, genauso ist es doch im Moment.
Ohne ref kannst du nur benutzen/verändern, nur mit ref kannst du überschreiben. Egal ob Wertetyp oder Referenztyp.

Eigentlich wenn du die Daten gleich in ne DataTable lädst, und diese dann per Remoting verschickst, kümmert sich der HttpChannel darum, dass es in XML übersetzt wird, und auf der anderen Seite zu einer DataTable zusammengebaut wird.

Objekt ist eben eine Klassifizierung. Du hast doch selbst definiert was es ist. Wenn du Objekt sagst, bezeichnest du damit einen ganz speziellen Gegenstand, so wie wenn ich "mein PC" sage? Nein, du beschreibst eine Gruppe von Gegenständen mit gleichen Eigenschaften.
Ich versteh echt nicht was du willst.

Wie kannst du etwas Objekt nennen, und gleichzeitig sagen es ist nicht vom Typ Objekt?

Da wäre nichts sauberer dran wenn du dir irgendwelchen Quatsch ausdenkst.

Eine Klasse ist eine Beschreibung. Und Object beschreibt eben alle Objekte.
Ich find daran nichts seltsam.
Genauso wie "Objekt" eine Klasse sein kann, kann auch eine Klasse ein Objekt sein, es hängt eben vom Kontext ab.

Ist eigentlich schon jemand auf die Idee gekommen "Gegenstände und Sachverhalte" als die Objekte in dem Zitat, und sowohl "Abbild" als auch "Urbild" als eine Beschreibung einer Gruppe von Objekten, also als Klassen zu sehen?

Konnte nicht allem so ganz folgen was hier verfasst wurde 😉