Das hat nix mit Pedanterie/Blödsinn zu tun. Durch diese vielen kleinen Fehlgriffe wirkt die Collection API nicht sehr konsistent. Vorallem wenn schon viele andere, recht brauchbare, APIs entwickelt wurden. Man hätte sich einfach nur "inspirieren" lassen müssen. Das Rad muss nicht schlecht neu erfunden werden.
Und ja, es hat mich schon aufgehalten. Ich kann zum Beispiel keine abstrakte Listenschnitstelle bei .NET finden, das von der konkreten darunterliegenden Implementation abstrahiert.

Ich bleibe dabei. Die Collection-Klassen in .NET sind nicht wirklich gut.

Original von herbivore
Vielleicht ist der Name etwas irreführend.Unter einer IList im .NET Sinne ist "eine Auflistung von Objekten [zu verstehen], auf die einzeln über einen Index zugegriffen werden kann.".

Das ist nicht nur ein etwas irreführend, sondern ziemlich Inkonsistent. Scheinbar hat man bei MS eine etwas seltsame Vorstellung darüber was eine Liste (mal ganz abstrakt gesehen) überhaupt ist.

Das ist bei LinkedList nicht der Fall und deshalb wird konsequenterweise IList nicht implementiert.

Bingo. LinkedList kennt keinen indizierten Zugriff. Dann stellt sich die Frage, warum man überhaupt ein IList interface entwickelt/benannt hat, wenn IList übehaupt nichts mit Objekten zu tun hat, die sich ebenfalls als Liste bezeichen.
Toll ist auch die englische Dokumentation zu IList:
The IList generic interface is a descendant of the ICollection generic interface and is the base interface of all generic lists.
Was ist denn nun mit LinkedList? Ist das keine Liste?

Nein, da du von einer Fehlannahme ausgegangen bist, ist hier alles in Ordnung. LinkedList implementiert alle nötigen (Collection-)Interfaces als da sind: ICollection<T>, IEnumerable<T>, ICollection, IEnumerable.Es ist also nicht möglich die konkreten List-Implementierungen von ihrer abstrakten Schnittstelle zu trennen.
Doch, da du von einer Fehlannahme ausgegangen bist, ist auch hier alles in Ordnung.

Welche Fehlannahme? Es geht hier darum, dass MS für seine Klassen extrem unsinnige Namen verwendet und das darunter die Konsistenz der API leidet. Es gibt noch weitere Beispiele. Im Namensraum ObjectModel gibt es eine Klasse namens Collection, die IList und ICollection implementiert. Meinst du wirklich das ein so allgemeiner Name wie Collection zu einer Klasse passt die ICollection und IList implementiert. Vorallem wird daraus nicht klar was MS eigentlich für Designziele bei den Collection Klassen hatte.
Man schau sich nur mal die Java Collection-Klassen an, da wird mir sofort klar was sich die Entwickler gedacht haben.

Du magst die Collection Klassen vielleicht gut finden aber glücklicherweise bin ich nicht der Einzigste der das so sieht (Diverse - teilweise schon recht böse - Blogkommentare beim BCL-Team belegen das...)

Teilweise hat das glaube ich nicht mehr so viel mit Geschmackssache zu tun. Mal ein Beispiel für eine typische Fehlleistung beim Design der Collection Klassen:
Im Framework gibt es ein IList interface. Jeder halbwegs logisch denkender Mensch würde annehmen, dass alles was sich wie eine Liste verhält bzw. eine Liste ist, dieses Interface implementiert. Genau das ist aber nicht der Fall. LinkedList implentiert IList aber überhaupt nicht. Damit wird das Interface-Konzept bei den Collections ad absurdum geführt. Es ist also nicht möglich die konkreten List-Implementierungen von ihrer abstrakten Schnittstelle zu trennen.
Hier hätte man durchaus von Java "klauen" können, die Ingenieure dort haben nämlich deutlich sauberer gearbeitet...
Ein kleiner Nachhilfekurs in Sachen Objektorientierter Programmierung würde so manchem MS-Entwickler gut tun 😉

