Laden...

Vorteile und Nachteile von C#/.NET

Erstellt von wpb vor 17 Jahren Letzter Beitrag vor 17 Jahren 31.553 Views
W
wpb Themenstarter:in
117 Beiträge seit 2005
vor 17 Jahren
Vorteile und Nachteile von C#/.NET

hy leute!

wo liegen eigentlich die konkreten vorteile und nachteile von c#
gegenüber anderen sprache wie z.B-: delphi, c++, pascal...

Danke schon mal....

1.373 Beiträge seit 2004
vor 17 Jahren

Schwierige Frage, vergleichbar mit: "Was sind eigentlich die Vor- und Nachteile eines Hammers gegenüber einer Säge?". Entscheidend ist, für welchen Zweck das ganze verwendet werden soll. Erst nachdem das feststeht, sollte die dafür passende Sprache verwendet werden. Und auch dann lassen sich Vergleiche ziehen. Denn was in Situation a vorteilhaft ist kann in Situation b schon wieder unerwünscht sein, beispielsweise die nichtdeterministische Speicherfreigabe durch den Garbage Collector.

Versuche die Frage konkreter zu stellen.

Grüße,
Andre

4.207 Beiträge seit 2003
vor 17 Jahren

Als Vorteile von C# gegenüber C++ / Java sehe ich unter anderem:

  • Keine Pointer
  • Durchgehend objektorientiert

Als Nachteile:

  • string wird wie ein value-Typ behandelt
  • Zu viel Compiler-"Magic"

Eigenschaften finde ich sehr zweischneidig, da sie einerseits den Komfort erhöhen, andererseits die Explizität des Codes mindern.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

369 Beiträge seit 2006
vor 17 Jahren

Ich bin selber kein JAVA-Experte, aber C++ / Java kannst du nicht so unter einen Haufen kehren, da afaik folgendes zutrifft:

