[Celion]

Zitat von haze303

Ich finde, man kann den Satz "C# - eine Weiterentwicklung von C und C++ - ist typsicher und objektorientiert" schon so stehen lassen.

C# hat einen Großteil seines Stils bzw. Aufbau von C/C++ und im direkten Vergleich mit dem C#-Unsafe-Code Verfahren, ist C# nur rund 20% langsamer (direkter Vergleich aus einem Benchmarking - leider finde ich im Moment den Link nicht mehr) als C/C++, was für eine objektorientierte Sprache _verdammt_ gut ist.

Das mit dem 20% langsamer habe ich auch irgendwie gelesen, wobei ich denke das ein gescheiter C# - Programmierer schon einiges aus seinem Programm rausholen kann.

Was den Verwandtschaftsgrad angeht so finde ich (und ich denke mich kann man nicht wirklich überzeugen ) das C# mit Java mehr gemein hat als mit C/C++ und da Java natürlich auch einige Beinflussungen von Seiten C++ hat gibt es eine Ähnlichkeit zwischen C# und C++ aber zu sagen das C# in der selben Linie steht wie C und C++ (wobei C++ auch kein "weiterentwickeltes" C ist sondern aus C hervorgegangen) finde ich ein bisschen weithergeholt.

Zitat von haze303

Alles in Allem ist C# eine innovative Sprache, die sehr leicht zu erlernen ist, Spass macht und unglaublich Usability- bzw. Leistungsorientiert arbeitet.

Ich bin momentan auch dabei, diese Sprache zu erlernen, um mir meinen Alltag als Administrator zu erleichtern.
C# bietet alle Möglichkeiten, die auch eine S*****sprache, wie VBS***** beinhaltet.
Jetzt denkt der Ein oder Andere bestimmt - ja klar, wäre ja auch traurig, wenn eine Hochsprache nicht mächtiger als eine S*****sprache wäre.
D.h. schnell und unkomplizierte Lösungen entwickeln, welche an diverse Schnittstellen gebunden sind, wie z.B. WMI-Abfragen, ADSI etc. pp.

Natürlich, jeder muss eine Programmiersprache finden in dem er sich wohl fühlt und die ihm auch Spaß macht und da ist C# von deinen Anfoderungen optimal - wobei VB6 (ja ich hasse VB.NET) auch dafür geeignet wäre (bin anscheinend ein Oldie)

Zitat von haze303

Diese Dinge kann man leider nicht via C/C++ in diesem Tempo bzw in dieser Leichtigkeit lösen, wie es mit C# möglich ist.

Nun in diesem Tempo ist es nicht lösbar, allerdings kann man wenn man sich in C++ auskennt eigene Klassen einrichten und diese dann bei späteren ähnlichen Problemen benutzen.

Zitat von Schank

Ähnliche Probleme besitzen ähnliche Lösungen

Zitat von haze303

Jeder muss "seine" Sprache für seinen Anwendungsbereich finden. Wer Treiber entwickelen möchte bzw. sehr "Hardwarenah", sollte doch lieber zu C/C++ greifen. ;-)

Nicht nur für Treiber bzw. Hardwarenahe Programmierung ist C/C++ geeignet. Wenn man sauber programmiert kann der selbe SourceCode theoretisch auf jeden System kompiliert werden. C/C++ ist bis jetzt noch so ziemlich die schnellste Programmiersprache und optimal für Programme die im Hintergrund laufen bzw. eine maximale Leistung benötigen (z.B hardwareaufwendige Spiele).

[haze303]

Zitat von Celion

Was den Verwandtschaftsgrad angeht so finde ich (und ich denke mich kann man nicht wirklich überzeugen ) das C# mit Java mehr gemein hat als mit C/C++ und da Java natürlich auch einige Beinflussungen von Seiten C++ hat gibt es eine Ähnlichkeit zwischen C# und C++ aber zu sagen das C# in der selben Linie steht wie C und C++ (wobei C++ auch kein "weiterentwickeltes" C ist sondern aus C hervorgegangen) finde ich ein bisschen weithergeholt.

Ich gebe dir Recht und möchte keineswegs behaupten, dass C# mit C/C++ gleich zu stellen wäre, denn das wäre schlichtweg falsch. (Meiner Meinung nach.)
C# bedient sich nur mit einen ordentlichen Schluck vom Stil und Kleinigkeiten in der Herangehensweise von C/C++.
Noch einen Esslöffel Java dazu + eine große Brise .NET und fertig ist der mächtige Hybride.

Letztendlich darf man nie vergessen, das sich jede moderne bzw. "aktuelle" Hochsprache aus Elementen vergangener Sprachen bedient hat.
Dagegen ist von meiner Seite aus nichts einzuwenden - warum sollte man das Rad neu erfinden, wenn man ein bereits fundiertes und für gut befundenes System in Neues eingliedern kann.

Den einzigen Nachteil, den ich bei C# sehe, ist die Unflexibilität ihrer Portabilität auf "fremde" Umgebungen/Betriebssysteme.
Klar, es ist teilweise möglich, aber leider nur mit gewissen Einschränkungen und teilweise unorthodoxen Methoden.