Wann sollte ich C# über C++11 benutzen?

[dot]

Ich sehe IDisposable als Symptom und using als Symptombehandlung und nicht als tatsächliche Problemlösung. using ist am Ende nur Syntaxzucker für genau einen konkreten Anwendungsfall, nämlich den einer temporären Ressource in einer Funktion. Zugegeben: Für den Fall funktioniert es. Aber leider deckt das eben auch nur einen Bruchteil des Problems ab. IDisposable ist genau das, was man sich mit Garbage Collection einhandelt. Das Grundproblem mit IDisposable ist, dass es ansteckend ist. Sobald du irgendwo in einer Objekthierarchie ein IDisposable einbaust, musst du sämtliche Objekte weiter oben ebenfalls IDisposable machen. Mit anderen Worten: Du hast mit einem Schlag einen riesen Haufen Code der sich plötzlich um das Management der Lebensdauer eines einzigen Members einer einzigen Klasse irgendwo ganz weit unten kümmern muss. Etwas, das eigentlich als Implementierungsdetail in einer Klasse gekapselt sein sollte, muss plötzlich in Code, der eigentlich nichts damit zu tun haben sollte, berücksichtigt werden. Und auf dieses Problem stoßt man leider sehr schnell. Schonmal eine Klasse geschrieben, die z.B. eine Datei als Member haben sollte, die so lange offen sein soll, wie das Objekt benutzt wird? In C++ geht das völlig natürlich ohne dass ich auch nur irgendwas dafür tun müsste. In C# muss ich dafür nicht nur extra Code schreiben, sondern potentiell auch noch über das ganze Programm verteilt sehr viel dem eigentlichen Problem völlig fremden Code seiner Lesbarkeit berauben...

[Nexus]

Xin schrieb:

...entweder verstehe ich hier gerade "manuelle Speicherorganisation" nicht, aber ich brauche wohl kaum ein Beispiel für new und delete zu geben!?

Das Problem ist: new und delete gehören nicht in den Anwendercode. Sie sind sinnvoll, da du mit ihnen eine einfache Möglichkeit zur Speicherverwaltung hast, aber ihre Verwendung gehört immer abgekapselt.

Xin schrieb:

SmartPointer sind kein GC, zumal sie nicht in der Sprache verankert sind, ergo die Datentypen aufwendiger zu repräsentieren sind, ergo der Code unleserlicher wird. => Mehraufwand.

Ne. Der Mehraufwand ist bedeutungslos, wenn man beachtet, wie viel Logikcode durch RAII wegfällt. Du hast nachher kein einziges delete mehr. Funktionen mit mehreren Rückgabepfaden oder Exceptions sind automatisch sicher und werden nicht mit Aufräumcode unleserlich gemacht.

Simples Beispiel:

// RAII
std::unique_ptr<T> ptr(new T);
ptr->func();
if (ptr->ok())
    return ptr->thing();
else
    return 47;

// Manuelle Speicherverwaltung
T* ptr(new T);
ptr->func(); // func() darf nicht werfen
if (ptr->ok()) // ok() darf nicht werfen
{
    int r = ptr->thing(); // thing() darf nicht werfen
    delete ptr;
    return r;
}
else
{
    delete ptr;
    return 47;
}

Nun stell dir das Gleiche vor mit mehr als einer Ressource. Oder, falls die einzelnen Funktionsaufrufe Exceptions werfen können. Der Code wird wahnsinnig unübersichtlich mit manueller Speicherverwaltung.

Nene, RAII ist immer besser. Und Smart-Pointer nicht zu benutzen wegen syntaktischem "Mehraufwand" ist doch etwas sehr fragwürdig. Gerade wenn sie Null Laufzeitkosten haben.

[Mechanics]

dot schrieb:

Sobald du irgendwo in einer Objekthierarchie ein IDisposable einbaust, musst du sämtliche Objekte weiter oben ebenfalls IDisposable machen. Mit anderen Worten: Du hast mit einem Schlag einen riesen Haufen Code der sich plötzlich um das Management der Lebensdauer eines einzigen Members einer einzigen Klasse irgendwo ganz weit unten kümmern muss. Etwas, das eigentlich als Implementierungsdetail in einer Klasse gekapselt sein sollte, muss plötzlich in Code, der eigentlich nichts damit zu tun haben sollte, berücksichtigt werden. Und auf dieses Problem stoßt man leider sehr schnell. Schonmal eine Klasse geschrieben, die z.B. eine Datei als Member haben sollte, die so lange offen sein soll, wie das Objekt benutzt wird? In C++ geht das völlig natürlich ohne dass ich auch nur irgendwas dafür tun müsste. In C# muss ich dafür nicht nur extra Code schreiben, sondern potentiell auch noch über das ganze Programm verteilt sehr viel dem eigentlichen Problem völlig fremden Code seiner Lesbarkeit berauben...

Ja, das stimmt schon. Das ist ein technisches Problem. Aber ich sehe so gut wie keine Use Cases für sowas und keine praktischen Probleme. Wenn eine Klasse intern Ressourcen verwaltet, ist es selbst eine Ressource und es macht auch Sinn, dass sie IDisposable implementiert. Und brauchen tut man das ganz ganz selten. Ich hab sicher schon mal Klassen geschrieben, die eine Datei oder andere Ressource offen halten, auch wenn ich mich grad nicht explizit dran erinnern kann und das sicherlich extrem selten vorkam. Aber das war sicher nichts, wo ich 10 000 von solchen Objekten im Programm verwalte. Das war dann vielleicht mal eine Klasse, die eine Datei offen gehalten hat, mein Gott, dann wird die notfalls halt etwas später zugemacht. Ich halte diese ganzen Probleme für nicht wirklich praxisrelevant.

[snipes]

Ich denke mal Mechanics wird von Microsoft gesponsert und will jetzt künstlich die Probleme kleinreden.

[Xin]

Nexus schrieb:

Xin schrieb:

...entweder verstehe ich hier gerade "manuelle Speicherorganisation" nicht, aber ich brauche wohl kaum ein Beispiel für new und delete zu geben!?

Das Problem ist: new und delete gehören nicht in den Anwendercode. Sie sind sinnvoll, da du mit ihnen eine einfache Möglichkeit zur Speicherverwaltung hast, aber ihre Verwendung gehört immer abgekapselt.

"Anwendercode"?

Wer ist denn hier bitte Anwender!?
Der Entwickler als Anwender der Programmiersprache? Und der soll kein new und delete mehr anwenden?
Wer dann?

Nexus schrieb:

Xin schrieb:

SmartPointer sind kein GC, zumal sie nicht in der Sprache verankert sind, ergo die Datentypen aufwendiger zu repräsentieren sind, ergo der Code unleserlicher wird. => Mehraufwand.

Ne. Der Mehraufwand ist bedeutungslos, wenn man beachtet, wie viel Logikcode durch RAII wegfällt. Du hast nachher kein einziges delete mehr. Funktionen mit mehreren Rückgabepfaden oder Exceptions sind automatisch sicher und werden nicht mit Aufräumcode unleserlich gemacht.

Dann möchte ich sehen, wie Du eine Liste in RAII implementiert.
Und jetzt sag nicht "Ich nutze std::list"...

Nexus schrieb:

Nene, RAII ist immer besser. Und Smart-Pointer nicht zu benutzen wegen syntaktischem "Mehraufwand" ist doch etwas sehr fragwürdig. Gerade wenn sie Null Laufzeitkosten haben.

Ahja... wir haben hier eine Pseudodiskussion. Lies mein erstes Posting, bevor Du Dich auf einen Zug von otze und volkard schwingst.

Du nennst es syntaktischen Mehraufwand für SmartPointern im Vergleich zum GC. Ich spreche von Mehraufwand. Wir sprechen also beide von Mehraufwand. Wir sollten nicht über Dinge argumentieren, wo wir uns einig sind.
Ich habe nirgendwo geschrieben, dass ich gegen die Verwendung von SmartPointern bin oder gegen RAII Partei mache.