-> In Java ebenfalls keine Pointer möglich - und zwar grundsätzlich (in C# gibt es ja noch die unsafe-Bereiche)
-> Java ist ebenfalls durchgehend Objektorientiert

Ansonsten trifft auf jeden Fall eine unglaubliche Ähnlichkeit zwischen C# und Java zu. Im Zweifelsfall würde ich persönlich C# bzw. .net den Vorzug geben, Java ist aber ebenfalls nicht grunsätzlich zu verschähen - insbesondere wenn es um Platformübergreifende Anwendungen geht. Der Rest sind dann weitestgehend Details, so hat jede Platform seine Vor- und Nachteile welche man je nach Anwendungsgebiet abwägen muss - an der Java-Syntax gefällt mir besonders, dass man die möglicherweise auftretenden Exceptions bei der Klassendeklaration mit angeben muss, ist aber ebenfalls wieder so ein Detail.

C++ würde ich heute nur noch in Ausnahmefällen Einsetzen, so ist diese Sprache zwar sehr mächtig, erleichtert aber weiterhin eher dem Compilerbauer, als dem Programmierer das leben. Darüberhinaus lässt sich damit sehr viel sch*** bauen, was mit C# / .Net, aber auch Java prinzipbedingt nicht möglich ist. Manchmal muss man sich selber eben sein Glück aufzwingen, indem man riskante Operationen untersagt (bzw. diese mit unsafe kennzeichnet) und dafür mit unter auf etwas Performance verzichtet (aber auf heutigen Maschinen nicht der Rede wert). Dieser Aspekt ist von großer Bedeutung, da sich auf diese Weise mögliche Fehlerquellen von Grund auf verbieten und die Fehlersuche erheblich erleichtern (à propos: Auch mit Delphi lässt sich viel Mist bauen!).

Der standardmäßig vorhandene Garbage Collector ist ein weiteres Plus einer Umgebung wie .Net und Java.

4.207 Beiträge seit 2003
vor 17 Jahren

Dass es in Java keine Pointer gibt, ist mir auch klar, das war evtl ein wenig unglücklich formuliert.

Java ist nicht durchgängig objektorientiert ... Das Literal 5 ist im Gegensatz zu einer 5 in C# zum Beispiel kein Objekt, sondern Du musst, wenn, dann eine entsprechende Instanz von Int anlegen.

Eine Sprache an sich ist nie plattformübergreifend. Jede Sprache lässt sich auf jeder Plattform umsetzen. Die Frage ist, wo es die Runtime gibt. Dies mag spitzfindig sein, aber es ist nicht die => Sprache ≤, welche die Zielplattform bestimmt.

Der Garbage Collector ist kein Feature der Sprache, sondern der Runtime.

Was die Exceptions in Java angeht, das sehe ich genau so.

Übrigens, ist off-topic, aber dass Performanceunterschiede auf Grund bestimmter Sprach- oder Plattformkonstrukte heutzutage keine Rolle mehr spielen würde, ist schlichtweg Quatsch.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

P
157 Beiträge seit 2006
vor 17 Jahren

Vorteile, Nachteile.. ich denke das jede Sprache je nach Kontext die richtige Wahl sein kann, da kann man nicht so pauschal sagen die eine ist besser oder schlechter.

Etwas nachteiliges von .NET gegenüber Java wäre für mich (ein rein subjektiver Geschmack) vielleicht das es nicht so konsequent Plattformunabhängig ist wie eben Java.
Mono unter Linux ist nunmal nicht dasselbe(leider) wie das .NET-SDK unter Windows. Da finde ich persönlich den Ansatz von Sun doch wesentlich konsequenter und homogener indem sie ein Framework gleichberechtigt für ganz verschiedene Systeme anbieten.

369 Beiträge seit 2006
vor 17 Jahren

_Original von Golo Haas_Übrigens, ist off-topic, aber dass Performanceunterschiede auf Grund bestimmter Sprach- oder Plattformkonstrukte heutzutage keine Rolle mehr spielen würde, ist schlichtweg Quatsch.

Es war von mir evtl. etwas zu pauschalisierend ausgedrückt, aber in vielen Anwendungsgebieten ist das tatsächlich so - wenngleich es natürlich weiterhin nicht zu verleugnende Bereiche gibt, in denen jedes Quäntchen Performance zählt. Wichtiger ist in vielen Fällen aber sowieso die Entwicklungszeit, welche man durch die Bevorzugung von C# / Java teils merklich drücken kann.

[Vermutung] Ich bin jedoch auch der Meinung, dass man bei kleinen Projekten mit .Net bzw. C# sogar die bessere Performance erreichen kann, da man häufig auf vorgefertigte Klassen des Frameworks zurückgreifen kann, welche hoffentlich so gut wie nur möglich optimiert wurden. [/Vermutung]

PS: In meinem letzten Beitrag habe ich in der Tat die Elemente Sprache, Runtime und Framework vermengt, was aber durchaus absicht war, da man sich i.d.R. mit der Wahl der Sprache auch auf eine bestimmte Runtime... festlegt.

N
4.644 Beiträge seit 2004
vor 17 Jahren

Original von purplestar
Etwas nachteiliges von .NET gegenüber Java wäre für mich (ein rein subjektiver Geschmack) vielleicht das es nicht so konsequent Plattformunabhängig ist wie eben Java.

Beide brauchen doch eine Runtime für die OS. Somit sind Java und .NET selbst die Plattform.

P
157 Beiträge seit 2006
vor 17 Jahren

Original von Noodles

Original von purplestar
Etwas nachteiliges von .NET gegenüber Java wäre für mich (ein rein subjektiver Geschmack) vielleicht das es nicht so konsequent Plattformunabhängig ist wie eben Java.

Beide brauchen doch eine Runtime für die OS. Somit sind Java und .NET selbst die Plattform.

Ok, vielleicht habe ich mich nicht ganz treffend geäußert.
Natürlich sind beide, .NET wie auch Java, selbst die Plattform(in Form der Runtime). Für mich liegt der Vorteil über die Bereitstellung dieser Plattform, für alle Systeme bleichberechtigt, ganz klar bei Sun mit Java. Anders als mit .NET ist man bei Java wirklich nicht an ein OS gebunden. Möchte man das umfangreiche .NET nutzen so muss man dies auf einem MS-System tun, wirkliche Plattformunabhängigkeit ist das nicht.

347 Beiträge seit 2006
vor 17 Jahren

Original von wpb
wo liegen eigentlich die konkreten vorteile und nachteile von c#
gegenüber anderen sprache wie z.B-: delphi, c++, pascal... Hmm...
Im Titel steht "vorteile nachteil von .NET", deine Frage ziehlt auf C# vs Delphi, Pascal und C++. Irgendwie macht das nicht wirklich viel Sinn. 🤔

Es gibt Versionen von C++, Delphi, und sogar mehrere Pascalderivate für .Net.

Falls du wirklich nur die Sprachen an sich meinst: Die Frage welche die "single best general purpose language ever (tm)" ist, wurde schon 5Mio-mal gestellt und 20Mio-mal mit "gibt's nicht" beantwortet.

C# wurde auf .Net abgestimmt, somit hat es da ein paar Vorteile gegen Legacy-sprachen wie Delphi oder C++.
Delphi oder C++ haben aber einige Sprach features zu .Net retten können, die nicht direkt auf der CLR/FCL aufbauen. C# bietet nur Vannila-.Net ohne irgendwelche Extras.
C++ oder Delphi lassen dich Funktionen exportieren, die von nativen Programmen verwendet werden können ohne den Umweg über COM gehen zu müssen.
C++ hat nicht nur Generics sondern auch Templates[1] außerdem kannst du damit nativen Code mit .Net Code in einem Binary mischen.
Delphi/Chrome besitzen MetaClasses, die dich einen Typen als ein Objekt verwenden lassen[2].

Sowohl Delphi als auch C++ haben einen gewissen Reiz was die Migrierung von nativen auf .Net Code angeht.
Selbst Chrome bietet Legacy switches um bestehenden Delphi code einfacher zu .Net zu migrieren, ist aber als Sprache wesentlich extremer auf .Net getrimmt als Delphi.Net.

C# steht eher für Wegschmeißen und von vorne anfangen.

C# wiederum steht immer an vorderster Front, was plattformbezogene und IDE-bezogene Features betrifft. Das ist ein nicht zu unterschätzender Punkt, IMHO.
Außerdem ist C# die Sprache, die jeder .Net dev zumindest lesen können sollte. Man hat also eine Art Esperanto um sich auszutauschen.

Ich selbst bin eher ein Pascal-Fan, weshalb ich wahrscheinlich eine andere Meinung zu solch esoterischen Frage habe, als ein alteingesessener Benutzer von MS-Tools. 😉

Ich schreibe auch den Großteil meines Codes in Chrome. Aber wenn absehbar ist, dass eine Classlib stark von anonymen Methoden profitieren wird, schreibe ich sie in C#. Auch was die IDE Features angeht ist man beim View-layer auch mit C# besser dran. (Wobei ich zum Glück wenig bis gar nichts mit GUI-Basteln zu tun habe 😉 )

Sprachpräferenz ist IMHO einfach eine Frage nach "the right tool for the right job".

[1]beide ähnlich aber doch grundverschieden 😉
[2]Nicht zu verwechseln mit System.Type, welcher nur RTTI zur Verfügung stellt

S
285 Beiträge seit 2005
vor 17 Jahren

Vorteile .NET:

In Bezug auf Codesicherheit und native Kompilierung ist .NET dem JAVA Environment überlegen. Kein Obfuscator, sondern tatsächliche native Kompilierung. Entweder mit standardmässigem .NET Framework Support oder fix eingebunden. Ich spreche hier auch von den Möglichkeiten.

Web Applikationen: Java Webtechnologien und PHP haben technisch nicht mehr die Nase vorn. ASP.NET ist mittlerweile mächtiger.

Nachteile:

Plattformunabhängigkeit. Mono ist auch nicht sehr zuverlässig.

Gegenüber C++ braucht man sowieso keine Vergleiche anstellen. Hier kommt es nur auf den Nutzen bzw. Anforderungen der gewünschten Applikation an.

4.207 Beiträge seit 2003
vor 17 Jahren

Sorry, wenn ich das jetzt so sage, aber das war gerade ziemlich oberflächlich.

In .NET wird nichts nativ kompiliert, sondern in MSIL übersetzt, was quasi dem Bytecode von Java entspricht. Klar, Du kannst ngen anführen, verlierst damit aber die Plattformunabhängigkeit, zudem ließe sich ein solches Tool mit Leichtigkeit ebenfalls für Java schreiben (ob es ein solches gibt, weiß ich nicht).

In Bezug auf Webtechnologien ... dann nenn doch mal ein paar konkrete Vorteile von ASP.NET gegenüber J2EE. Was heißt für Dich "die Nase vorn haben"? Beleg das doch bitte mal an Fakten, wo ASP.NET "mächtiger" ist ...

Inwiefern ist Mono unzuverlässig?

Und .NET mit C++ zu vergleichen, geht sowieso am Thema vorbei, denn entweder musst Du C# mit C++ vergleichen oder .NET mit C++ inklusive MFC, ATL, STL, ...

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

3.728 Beiträge seit 2005
vor 17 Jahren
Senf dazugeben

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.

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. Besonders in Sachen Win32-GUI, wird da oft auf Spezial-Frameworks zurückgegriffen. Auch die Artenvielfalt der Java-Anwendungserver und der Java Runtime (Jeder baut seine eigene Runtime) ist nicht unbedingt transparent. .NET ist natürlich auf der anderen Seite mit Windows verheiratet. Mono kann daran nicht wirklich was ändern, da es nicht direkt vom Hersteller kommt bzw. nicht aktiv von diesem Unterstützt wird. Es ist aber trotzdem super, dass es im Linux/Unix Umfeld eine technologie gibt, in der sich .NET Entwickler sofort zu Hause fühlen. Für Anwendungen, die wirklich auf verschiedenen Plattformen laufen müssen, ist dann doch eher Java am Zug.

Alles andere ist Geschmacksache!

M
456 Beiträge seit 2004
vor 17 Jahren

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, ...)