Original von Rainbird
Unmanaged Code (z.B. C++) ist schneller als managed Code. Das ist Fakt. Die ganzen Sicherheitsprüfungen etc. und die meistens verwendete JIT-Kompilierung schlagen auf den Geschwindigkeits-Magen. Dafür ist alles einfach, toll und sicher. Außerdem wird die sozusagen "Neue Windows API" von Vista großtenteils in managed Code geschrieben sein. Der .NET Zug fährt aus jetziger Sicht am weitesten in die Zukunft.

Naja, wenn ich mir so einige SciMark Benchmarks ansehe, dann kommen mir schon Zweifel ob das nun ein unumstößlicher "Fakt" ist. Ich denke es liegt vorallem an den Verwendeten Jit-Compilern und ihren Möglichkeiten Code zu optimieren. Eine gewisse Setup-Time beim Start bekommt man natürlich nie weg. Im Bereich Performance und verwaltete Sprachen, wird man in Zukunft aber garantiert so einiges zu sehen bekommen. (Siehe einige sehr interessante MS Research Projekte)

Java ist .NET eigentlich ebenbürtig. Als Nachteil könnte man die Stückelung von Java sehen. Bei .NET gibt es die Base Class Library. Die ist fett und rund und macht alle glücklich. Bei Java ist das nicht ganz so ...

Da kann man sich streiten, ob Java .NET wirklich ebenbürtig ist. Aus rein technischer Sicht ist .NET eigentlich sogar die mächtigere Plattform. Du kannst sogar Low-Level Sprachen wie C nach IL kompilieren (mit allem drum und drann, Pointerarithmetik, Funktionszeigern, usw.).
In Java geht das nicht so einfach, da Programmiersprachenunabhängigkeit kein sehr großes Thema im Javaumfeld war.

Allerdings muss ich auch einige Dinge bei .NET kritisieren. Ich glaube die größen Probleme lauern im Design der Klassenbibliotheken. Ich persönlich halte z.B. die Collectionklassen für nicht sehr gut gelungen (Inkonsistente Bezeichnungen, zu wenig Funktionalität, ...)

Ich würde frickeln einfach als "pseudokompetentes Gebastel" übersetzen 😉
Also passt tinker glaube ich schon ganz gut (auch als Verb wie herbivore schon sagt).
to tinker with something -> an etwas herumbasteln/herumfrickeln.

Also mir ist das Wort Tinker geläufig. Man könnte as frei als Bastler, Pfuscher oder auch als Frickler übersetzen 😉

Genau genommen ist ein DWORD sogar ein uint 😉

Auch solltest du ein Flag nicht einfach als String übergeben. Das wird Brühe. Du muss die genaue Flag-Definition schon aus dem BASS Header nehmen und auf C# umschreiben.

Schon mal daran gedacht, dass string und DWORD nicht kompatiblel sind?

Hi,
wär schon wenn du die Fehlermeldung etwas genauer beschreiben könntest.
Grundsätzlich funktionieren .NET Anwendungen unabhängig davon wo sie entwickelt wurden. Ob VS oder #D ist egal, da beide auf der exakt gleichen Technologie aufbauen.

Ein Problem von ndoc ist allerdings, dass die Entwicklung eingestellt wurde. Sehr schade wie ich finde. Jemand hat versucht das Projekt weiter zu führen:
http://sourceforge.net/projects/ndoc05
Alternativ kannst du auch Doxygen benutzen. Akzeptiert inzwischen auch C# Dokumentationstags (Wenn auch nicht vollständig).