Dass ein Smartpointer Null Laufzeitkosten hat, wäre mir allerdings neu. Deine Behauptung an Unique-Pointern festzuhalten ist nämlich etwas mutig. Manuelle Speicherverwaltung braucht man nämlich nicht für gezeigtes Beispiel eines UniquePointers. Für Dein Beispiel ist ... eher unangebracht für manuelle Speicherverwaltung. Es geht nicht darum ein delete zu vermeiden. Für die Argumentation wäre vielleicht ein Beispiel sinnvoll, was überhaupt ein new benötigt.

// scheiß was auf Pointer.
T obj;
obj.func();
if (obj.ok())
    return obj.thing();
else
    return 47;

Schreib eine doppelt verkettete Liste mit SmartPointern ohne Mehraufwand in Syntax und Rechenleistung. Syntaktisch ist da ist die GC vorne, womit der C# Code hier lesbarer ist. Mehr habe ich nie gesagt.

[dot]

Mechanics schrieb:

Das ist ein technisches Problem.

...dessen Existenz notwendige Konsequenz der Verwendung von Garbage Collection ist...

Mechanics schrieb:

Aber ich sehe so gut wie keine Use Cases für sowas und keine praktischen Probleme.
[...]
Und brauchen tut man das ganz ganz selten. Ich hab sicher schon mal Klassen geschrieben, die eine Datei oder andere Ressource offen halten, auch wenn ich mich grad nicht explizit dran erinnern kann und das sicherlich extrem selten vorkam. Aber das war sicher nichts, wo ich 10 000 von solchen Objekten im Programm verwalte.

Nur weil du etwas ganz ganz selten brauchst, heißt das noch lange nicht, dass man etwas ganz ganz selten braucht. Ich weiß ja nicht was für Anwendungen du so schreibst, aber meiner Erfahrung nach braucht man das in spätestens jeder nichttrivialen Anwendung früher oder später. Schonmal versucht z.B. OpenGL in C# zu verwenden? Ich hab mir auch gedacht, dass es so schlimm ja nicht sein kann. Und das war genau der Fehler, der mich damals eines Besseren belehrt hat. Und dabei was das sogar noch eine relativ einfache Anwendung...

Mechanics schrieb:

Wenn eine Klasse intern Ressourcen verwaltet, ist es selbst eine Ressource und es macht auch Sinn, dass sie IDisposable implementiert.

Stimmt, wenn man IDisposable als gegeben annimmt, wozu C# dich offenbar erzogen hat. Denn in der Welt von C# gibt es tatsächlich keine Alternative (genau das ist ja der Kern meiner Kritik). Aber überleg dir mal, ob du nicht vielleicht völlig anders denken würdest, wenn du, selbst nur für einen kurzen Moment, schonmal eine bessere Welt gesehen hättest...

Mechanics schrieb:

Das war dann vielleicht mal eine Klasse, die eine Datei offen gehalten hat, mein Gott, dann wird die notfalls halt etwas später zugemacht. Ich halte diese ganzen Probleme für nicht wirklich praxisrelevant.

Du hast dich sicher auch schon mehr als einmal drüber geärgert, dass du z.B. eine Datei nicht umbenennen, löschen etc. konntest, weil irgend ein anderer Prozess sie blockiert hatte? Genau diese Einstellung beschert uns derartige Software...

[kantaki]

Ich wollte hier eigentlich keinen Krieg auslösen :).

Ich lese oft das C# sehr gut in Verbindung mit GUI's sein soll. Doch niemand hier hat Qt genannt. Ich habe mit beiden GUI solutions gearbeitet und ich bin nicht wirklich langsamer mit C++ & Qt als mit C# WPF.

Den richtigen Vorteil von C# sehe ich immer noch nicht. Compile speed, kickass IDE support , huge library, interop mit anderen .NET Sprachen sind nice to have aber überzeugen mich nicht wirklich diese Sprache einzusetzen.