I am Jack's smirking revenge.
I am Jack's raging bile duct.
I am Jack's cold sweat.
I am Jack's complete lack of surprise.
I am Jack's broken heart.
I am Jack's wasted life.

3.728 Beiträge seit 2005
vor 17 Jahren

Original von maxE
Ich persönlich halte z.B. die Collectionklassen für nicht sehr gut gelungen (Inkonsistente Bezeichnungen, zu wenig Funktionalität, ...)

Das meine ich z.B. mit Geschmacksache.

347 Beiträge seit 2006
vor 17 Jahren

Original von maxE
Naja, wenn ich mir so einige SciMark Benchmarks ansehe, dann kommen mir schon Zweifel ob das nun ein unumstößlicher "Fakt" ist. Traue keiner Statistik, die du nicht selbst gefälscht hast. 😉
Stelle dir einfach die Fragen warum native Images von IL so riesengroß sind, und vor allem: Was in dem Zusatzcode hauptsächlich passiert.
"Fakt" ist, dass lokale Variablen initialisiert werden müssen, bevor das erste Statement einer Mothode ausgeführt wird.
"Fakt" ist, dass selbst die BCL mit XXXPermission-Attributen auf Klassenebene und darunter verseucht ist. Wenn man sich ein wenig mit CAS beschäftigt, weiß man, dass dadurch statische Sicherheitsanalysen beim JITting nicht reichen. Es werden also fleißig Prüfungen eingebaut, in denen alles Mögliche verpackt wird, sogar Feldzugriffe!