Für GTK Anwendungen wir meist Glade verwendet um die Gui zu basteln. Wenn du das GTK SDK installiert hast, dann sollte das Programm eigentlich mit dabei sein. Bei GTK werden Benutzeroberflächen mit Hilfe von Xml beschrieben.
Hier gibt's ne nette Demo wie man mit Glade Gui-Anwendungen baut und mit C# verknüpft: http://nat.org/demos/gtksharp.html

C++ Klassen kann man am besten damit wrappen:
http://www.swig.org/

@ikaros
Nein, geht nicht. Siehe mein Post oben.

http://ankhsvn.tigris.org/

@svenson
Ich glaube du liegst da ein bissl falsch. Der Dateisystem-Treiber sorgt dafür, dass nach einem FILE_MOVE Kommando per DeviceIoControl, das Dateisystem immer in einem konsistenten Zustand bleibt. Schließlich werden nur Cluster verschoben und die Verküpfungsinformationen werden dabei automatisch angepasst.
Hier ein interessanter Artikel dazu (Nutzt die Nt-API direkt):
http://www.rheumanet.org/Uploads/content/m1/k2/k21/doc/20204120.pdf

Es dürfte also relativ einfach sein eigene Defrag-Tools zu schreiben. Zumindest wünsche ich ec-hasslau.de viel Erfolg dabei 😉

Leider nicht jede Version. Baumbert würde wohl kaum fragen, wenn sein VS dieses Feature unterstützen würde 😉

Ein Debug.Assert() wird wohl kaum testgetriebene Entwicklung ersetzen können 😉
Schau mal im Netz nach csUnit. Sollte VS 2005 Unterstützung haben.

Hier hat jemand schon mal was dazu gemacht:
http://www.codeproject.com/csharp/edix.asp
Vielleicht ganz nützlich.

Vil ist ebenfalls ein Tool um Sourcecode zu analysieren. Es beinhaltet fast alle wichtigen Code-Metriken (LOC, abstractness, instability, cyclomatic complexity). Allerdings läuft Vil nicht auf Source-Ebene, sondern arbeitet direkt mit IL-Code:
http://www.1bot.com/

Für die SortedList implementiert man am besten ein IComparer oder IComparable Interface. Und warum kaskadierst du die if-Bedingungen in der Vergleichsmethode nicht? Das sollte IMHO besser gehen:

public int CompareTo(myType other)
{
    if (this.val1 < other.val1)
        return -1;
    else if (this.val1 > other.val1)
        return 1;
    else
        if (this.val2 < other.val2)
            return -1;
        else if (this.val2 > other.val2)
            return 1;
        else
           // ... für alle Werte bis val5 
              if (this.val5 < other.val5)
                  return -1;
              else  if (this.val5 > other.val5)
                  return 1;
              else
                  return 0; // alle sind gleich

        }

Ich selbst nutze auch SharpDevelop. Eigentlich bin ich sehr zufrieden mit der IDE.
Schön ist die Integration von Boo, NUnit und das Refactoring. Die nächste Version (2.1) soll auch FxCop und Subversion unterstützen.
Allerdings gibt's auch einige eklatante Schwächen. Am meisten stört mich ein Memory-Leak, dass bei häufigem Layoutwechsel im Debug-Modus auftritt. Dabei werden mehrere hundert Megabyte virtueller Speicher belegt und ein Geisterprozess bleibt übrig, den man nur im Taskmanager abschießen kann. Hoffe mal die Jungs bekommen das noch in den Griff.
Aber trotzdem. #D ist zur Zeit eine der besten freien IDEs die man überhaupt bekommen kann.

Jep, würde sagen das ist ein Port. Laut den Konventionen für URLs werden Ports am Ende mit einem Doppelpunkt abgegrenzt. Macht man ja beispielsweise bei http auch so, wenn man keinen Standardport verwendet
Was ein Reflector im Sinne von LiveStreams ist, kann ich dir aber leider auch nicht sagen 😉