Wahrscheinlich ist es wohl doch eine reine Geschmackssache.

[dot]

Wenn man bei Qt mal unter die Haube schaut, vergeht einem das Lachen in Anbetracht der Hässlichkeiten, die einem da entgegen starren, leider sehr schnell. Die Tatsache, dass Qt vermutlich praktisch das beste ist, was es für C++ im Moment gibt, stimmt mich immer leicht depressiv...

[opengl vs directx]

Warum interessiert dich das so stark was unter der Haube abgeht? So lange es nicht buggy ist, sollte es doch egal sein.

[dot]

Weil ich persönlich großen Wert auf Ästhetik lege.

[Nexus]

Xin schrieb:

Dann möchte ich sehen, wie Du eine Liste in RAII implementiert.
Und jetzt sag nicht "Ich nutze std::list"...

RAII bedeutet nur, dass das Objekt die Verantwortung für die Ressourcen trägt. Das heisst, bei der Initialisierung wird Speicher angefordert, bei der Zerstörung freigegeben. Eine Liste implementierst hoffentlich auch du so.

Davon abgesehen habe ich geschrieben: "ihre [ new/delete ] Verwendung gehört immer abgekapselt". Wenn du manuelle Speicherverwaltung nur intern in einem Container verwendest, ist ja alles gut. Da du eben RAII betreibst, und sich der Anwender der Liste nicht mehr um Speicherverwaltung kümmern muss. Folglich ist der Anwendercode ist frei von new und delete .

Xin schrieb:

Wir sprechen also beide von Mehraufwand.

Ne, ich sprach von "Mehraufwand"

Xin schrieb:

Für die Argumentation wäre vielleicht ein Beispiel sinnvoll, was überhaupt ein new benötigt.

Nimm eben eine polymorphe Basisklasse statt T .

Aber ich glaube wir sind uns einig: unique_ptr ist gratis, und gekapseltes new/delete kann akzeptabel sein.

[über?]

Wann sollte ich C# über C++11 benutzen?

Was ist das für ein Dialekt? Warum "über" und nicht "anstatt"? Oder willst du einen C# Wrapper für C++ schreiben?

[otze]

Xin schrieb:

Und jetzt sag nicht "Ich nutze std::list"...

Na, exakt das ist aber der Fall. Gnauso wie du schreiben kannst: "Dein Beispiel ist reichlich scheiße, ich lege das Objekt auf den Stack", kann ich sagenst als ob SPicherv: "Dein Beispiel ist reichlich scheiße, ich benutze std::list"e .

Der Punkt ist, dass du es hinstellstellst, als ob Speicherverwaltung ein Problem ist, in dem man sich in 10% der Fälle rumschlagen muss und der richtigen Codeoverhead erzeugt. Ich habe gerade durch mein Projekt gegrept und 0 delete gefunden. Und news waren auch lokal auf 2-3 Dateien begrenzt (von den mehreren 100...)

[loks]

Bin mir nicht sicher ob das zwischendrin schon gesagt wurde, aber...

Die eingehende Frage ist falsch, bzw übersieht einen wesentlichen Punkt:

Man muß keineswegs entscheiden zwischen C# _oder_ C++, sondern beides läßt sich auch wunderbar kombinieren, also C# _und_ C++. Man kann also das Beste aus beiden Welten haben...

IJW FTW.

Ja, MS nennt die Technologie tatsächlich "It Just Works": http://msdn.microsoft.com/en-us/library/aa712982(v=vs.71).aspx

[Xin]

Nexus schrieb:

Xin schrieb:

Wir sprechen also beide von Mehraufwand.

Ne, ich sprach von "Mehraufwand"

Ist das hier eigentlich eine Diskussion, die zu einem Konsens führen soll oder diskutieren wir hier, weil wir nichts besseres zu tun haben? In dem Fall hätte ich nämlich was besseres zu tun!?

Xin schrieb:

Für die Argumentation wäre vielleicht ein Beispiel sinnvoll, was überhaupt ein new benötigt.