Ich sehe absolut keine Chance mit der CLR2.5 IL Code laufen zu lassen, der schneller als sein natives Gegentück läuft.

Ich denke es liegt vorallem an den Verwendeten Jit-Compilern und ihren Möglichkeiten Code zu optimieren. Dann reden wir aber nicht von .Net. 😉 So gerne ich auch in .Net entwickle, der .Net JIT ist einfach erbärmlich was Optimierungen angeht. MS hat es selbst bis heute noch nicht gebacken bekommen, dass er Fließkommaberechungen auch nur teilweise an die Hardware optimiert, von CPU-registern und 64-Bit-Optimierungen ganz zu schweigen...

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.). Das ist definitv ein Punkt! Die Java VM hat IMHO Pointer.
In Java geht das nicht so einfach, da Programmiersprachenunabhängigkeit kein sehr großes Thema im Javaumfeld war. Noch so eine urbane Legende, Java (die Sprache) war eigentlich nur als Übergangslösung gedacht bis dieanderen Compilerbauer ihre eigenen Copiler für die JavaVM gebaut haben. Die Sprache fand aber soviele Fans, dass es dazu nie wirklich gekommen ist.

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, ...) Die Benennung "List" für einen arraybasierten Container finde ich schlimmer als "nicht sehr gut gelungen". Die Funktionalität der Container ist nicht wirklich ein Problem, viel schlimmer finde ich diese ganzen internal Typen und methoden in der BCL. Wie oft muss man 100 Umwege gehen, nur weil man da nicht rankommt. (Ohne Reflectionberechtigungen).