Zufälligerweise hab ich mich heute auch damit beschäftigt, wie man eigene Snapins bastelt und in die PowerShell integriert. Der installutil Aufruf und die zusätzlichen Snapin-Registrierung ist aber leider etwas fummelig. (Cmdlets muss man aber nicht unbedingt in C# schreiben, dass geht auch mit der Shell selbst.)

Insgesammt ist die PS aber ne geniale Sache. Objektorientierte Pipelines sind ein klarer Fortschritt gegenüber alten Zeichenkettenströmen. Will man spezielle Informationen aus der Pipeline eines anderen Programms lesen, so musste man früher erst mit awk, grep und Co. den Stream durchsuchen. Durch die Objektorientierung bekommt man auch gleichzeitig die "Semantik" des Datenstroms mitgeliefert.

Aber nicht nur die Pipeline ist Objektorientiert, sondern auch die Shell-Variablen werden auf die Typen des .NET Frameworks abgebildet. Wenn man beispielsweise folgendes eintippt:

 PS> $hallo = "Ich bin ein String."
 PS> $hallo | get-member | %{"{0,20} : {1,-20}" -f $_.name $_.membertype.tostring()}

bekommt man die internen Member der String-Klasse zurück. (Man beachte auch den Format-Syntax, der identsch zu Console.WriteLine() ist)

Mal sehen, wie das Ganze in Zukunft angenommen wird, denn die Shell ist nicht nur wesentlich mächtiger als die alte cmd.exe, sondern auch deutlich komplexer geworden. Eine gewisse Einarbeitungszeit ist also notwendig.
Fazit: Wieder ein schönes, neues und nützliches Spielzeug für Admins und Programmierer 🙂

Hier gibt's ne USB-Bibliothek für .NET:
http://www.icsharpcode.net/opensource/sharpusblib/

Original von Robert G
WiX ist ziemlich nett und sehr mächtig. 🙂
btw: Schonmal was von WiX-Vorlagen gehört? 😁

Mag sein. Mir ist Wix aber teilweise zu "over-engineered".

Die basieren aber nicht auf MSI.

Ist mir klar. Er hat aber auch nicht expliziet eine MSI Lösung gewünscht 😉

Mir ist noch kein Non-MSI-Installer unter die Augen gekommen, der sich selbst mit einem popeligen, StiNo VS-Setup messen könnte...

Mich würde mal interessieren was ein "StiNo-Klick-und-Weg-Installer" aus VS so viel besser macht als InnoSetup oder NSIS. Behaupte mal, dass man für über 90% aller Installationszenarien mit Non-MSI Lösungen sehr gute Installationen durchführen kann. Außerdem fährt MS - was Deployment angeht - teilweise auch selbst recht chaotische Wege. Wie oft da schon etwas "Neues" erfunden wurde ... Setup-API, Lz-API, MSI mit Wix, VB-Setups, Click-Once, ClickThrough, XCopy-Deployment ...
Die Hälfte von dem Krempel hat sich selbst überholt oder nur als Buzzword in der Marketingabteilung existiert 😉

@Koskas: Nimm das, was deinen Anforderungen am besten enspricht oder das, was man von dir verlangt - aus welchen Grüden auch immer. Es gibt viel Möglichkeiten Software zu installieren. Musst halt das Optimum zwischen Kosten, Aufwand und Ergebnissen finden und überdies gibt es Wichtigeres als an Installern zu frickeln 😉

Wenn dir das pure Wix zu fummelig ist, dann gibt es auch einen Editor für Wix-Files http://wixedit.sourceforge.net/.
Ansonsten InnoSetup oder NSIS. Wurde im Forum aber schon 1000 mal genannt 😉

Du könntest auch einen komplett neuen Appender schreiben, der einfach prüft, ob das Netzwerk down ist oder nicht und dann selektiv wählt in welchen Appender geschrieben wird. Der Vorteil ist, dass du deinen bisherigen Code praktisch nicht ändern musst. IMHO der kompfortabelste Weg.
Im Pseudo-Code (nicht log4net konform):

public class SelectiveUDPOrFileAppender : Appender
{
  UDPAppender udpAppender;
  FileAppender fileAppender;

  public override void Write(string str)
  {
    if(NetworkAvailable)
      udpAppender.Write(str);
    else
      fileAppender.Write(str);
  }
  ...
  private bool NetwortAvailable {...}
}

@herbivore
*lach*
MyCSharp tries to take over the google index 😉
Herbi for president!

Das du da nichts gefunden hast?

Es gibt dort Links auf Vergleiche von Boo, Ruby, C#, VB:
http://www.cse.iitb.ac.in/~kart/writings/Ruby%20vs.%20Boo%20(long).html
http://boo.codehaus.org/Part+01+-+Starting+Out#Part01-StartingOut-ComparingcodebetweenBoo%2CC%23%2CandVB.NET
http://docs.codehaus.org/display/BOO/Differences+with+Csharp
http://boo.codehaus.org/Gotchas+for+Python+Users
http://boo.codehaus.org/Differences+with+Csharp

Sogar Benchmarks gibt es:
http://docs.codehaus.org/display/BOO/Boo+benchmarks

Meinungen:
http://www.atug.com/andypatterns/boo.htm
http://stevedonovan.blogspot.com/2005/05/boo-programming-language.html

Oder einfach kurz das Boo-Wiki
http://docs.codehaus.org/pages/listpages-dirview.action?key=BOO

Ich versteh einfach nicht was du noch wissen willst. Auf der Boo HP findest du eigentlich fast alles 😉

Original von e86
Hat jemand noch gute Links zu Infos von Boo ?

Hi wie wärs mit der Homepage von Boo selbst 😉http://boo.codehaus.org/
Da gibts Tutorials und Beispiele. Wie oben schon gesagt ist Boo in #Dev 2.0 integriert.

Einige kennen diesen Stream vielleicht schon (Achtung, läuft fast eine Stunde):

http://chaosradio.ccc.de/cre022.html

Ungewöhnlich ist, dass MS, Windows und .NET bei dieser Folge ungewöhlich gut wegkommen (Wenn man bedenkt, welche Kommentare beim CCC sonst über Microsoft zu hören sind). Dort wird MS sogar mal ausdrücklich gelobt für die Fortschritte, die sie im Bereich Sicherheit, Compilertechnologien, .NET usw. machen.
Gerade viele Linux-Fans dürften die Folge mit viel Unzufriedenheit aufgenommen haben, da diesmal nicht das übliche Feindbild beschworen wurde. Auch die Entwicklung des Linux-Kernels hat FX kritisiert.

Ob die Bemühungen von MS wirklich etwas bringen werden, wird man natürlich erst mit dem Release von Vista erfahren.

Was meint ihr?

@nop
Hallo!? Bist du mit dem falschen Bein aufgestanden?
Habe Tao selbst in der Benutzung und kann mich nicht beschweren. Alle Assemblies sind vorkompiliert und problemlos nutzbar. Auch für Anfänger interessant, da die auf C# portierten Redbook Beispiele mit drinn sind und einen guten Startpunkt für eigene Erweiterungen/Experimente bieten. Also irgendwie versteh ich dich nicht ganz, denn meist bin ich mit diesem ganzen "Linux-Inzest-l33t-Hacker-Frickelscheiß" ganz gut gefahren 😁

Eventuell glBlendFunc nicht gesetzt?

http://wiki.delphigl.com/index.php/GlBlendFunc

PS: Ich hab's glaube ich schon mal in nem anderem Thread geschrieben: Die Tao-Lib ist zur Zeit ein viel aktueller als CSGL. Und überdies sind sehr viele Beispiele und Tutorials mit enthalten.

CSGL wird doch schon lange nicht mehr weiterentwickelt. Die Wrapper von Tao sind doch viel aktueller und noch dazu 100% CLS kompatibel.

Mit Hackers konnte ich nie viel anfangen. Zu überspitzt und überdreht. 23 hat mir mehr gefallen, da der Film einen realen Bezug hatte. Ein absoluter Kultfilm im Sci-Fi Genre -obwohl eigentlich kein richtiger "Computerfilm"- ist natürlich 2001. Die Szene mit den Affen und der Musik "Also sprach Zarathustra" haben Kinogeschichte geschrieben.
Ein weiterer Film den ich gut finde ist Existenz. Hier wurde die Grundidee von Matrix in eine ziemlich surrealistische Mischung aus Fiktion und Realität gebracht. Auch Dark Star ist genial. Am Ende des Films haben die Astronauten ein philosophisches Gespräch mit einer "intelligenten" Bombe. Kennt den Jemand?

Original von herbivore
Hallo maxE,

so hat halt jeder seinen Background und seine Erfahrungen. Ich hoffe du bist mir nicht böse, wenn ich sage, dass sich in dieser Beziehung meine Erfahrungen vermutlich eher verallgemeinern lassen als deine.

herbivore

Wie schon gesagt: Jeder hat seinen Background und außerdem kommt es auf den Anwendungsfall an. Für viele Anwendungen sind solche Überlegungen ausreichen, da die Performance meist nicht so eine große Rolle spielt. Ich hätte es wahrscheinlich oft auch so gemacht wie du, aber ich kenne Situationen bei denen es manchmal sehr sinnvoll ist über Reflection zu gehen und den Overhead einer Hashtabelle zu meiden ...
Na ja, lassen wir's gut sein 😉

Kleiner Nachtrag:
Auf http://www.mono-project.com/Tao findest du Bindings für OpenGL. Im Paket sind auch viele C#-Beispiele und Tutorials als Quellcode (Verzeichnis NeHe).

Original von herbivore
Ein Hash-Zugriff ist heutzutage in der Regel schnell genug. Ich habe eine komplette Lastschrift-Anwendung geschrieben, bei der für jeden Property-Zugriff nicht nur auf mehrere Hashtables zugegriffen wurde, sondern noch diverse Prüfungen durchgeführt wurden, teilweise inkl. Substring-Operationen auf den Attributnamen. Keinerlei Performace-Probleme.

Sicher, für die Lastschriftanwendung ist das OK. Für die Anwendungen an den ich mitgearbeitet habe ist das aber nicht sehr praktikabel. Auf Variablen/Properties - anfänglich einmal über Refl. initialisiert - muss hier mehrere tausend mal pro Sekunde zugegriffen werden. Da sind mir "normale" Variablen/Properties, lieber als Hashtabellen, die als Variablencontainer fungieren 😉

@herbivore:
Es gibt schon Situationen, wo sowas sinnvoll ist. Bei Plug-ins z.B. gibt es meist immer nur eine feste Schnittstelle mit genau definierten Funktionen. Soll das Plug-in noch über weitere Eigenschaften verfügen, die in der Schnittstelle nicht definiert sind, dann kommt man um Reflection kaum rum.
Du wolltest hier ein Dictionary/Hash vorschlagen aber das ist manchmal aus Performance-Gründen nicht sinnvoll, weil direkter Variablenzugriff im Code schneller ist:

int i = (int)hash["myVar"];
 vs.
int i = myVar; 

Voraussetzung ist natürlich, dass das Property sehr selten aufgerufen wird, dafür aber die interne Variable, die dem Property zugeordnet ist, sehr intensiv.

Auf nehe.gamedev.net im Lessonsbereich gibt es schon viele C#-Portierungen. Aber ob du nun mit C++ oder C# programmierst ist doch bei OpenGL egal, da die Funktionen überall gleich sind.

Also für große Welten, wird Occlusion Culling auf der Grafikhardware immer populärer. Heutige Grafikkarten unterstützen Occulusion Queries nativ. Damit kann man recht einfach und hardwarebeschleunigt testen, welche Geometrie man sehen kann und welche nicht. Das ganze funktioniert grob so:
Du erzeugst zuerst eine sehr einfache geometrische Repräsentation deiner Welt (Bäume, Häuser, Felsen, usw. ... werden als Bounding Boxes angenähert).
Jetzt aktivierst die Occulusion Queries und renderst diese Bounding Boxes in eine nicht sichtbare Surface. Natürlich stark verkleinert (320*200) und mit deaktiviertem Shading, also keine Lichter, Texturen, Blending oder sonst was.
Dann zeichnest du alle "richtigen" Objekte, die in deinem Occulusion Querie stehen in das VRAM, fertig. Natürlich lässt sich die Sache noch stark erweitern: LOD Meshes usw...

Königsklasse? Na ja.
Im DirectX SDK ist ein Beispiel für ein einfaches Partikelsystem. Direct3D unterstützt hierfür auch Point Sprites (siehe http://www.riaz.de/tutorials/d3d17/d3d17.html). Ansonsten ist die Programmierung solcher Systeme eigentlich recht einfach. Du nimmst einfach ein Array von Partikelstrukturen, die beispielsweise folgende Felder enthalten:*Lebenszeit (wird bei jedem Frame dekrementiert, bei 0 hört das Partikel auf zu existieren) *Start- und Endfarbe mit Alphakanal (Interpoliert über die Zeit) *Geschwindigkeit (wird bei jedem Frame - mit der Zeitdifferenz pro Bildaufbau skaliert - auf die Position addiert) *Position

• usw ...

Um das Ganze etwas zu abstrahieren, könntest du noch Klassen für verschiedene Emitter (Regen, Feuer, Rauch, ...) und Manipulatoren schreiben (Wind, Attraktion, Gravitation, Wirbelsturm, ...).
Eigentlich sooo nicht schwer 😉

Die meisten neuen APIs sind .NET basierend. Siehe WPF, WCF usw ...

@herbivore

Ja, du hast recht. Ein String kann man nicht direkt verändern, sondern sich nur eine modifizierte Kopie zurückgeben lassen. Mit verändern hab ich eigentlich auch mehr das Neuzuweisen von Strings gemeint (Im Sinne von: s = s + "xyz").
Hier was zum String-Pool den .NET verwaltet: http://www.yoda.arachsys.com/csharp/strings.html (Abschnitt Interning)
Mehrere Strings mit gleichem Inhalt werden zur Compilezeit nur einmal gespeichert und als "intern" markiert. Mit String.Intern()/IsInterned() kann man überprüfen ob ein zur Laufzeit erzeugtes String schon in diesem String-Pool vermerkt ist.

Strings werden in C#/.NET auch besonders behandelt (mal unabhängig davon ob Wert- oder Referenztyp).
.NET führt intern eine Art globalen Pool für Strings. Hast du mehrere Strings mit dem gleichen Inhalt, dann werden sie nicht mehrfach gespeichert, sondern es zeigt ein interner Verweis auf die gemeinsame Zeichenkette. Veränderst du dein String, dann wird geprüft ob sich dieses ebenfalls noch im Pool befindet. Wenn nicht, wird erst eine echte Kopie mit neuem Verweis im Pool erzeugt.

Hier ist foo statisch. Man könnte natürlich foo zu einer Instanzmethode machen und dann die abstrakten Methoden aus der Basisklasse implementieren. Allerdings wird so etwas in bestimmten Softwarearchitekturen nicht unbedingt gern gesehen. Siehe Vistitor-Pattern. Die Idee ist hier, dass du Daten auf der einen Seite und Operationen auf der anderen Seite hast. Möchtest du eine neue Operation auf diese Daten definieren, dann schreibst du dir einfach einen neuen Visitor (Die Klassen, die deine Daten repräsentieren müssen nicht verändert werden). Eigentlich genau so, wie man es von einem gutem Softwareentwurf erwarten. Wenn du jetzt aber die foo-Methoden als Instanzmethoden definierst, dann hast du diese Trennung nicht mehr.
Schönes Beispiel zu diesem Thema und warum Multimethoden dieses Pattern so vereinfachen: http://nice.sourceforge.net/visitor.html

Funktionsüberladung geht heute schon, hat aber erst mal nichts mit Multimethoden zu tun. Das besondere ist hier, dass d0, d1, d2 auf ihre Basisklasse geboxt wurden. Rufst du foo() auf, dann wird natürlich nur foo(Base c) aufgerufen. Bei Multimethoden wird aber zusätzlich der eigentliche Typ erkannt. D1 und d2 sind nämlich vom Typ Derived1 und Derived2 und werden bei Multimethoden automatisch (zur Laufzeit) an die richtige Methode delegiert.

Multimethoden sind Methoden die den gleichen Namen aber unterschiedliche Parameter haben, welche von einem gemeinsamen Basistyp abgeleitet wurden.

class Base
{...}

class Derived1 : Base
{...}

class Derived2 : Base
{...}

...
// Multimethoden

foo(Base c)
{...}

foo(Derived1 c)
{...}

foo(Derived2 c)
{...}

// Instanzierung
Base d0 = new Base();
Base d1 = new Derived1();
Base d2 = new Derived2();

// Aufruf ohne Multimethoden
foo(d0); // ruft foo(Base c) auf
foo(d1); // ruft foo(Base c) auf
foo(d2); // ruft foo(Base c) auf

// Aufruf mit Multimethoden
foo(d0); // ruft foo(Base c) auf
foo(d1); // ruft foo(Derived1 c) auf
foo(d2); // ruft foo(Derived2 c) auf

Multimethoden bestimmen also dynamisch welchen Typ die Methodensignatur hat und ruft dann passen die Methode auf. Damit kann man das Visitor Pattern stark vereinfachen.

Ich finde die Erweiterungen eigentlich ziemlich gut. Über Unausgereiftheit würde ich mir weniger Sorgen machen, denn ähnliche Sprachfeatures gibt es schon in anderen Programmiersprachen. Die Iteratoren und die Lambda-Methoden sind ja doch sehr an Python angelehnt.

Auch kann ich mich dem Eisbären anschließen, wenn er sagt, dass es bei C# oft noch an ganz anderen Stellen zwickt. Ich würde hier aber andere Beispiele nennen:

Operatorenüberladung mit generischen Datentypen. Bis heute sind solche Konstrukte in C# ungültig, dass wird sich wohl leider auch mit C# 3.0 nicht ändern:

T x, y, z;
...
public static Vector3<T> operator+(Vector3<T> l, Vector3<T> r)
{
    return new Vector3<T>(l.x+r.x,l.y+r.y,l.z+r.z);
}

Außerdem fände ich eine Erweiterung um Multimethoden sinnvoll. Das könnte z.B. das Visitor Pattern überflüssig machen.

Also ich hab vor einiger Zeit mit wx.NET rumgespielt. Das Toolkit gefällt mir sehr gut und ist recht robust. Wenn dir die C# Dokumentation nicht reicht, dann kannst du dir auch die größtenteils äquivalente C++ Doku anschauen.

Gtk# ist eigentlich ganz nett (vorallem wegen Glade) aber ich finde die Mono Dokumentation sehr lückenhaft. Außerdem muss du die Gtk# Runtime (kann bei Novell für Windows runtergeladen werden) auf dem Zielrechner installieren.

Und Winforms ist so ne Sache. Ich habe die Erfahrung gemacht, dass WinForms Anwendung auf Linux oft etwas fehlerhaft angezeigt werden. Da hilft eigentlich nur regelmäßiges Testen auf beiden Plattformen und eventuelle Anpassungen.