Nimm eben eine polymorphe Basisklasse statt T .[/quote]
std::unique_ptr< PolymorpheBasisklasse > ptr( new PolymorpheBasisklasse() )?

Lassen wir das Haarespalten. Entweder kenne ich T und kann es direkt auf dem Stack anlegen oder ich kenne es nicht, dann macht der unique_ptr an der Stelle aber keinen Sinn.

Xin schrieb:

Aber ich glaube wir sind uns einig: unique_ptr ist gratis, und gekapseltes new/delete kann akzeptabel sein.

new und delete kann ebenso ohne Kapselung akzeptabel sein. Nicht alles, was man programmiert kann Exceptions werfen. Keine Exceptions, keine Gefahr.

otze schrieb:

Xin schrieb:

Und jetzt sag nicht "Ich nutze std::list"...

Na, exakt das ist aber der Fall.

So lobenswert es ist, bewährte Techniken zu verwenden, um eigene Fehler zu vermeiden, so sehr beeindruckt mich auch, das krampfhafte Festhalten daran.

Naja, wir beide programmieren ja nicht zusammen.

otze schrieb:

Der Punkt ist, dass du es hinstellstellst, als ob Speicherverwaltung ein Problem ist, in dem man sich in 10% der Fälle rumschlagen muss und der richtigen Codeoverhead erzeugt.

Ich könnte jetzt mal wieder fragen, wo ich das geschrieben haben soll... aber dieser Hang zu Diskussion der Diskussion wegen, bringt mich auch nicht weiter. Lies das erste Posting.

otze schrieb:

Ich habe gerade durch mein Projekt gegrept und 0 delete gefunden. Und news waren auch lokal auf 2-3 Dateien begrenzt (von den mehreren 100...)

Ich kann hier nicht grepen. Ich arbeite weniger mit SmartPointern und diese habe ich auch noch selbst geschrieben. Ich arbeite durchaus häufiger mit new und delete, dafür arbeite ich überhaupt nicht mit Exceptions. Die Anzahl der Dateien weiß ich nicht, die mehrere hundert halte ich aber problemlos.

Und jetzt kommt's: Es funktioniert trotzdem.

loks schrieb:

Man muß keineswegs entscheiden zwischen C# _oder_ C++, sondern beides läßt sich auch wunderbar kombinieren, also C# _und_ C++. Man kann also das Beste aus beiden Welten haben...

MS nennt die Technologie tatsächlich "It Just Works"

Das machen wir auf der Arbeit auch. Ich persönlich würde es als handverlesenen Albtraum bezeichnen, der vorrangig mit selbstgeschriebenen Codegeneratoren im Zaum gehalten wird, die dafür als die Architektur in beiden Sprachen (sowie einer dritten) behindern.
"Just" halte ich daher für etwas weit hergeholt, sofern Du nicht Microsofts .NET-Dialekt von C++ meinst, sondern echtes C++.

[Nexus]

Xin schrieb:

Entweder kenne ich T und kann es direkt auf dem Stack anlegen oder ich kenne es nicht, dann macht der unique_ptr an der Stelle aber keinen Sinn.

Hast du echt so wenig Vorstellungsvermögen? Warst du noch nie in einer Situation, wo du nur einen abstrakten Basisklassenzeiger hattest? Statt diesen mit new und delete manuell zu verwalten, nimmt man eben unique_ptr -- weil es nichts kostet, sicherer ist und Code übersichtlicher macht.

Xin schrieb:

new und delete kann ebenso ohne Kapselung akzeptabel sein. Nicht alles, was man programmiert kann Exceptions werfen. Keine Exceptions, keine Gefahr.

Ähm, doch. Exceptions sind nicht der einzige Grund, wieso man RAII verwendet. Ich habe vorher z.B. mehrere Rückgabepfade erwähnt.

Nochmals: std::unique_ptr kostet nichts, macht den Code automatisch sicher und übersichtlicher, weil die Freigabe wegfällt. Wieso sollte man Memory Leaks riskieren, wenn RAII sie ohne irgendwelche Nachteile vermeiden kann?