btw: Das Killerfeature von .Net gegenüber Java dürfte CAS sein. 😉

M
456 Beiträge seit 2004
vor 17 Jahren

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 😉

I am Jack's smirking revenge.
I am Jack's raging bile duct.
I am Jack's cold sweat.
I am Jack's complete lack of surprise.
I am Jack's broken heart.
I am Jack's wasted life.

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo Robert G,

Die Benennung "List" für einen arraybasierten Container finde ich schlimmer als "nicht sehr gut gelungen".

Jetzt wir vollends bei den Geschmacksfragen angelangt. 🙂 Die nicht generischen Collections ArrayList und Hashtable (seit .NET 1.0) heißen so, dass man direkt auf ihre Implementierung schließen kann. Unter .NET 2.0 hat man die beiden entsprechenden generischen Klassen nach ihrem abstrakten Charakter benannt, also List und Dictionary. Das hat m.E. nichts mit gelungen oder nicht zu tun, sondern ist eine verständliche Designentscheidung. List sagt eben nichts über die Implementierung und passt daher natürlich ohne weiteres auf eine Liste, die intern über ein Array implementiert ist.

Was mir schon die ganze Zeit durch den Kopf geht, seit die Generics eingeführt wurden. Die eigentlichen generischen (= allgemeinen) Klassen, sind doch die, die es vorher gab, oder? 🙂 Die neuen Klassen sind ja spezifischer und nicht allgemeiner als die alten.

herbivore

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo maxE,

Jeder halbwegs logisch denkender Mensch würde annehmen, dass alles was sich wie eine Liste verhält bzw. eine Liste ist, dieses Interface implementiert.

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 bei LinkedList nicht der Fall und deshalb wird konsequenterweise IList nicht implementiert.

Damit wird das Interface-Konzept bei den Collections ad absurdum geführt.

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.

herbivore

T
512 Beiträge seit 2006
vor 17 Jahren

Original von Robert G
Die Benennung "List" für einen arraybasierten Container finde ich schlimmer als "nicht sehr gut gelungen".

Ah ja, du hast also einen besseren Gegenvorschlag? Lass mal hören 😉

Vieleicht wie in der STL "vector", der nun absolut irreführend ist?

RandomAccessCollection? 😉

e.f.q.

Aus Falschem folgt Beliebiges

369 Beiträge seit 2006
vor 17 Jahren

Die Performance-Nachteile die du durch nicht nativen Code hast, sind aber bei den meisten Anwendunggebieten nicht relevant - im Gegensatz bringen dir die Überprüfungsmechanismen, die .Net einbringt ein deutliches Plus in Punkto Fehleranfälligkeit.

Außerdem muss managed Code nicht zwangsweise langsamer sein, da gejitteter Code zumindest theoretisch aufgrund des Laufzeitverhaltens optimiert werden könnte.

347 Beiträge seit 2006
vor 17 Jahren

Original von Kabelsalat
Die Performance-Nachteile die du durch nicht nativen Code hast, sind aber bei den meisten Anwendunggebieten nicht relevant
...
Außerdem muss managed Code nicht zwangsweise langsamer sein, da gejitteter Code zumindest theoretisch aufgrund des Laufzeitverhaltens optimiert werden könnte. Es war genau dieser doch etwas zu theorethische Standpunkt von maxE, der mich überhaupt erst zur Antwort verleitete.
Um es nochmal zu schreiben: Nein, es ist nicht möglich, dass .Net Code schneller als managed Code ist, nicht mit der aktuellen Runtime und erst recht nicht mit dem aktuellen JIT Compiler. 😉
Das war jetzt kein ".Net ist doof"-Beitrag, ich wollte das nur klarstellen.
Je öfter Leute sowas lesen umso mehr glauben sie es, und je mehr an das Märchen glauben umso mehr schreiben es in Blogs oder Threads wie diesem hier. 😉

M
456 Beiträge seit 2004
vor 17 Jahren

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...)

I am Jack's smirking revenge.
I am Jack's raging bile duct.
I am Jack's cold sweat.
I am Jack's complete lack of surprise.
I am Jack's broken heart.
I am Jack's wasted life.

T
512 Beiträge seit 2006
vor 17 Jahren

Das ist doch Blödsinn. Wegen so was Minimalen so nen Aufstand loszubrechen.

Und ja, es gibt viele Pedanten.

Hat dich das mal mehr als 2 Sekunden in deiner Programmiertätigkeit aufgehalten? Vieleicht auch nur ein Zehntel so lange wie du Zeit vergeudest dich darüber aufzuregen?

Wenn jemand mit Programmieren anfängt und ne Liste braucht, wird er die ziemlich leicht finden. Im Vergleich zu "vector" z.B.

e.f.q.

Aus Falschem folgt Beliebiges

M
456 Beiträge seit 2004
vor 17 Jahren

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.

I am Jack's smirking revenge.
I am Jack's raging bile duct.
I am Jack's cold sweat.
I am Jack's complete lack of surprise.
I am Jack's broken heart.
I am Jack's wasted life.

T
512 Beiträge seit 2006
vor 17 Jahren

Da wunder ich mich ernsthaft nach was für einer Schnittstelle du suchst. Was für Funktionen sollen da enthalten sein?

Iterieren -> IEnumerable Generic

  • Hinzufügen, Entfernen, Count -> ICollection Generic
  • Zugriff über Index, Funktionen die Index benutzen -> IList Generic

Könntest du noch ein bisschen mehr von den "vielen kleinen Fehlgriffen" berichten?

e.f.q.

Aus Falschem folgt Beliebiges

S
285 Beiträge seit 2005
vor 17 Jahren

Original von Golo Haas
Sorry, wenn ich das jetzt so sage, aber das war gerade ziemlich oberflächlich.

In .NET wird nichts nativ kompiliert, sondern in MSIL übersetzt, was quasi dem Bytecode von Java entspricht. Klar, Du kannst ngen anführen, verlierst damit aber die Plattformunabhängigkeit, zudem ließe sich ein solches Tool mit Leichtigkeit ebenfalls für Java schreiben (ob es ein solches gibt, weiß ich nicht).

In Bezug auf Webtechnologien ... dann nenn doch mal ein paar konkrete Vorteile von ASP.NET gegenüber J2EE. Was heißt für Dich "die Nase vorn haben"? Beleg das doch bitte mal an Fakten, wo ASP.NET "mächtiger" ist ...

Inwiefern ist Mono unzuverlässig?

Und .NET mit C++ zu vergleichen, geht sowieso am Thema vorbei, denn entweder musst Du C# mit C++ vergleichen oder .NET mit C++ inklusive MFC, ATL, STL, ...

Generell wird nicht native kompiliert, das ist klar. Aber es ist möglich, da viele verunsicherte User gerne ihren Code nicht disassemblierbar machen möchten. Ich meine hier die De-Obfuscator-Disassembler und nicht die ASM Teile. Letztere können ja alles disassemblieren nur halt ASM Code. Ein Tool für .NEt wäre der .NET Protector von RemoteSoft, der native kompiliert. Natürlich braucht man weiterhin das .NET Framework auf dem lokalen Rechner. Für Java habe ich bis dato kein Tool gesehen, und mit der Low Level Programmierung von Java kenne ich mich auch nicht so aus. Es gibt ja keine .exe Files, in diesem Sinne. Somit die Frage, wie Java den Code compiliert.

Mono macht anscheinend Probleme auf Mac OS Plattformen, weil es ständig Probleme während der Ausführung gibt. Auf Linux/Unix Rechnern läuft es einwandfrei. Und für mich ist das schon unzuverlässig. Java ist super, was Plattformunabhängigkeit betrifft und es läuft diesbezüglich reibungslos.

Ich denke, daß ASP.NET für größere Projekte die bessere Wahl ist. Es ist einfacher zu codieren, da ASP.NET in .NET selbst integriert ist und eine bessere IDE vorliegen hat. In Java habe ich nur Eclipse und Netbeans verwendet und ärgern mich verschiedene Plug-Ins bzw. die Einbindung von externen Bibliotheken. Alles das kostet Zeit. Aber @Herbivore, du wirst mir sicher zustimmen, daß es auf die Anforderungen und die Kosten ankommt, wenn man sich für eine der beiden Technologien entscheidet und nicht an welche Sprache sich ein Programmierer gewöhnt hat 😉 Ich entwickle halt schneller mit .NET als mit Java.

3.728 Beiträge seit 2005
vor 17 Jahren
Kaiser´s Bart

Ähhm... 🤔