Xin schrieb:

Und jetzt kommt's: Es funktioniert trotzdem.

Dir scheinen die Argumente auszugehen, wie? Natürlich funktioniert manuelle Speicherverwaltung, aber es ist ein unnötiger Mehraufwand, den man nur in Kauf nimmt, wenn man die Vorteile von RAII nicht erkennt.

[Lightspeed=&gt;C++]

Xin schrieb:

Lightspeed=>C++ schrieb:

Xin schrieb:

Ein GC braucht eigentlich kein Mensch. Im Schnitt meldet valgrind alle 3-6 Monate mal ein Leak, welches ich mir was angucken sollte. Dann mache ich das und dann war's das.

Man brauchts nicht, weil men es als C++ Programmierer eben gewohnt ist, seinen Code ohne GC zu programmieren.

Damit meine ich nicht die Gewohnheit, sondern die Notwendigkeit.
Geschätzt 90% bei der Speicherveraltung lassen sich mit C++ besser lösen als mit Java/C# und dem GC. Beim Rest muss man sich wirklich fragen, ob man dafür so ein Ungetüm haben will.
Ich bin der Meinung, dass das kein Mensch braucht.

Das ist schon klar, allerdings erspart einem ein GC genau dann Arbeit, wenn man es eben nicht gewohnt ist, sich in C++ selbst darum zu kümmern.

Da die meisten C++ User aber schon Erfahrung in C++ haben, sind sie es eben gewohnt ihre Probleme ohne GC zu lösen und daher nutzen sie ihn auch nicht.

Insofern ist der GC lediglich für C++ Neulinge interessant und das auch nur dann, wenn ich C++ Buch daran ausgerichtet ist, was auf die wenigstens C++ Bücher zutreffen dürfte.

Lightspeed=>C++ schrieb:

Der unberechtigten Ban war übrigens fehl am Platz.

Ban? Worum geht's und müsste ich was davon wissen?
[/QUOTE]
Tja, das solltet ihr Mods mir mal erklären.
Ich war vorgestern gebannt und weiß bis heute nicht weshalb.

[Xin]

Nexus schrieb:

Xin schrieb:

Entweder kenne ich T und kann es direkt auf dem Stack anlegen oder ich kenne es nicht, dann macht der unique_ptr an der Stelle aber keinen Sinn.

Hast du echt so wenig Vorstellungsvermögen? Warst du noch nie in einer Situation, wo du nur einen abstrakten Basisklassenzeiger hattest? Statt diesen mit new und delete manuell zu verwalten, nimmt man eben unique_ptr -- weil es nichts kostet, sicherer ist und Code übersichtlicher macht.

Ich liebe diese Formulierungen in diesem Forum, die nahezu grundsätzlich davon ausgehen, dass das Gegenüber einen Mangel haben muss...

Ich habe durchaus das Vorstellungsvermögen und arbeite sehr viel mit virtuellen Basisklassen. Ich arbeite auch viel mit Templates und beides auch gerne in Kombination. Trotzdem würde ich nicht behaupten, dass Templates die Übersichtlichkeit von Quelltexten erhöhen.

Nexus schrieb:

Xin schrieb:

new und delete kann ebenso ohne Kapselung akzeptabel sein. Nicht alles, was man programmiert kann Exceptions werfen. Keine Exceptions, keine Gefahr.

Ähm, doch. Exceptions sind nicht der einzige Grund, wieso man RAII verwendet. Ich habe vorher z.B. mehrere Rückgabepfade erwähnt.

Dafür braucht man aber keinen unique_ptr.

Den Unique_Ptr als Dokumentation akzeptiere ich vollkommen. Ich akzeptiere unique_ptr in Containern. Alles wunderbar.

Aber das konstruierte Beispiel hakt. Ich kann mich nicht über Pointer beschweren, wo ich sie nicht brauche - und wo ich keine Pointer brauche, brauche ich auch keine unique_ptr.

Nexus schrieb:

Nochmals: std::unique_ptr kostet nichts, macht den Code automatisch sicher und übersichtlicher, weil die Freigabe wegfällt. Wieso sollte man Memory Leaks riskieren, wenn RAII sie ohne irgendwelche Nachteile vermeiden kann?

Nicht alles lässt sich über unique_ptr lösen.

Und shared_ptr kosten. Wenn man bereit ist die Kosten zu tragen, kein Problem. Aber es gibt eben auch durchaus Fälle, wo man diese Kosten nicht tragen will. Oder wo das ganze einfach keinen Mehrwert ergibt.

Für mache scheint die Kostenfrage uninteressant zu sein, ich schreibe dafür eigene Container, weil das millionenfache Anfragen und Appends an einzelne Container nunmal Probleme sind, die Zeit kosten. Und wenn so ein Vector resized wird und dafür ein paar hundertausend Standard-Konstruktoren ausführt, dann kann man sich das nicht immer leisten, um anschließend ein paar hunderttausend Objekte zu verschieben.

Mir fehlt nicht die Vorstellungskraft, mir fehlen die std::Probleme.
Deswegen bringe ich es auch ganz locker über die Lippen, dass ich manche Probleme ohne std::Problemloesung löse und dann gerne new und delete verwende.

Nexus schrieb:

Xin schrieb:

Und jetzt kommt's: Es funktioniert trotzdem.

Dir scheinen die Argumente auszugehen, wie? Natürlich funktioniert manuelle Speicherverwaltung, aber es ist ein unnötiger Mehraufwand, den man nur in Kauf nimmt, wenn man die Vorteile von RAII nicht erkennt.

Liebelein, Du hast recht und ich meine Ruhe.

[DirectX 11 = veraltet]

dot schrieb:

Der große Vorteil von C# gegenüber C++ ist die einfach nur riesige Library, die einem mit dem .NET Framework zur Verfügung steht. Rein sprachlich hat C# den Vorteil, dass es vergleichsweise einfach ist, was es zu meiner üblichen Empfehlung für Anfänger macht, ...

Du empfiehlst:

Anfängern C# anstatt Java
3d Grafik Interessierten (siehe anderer Thread) DirectX anstatt OpenGL

Frage:

Wie kommt es, dass du so sehr auf Microsoft Technologien setzt?
Arbeitest du bei Microsoft?

[Xin]

Lightspeed=>C++ schrieb:

Xin schrieb:

Lightspeed=>C++ schrieb:

Der unberechtigten Ban war übrigens fehl am Platz.

Ban? Worum geht's und müsste ich was davon wissen?

Tja, das solltet ihr Mods mir mal erklären.

Erstens schreibst du hier als Unregistrierter, was belegt, dass der Bann offensichtlich nicht sehr erfolgreich ist.

Zweitens - und nur deswegen schreibe ich das in diesen Thread: Wie wäre es, wenn Du den Moderator fragst, der den Bann ausgesprochen hat, statt einfach ein beliebiges Thema zu kapern?

Lightspeed=>C++ schrieb:

Ich war vorgestern gebannt und weiß bis heute nicht weshalb.

Tja, und ich habe auch keine Kristallkugel, lese weder das ganze Forum, noch fand ich auf die Schnelle einen Hinweis, dass irgendwer gebannt wurde.

Wenn Du mich ansprichst, was Du natürlich auch gerne tun kannst, so schreib mir diesbezüglich doch eine PM, die statt "Der Ban war unberechtigt" und "Du solltest mir mal erklären" etwas enthält wie Informationen, vielleicht sogar in freundliche Worten verpackt, soweit mir bekannt ist, habe ich Dir bisher nichts getan.
Zum Beispiel "Mein Accountname ist ... und ich wurde kürzlich gebannt und kann mir nicht erklären weshalb, daher wäre es nett, wenn Du mal nachguckst und mich entweder wieder freischalten lässt oder mir mitteilen könntest, was falsch gelaufen ist".

Gerade der Accountname wäre hilfreich und ich werde sehen, was ich konkretes in Erfahrung bringen kann.