Wir können uns auch gerne um Kaiser´s Bart streiten. Das ist ganz unterhaltsam, bringt aber nichts. 8)

347 Beiträge seit 2006
vor 17 Jahren

Original von Rainbird
Ähhm... 🤔

Wir können uns auch gerne um Kaiser´s Bart streiten. Das ist ganz unterhaltsam, bringt aber nichts. 8) Full Ack! Bis auf XXXList == irgendwas mit Indexer, statt einer Liste habe ich damit auch kein Problem. Da ich damit nicht erst seit gestern arbeite habe ich in der Praxis auch gar kein Problem damit. 😉
Und @Traumzauberbaum, zum Glück war ich nicht die arme Seele, die die Namen vergeben musste. Da bist du hinterher immer der Ar***. 😁

@maxE, ich denke die SCO.Collection ist ein Erbe aus Delphi. Dort wird TCollection generell als Container für Properties von Komponenten genommen, die IDE hatte dir schon vollen Design time support dafür gegeben. Da viele ehemalige Borländer an der FCL/BCL gearbeitet haben, muss man sich da nicht wundern. g

6.862 Beiträge seit 2003
vor 17 Jahren

Also ich versteh nicht was ihr alle an dem Begriff "List" habt 🤔

Klar, wörtlich übersetzt heißt es Liste, aber genauso auch Aufzählung oder Aufstellung.

Bis auf XXXList == irgendwas mit Indexer, statt einer Liste...

Was ist für dich dann ne Liste?

Selbst im alltäglichen Gebrauch sagt man doch: "Punkt 5 auf meiner Liste ist ..." und nicht "Nach Punkt 1,2,3,4 ist mein 5. Punkt ...". Selbst im Sprachgebrauch greift man direkt auf das 5. Element der Liste zu - sprich wie über nen Indexer 😁

Also nach meinem Sprachverständnis ist die Bezeichnung mehr als okay.

Baka wa shinanakya naoranai.

Mein XING Profil.

4.207 Beiträge seit 2003
vor 17 Jahren

Eine LinkedList ist für mich deshalb keine Liste, weil eben NICHT über Indexer, sondern nur über die Verknüpfungen zugegriffen werden SOLL - auch wenn sie "Liste" heißt.

Insofern finde ich das schon richtig, nur schlecht benannt.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

347 Beiträge seit 2006
vor 17 Jahren

Original von Golo Haas
Eine LinkedList ist für mich deshalb keine Liste, weil eben NICHT über Indexer, sondern nur über die Verknüpfungen zugegriffen werden SOLL - auch wenn sie "Liste" heißt.

Insofern finde ich das schon richtig, nur schlecht benannt. Das ist aber, klassisch gesehen, eine Liste: Ein Pointer, der einen Pointer auf einen Pointer hält, der wiederum einen... 😁

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo Robert G,

was du beschreibst ist - auch klassisch gesehen - eine spezielle Ausprägung einer Liste, nämlich eine LinkedList. 🙂

herbivore

347 Beiträge seit 2006
vor 17 Jahren

Original von herbivore
Hallo Robert G,

was du beschreibst ist - auch klassisch gesehen - eine spezielle Ausprägung einer Liste, nämlich eine LinkedList. 🙂 Wo wir doch gerade so schön beim Erbsenzählen waren... 🙁 ( 😁 )

S
1.047 Beiträge seit 2005
vor 17 Jahren

Eine LinkedList ist für mich deshalb keine Liste, weil eben NICHT über Indexer, sondern nur über die Verknüpfungen zugegriffen werden SOLL - auch wenn sie "Liste" heißt.

naja aber von außen gesehen geht das ja mit dem index... man hangelt sich halt durch

4.207 Beiträge seit 2003
vor 17 Jahren

Der Unterschied zu einer "klassischen" Liste ist aber, dass der Index Dir nicht garantiert wird, ebenso wenig wie Dir bei einer Enumeration die Reihenfolge der Elemente garantiert wird ...

Es wird NUR garantiert, dass jedes Element einmal durchlaufen wird, ebenso wird Dir bei einer LinkedList nur garantiert, dass jedes Element irgendwann eben mal erreicht wird.

Deswegen macht ein Index hier genausowenig Sinn wie bei einem IEnumerable.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

S
1.047 Beiträge seit 2005
vor 17 Jahren

was meinst du mit "dass der Index Dir nicht garantiert wird"?