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

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.

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

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.

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.

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.

nman

Ich sehe in der Ban-Tabelle der letzten Tage keine aktiven User-Bans, Spambots mal ausgenommen.

Könnte sich höchstens um einen IP-Ban gehandelt haben, aber auch da gibt's gerade keine aktiven; muss also ein temporärer Ban gewesen sein.

Wenn du Tor oder irgendeinen öffentlichen Proxy verwendest, war das vielleicht einfach Kollateralschaden, beim Ban eines Trolls mit der gleichen IP.

Xin schrieb:

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.

Ich war und bin als unregistrierter Unterwegs und ich habe das deswegen in diesen Thread geschrieben, weil er aus meiner Sicht der einzige ist, der in Frage käme. Denn wie ich bereits sagte, ich weiß nicht warum ich gebannt wurde, aber wenn, dann wegen meinem Beitrag in diesem Thread.

Nexus

Xin schrieb:

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

War nicht persönlich gemeint, aber ich hatte den Eindruck, dass du mein Beispiel absichtlich falsch verstanden hast. Die Verallgemeinerung von T auf polymorphe Klassen erschien mir nun nicht so wahnsinnig weit hergeholt.

Xin schrieb:

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.

Ja, ich dachte, das Beispiel würde zur Veranschaulichung genügen, anscheinend lag ich damit falsch. Stell dir z.B. das Strategy-Pattern vor, bei dem mehrere abgeleitete Klassen möglich sind, die über ein Base* angesprochen werden. Hier wäre so ein Fall für ein unique_ptr<Base> . Das bezieht sich nicht nur auf lokale Variablen wie in meinem Beispiel, für Member einer Klasse gilt das Gleiche.

Xin schrieb:

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.

Ja, sehe ich auch so. Aber dann hat man die Speicherverwaltung üblicherweise auf einen oder wenige Orte konzentriert, und nicht über den ganzen Code verteilt. Und oft kann man dabei den entsprechenden Code mit RAII wegkapseln, statt sich bei jeder Anwendung wieder erneut mit new und delete herumzuschlagen.

Xin schrieb:

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.

Ich sage nicht, man solle immer Standardlösungen verwenden -- aber wenn du deine spezifischen Container schreibst, die Objekte nicht direkt initialisieren, kannst du Low-Level-Operationen wie Speicherverwaltung doch intern abhandeln.

Xin schrieb:

Liebelein, Du hast recht und ich meine Ruhe.

Sorry, aber ein viel sinnloseres "Argument" als "es funktioniert ja" gibts echt nicht.

dot

DirectX 11 = veraltet schrieb:

Arbeitest du bei Microsoft?

Nope

Xin

Danke für den Fullquote...

Lightspeed=>C++ schrieb:

Ich war und bin als unregistrierter Unterwegs und ich habe das deswegen in diesen Thread geschrieben, weil er aus meiner Sicht der einzige ist, der in Frage käme. Denn wie ich bereits sagte, ich weiß nicht warum ich gebannt wurde, aber wenn, dann wegen meinem Beitrag in diesem Thread.

Da Du zuvor wie derzeit als Unregistrierter unterwegs bist, warst Du also auch nicht gebannt. Wie Dir schon erklärt wurde, hast Du vielleicht eine gebannte IP benutzt - in dem Fall lag es nicht an Dir. Wenn ich das richtig sehe, gibt es kein Problem, also ist die Sache soweit erledigt. Falls doch => PM.

Nexus schrieb:

Xin schrieb:

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

War nicht persönlich gemeint, aber ich hatte den Eindruck, dass du mein Beispiel absichtlich falsch verstanden hast. Die Verallgemeinerung von T auf polymorphe Klassen erschien mir nun nicht so wahnsinnig weit hergeholt.

Ich programmiere bald 20 Jahre in C++, ich komme sicherlich aus einem Umfeld wo auch Assembler und C normal sind daher bin ich sicherlich nicht so empfänglich für shared_ptr. Ich entwickle aber auch selbst eine Programmiersprache und mache mir da genauso meine Gedanken. Da spielen unique und shared Pointer genauso eine wichtige Rolle - und zwar direkt in der Sprache, weil ich die Vorteile durchaus sehe und für so wichtig halte, dass ich damit mit weniger syntaktischen Mehraufwand umgehen möchte als in C++.

Nochmal... ich schreibe in meinem ersten Posting, dass hier Java Vorteile hat, weil es in C++ einen syntaktischen Mehraufwand gibt und Ringreferenzen durch referenzzählende Shared-Pointer nicht aufgelöst werden können. Bei einer doppelt verketteten Liste gibt es immer mindestens ein Element, dass noch auf ein Node zeigt.
Du kommst um ein "delete" nicht herum, auch wenn es "remove" heißt, was die SharedPointer auf Null setzt und über diesen dann "delete" ruft. Es ist kein Vorteil, das Wort "delete" in einem Quelltext zu vermeiden und durch ein anderes zu ersetzen. Ein Vorteil entsteht erst, wenn der Compiler Verantwortung übernehmen kann; ein in meinen Augen größerer Vorteil entsteht, wenn der Compiler den Entwickler auf nicht wahrgenommene Verantwortung hinweisen kann, ohne sie ihm abzunehmen: Das hält den Entwickler wachsam und stärkt sein Verständnis von dem, was er da schreibt. Im von mir benannten Listen-Beispiel verschleiert ein Referenzzähler die Verantwortung: Der Entwickler glaubt aus der Alltagserfahrung, sie abgegeben zu haben, muss aber tatsächlich selbst ran. Hier scheitern auch viele GCs (an die Haarspalter: viele heißt nicht alle).

Hier hat C#/Java Vorteile im Vergleich zur manuellen Speicherverwaltung. Alleine die Tatsache, dass Du std::xxx_ptr schreiben musst ist ein manueller Akt. Du als Entwickler bist verantwortlich, das Richtige zu schreiben, in C#/Java schreibst Du "new bla()" und hast trotzdem kein Speicherleck (wenn man vom immensen Speicherverbrauch des GCs mal absieht)
Das geht in C++ auch, aber auch da musst Du von Hand ran. Du musst immer die Verantwortung tragen, egal ob Du Dein "delete" in unique_ptr versteckst oder selbst schreibst. Es ist immer Mehraufwand und Verantwortung und nicht nur "Mehraufwand".

Und dennoch ist C++ besser, denn die Nachteile von C#/Java überwiegen, sobald Dein Projekt eine gewisse Größe erreicht haben, sobald der GC zuviel Leistung oder Speicher abzwackt, sobald Du nicht mehr in der Lage bist, das Projekt vollständig zu überblicken und jede semantische Unterstützung des Compilers zur Fehlervermeidung brauchst, die Du bekommen kannst.

Memoryleaks sind ein Anfängerproblem. RAII und SmartPointer sind zum Teil gültige Lösungen dafür, aber syntaktisch und im Fall von Shared-Pointern auch Leistungsmäßig Mehraufwand zu einfachen Pointern.

Nexus schrieb:

Xin schrieb:

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.

Ja, sehe ich auch so. Aber dann hat man die Speicherverwaltung üblicherweise auf einen oder wenige Orte konzentriert, und nicht über den ganzen Code verteilt. Und oft kann man dabei den entsprechenden Code mit RAII wegkapseln, statt sich bei jeder Anwendung wieder erneut mit new und delete herumzuschlagen.

Habe ich kein Problem mit.
Ich weiß nicht, was Du mit 'über den ganzen Code' verteilt meinst, aber wenn das auf Spaghetti-Speicheralloziierung (ähnlich wie das Rumhüpfen mit Goto) rausläuft, bin ich voll bei Dir.
In der Regel gibt aber das Problem mir vor, wo ich new und delete brauche.
Ich löse Probleme, bevorzugt auf die einfachste Art, die mir zur Verfügung steht. Ich bin kein Verfechter von akademischen Weisheiten. Alles hat seinen Wert und alles hat seine Ausnahme.

Die Frage ist, ob man einen guten Grund hat, warum man etwas so oder so entwickelt, die üblichen Lehrmeinungen gelten nur für die Mehrheit der Fälle, aber nicht für die Allgemeinheit.

Nexus schrieb:

Xin schrieb:

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.

Ich sage nicht, man solle immer Standardlösungen verwenden -- aber wenn du deine spezifischen Container schreibst, die Objekte nicht direkt initialisieren, kannst du Low-Level-Operationen wie Speicherverwaltung doch intern abhandeln.

Mache ich auch, dafür sind die Container ja da.

Ein spezialisierter Container ist Teil eines speziellen Programms und der muss auch geschrieben werden. Es gibt aber innerhalb des Containers kein Intern. Da muss man mit new und Placement-New und delete oder dem direkten Aufruf des Destructors, um Objekte zu zerstören, für die man gar keinen Speicher alloziiert hat.

Und wenn dann Leute ankommen, die über hunderte Klassen nur drei delete brauchen oder feststellen, dass RAII immer besser ist, dann kann ich nur sagen, dass diese Leute offenbar andere Probleme zu lösen haben als ich.
Und wer "immer" schreibt muss andere Erfahrungen gemacht haben als ich.

Wäre schön, wenn diese Personen dann in Erwägung ziehen könnten, dass ich deswegen nicht zwangsläufig auf dem falschen Dampfer bin, sondern einfach andere Probleme löse. Eventuell sogar sinnvoll.

Nexus schrieb:

Xin schrieb:

Liebelein, Du hast recht und ich meine Ruhe.

Sorry, aber ein viel sinnloseres "Argument" als "es funktioniert ja" gibts echt nicht.

Och, ich halte "Es funktioniert" für ein sehr gutes Argument.

Fast alle Entwickler sind schlauer als andere. Aber nicht davon alle schreiben funktionierende Software. Ich muss hier häufiger mal ziemlich haarige Fehler debuggen und zumindest letztes Jahr war kein Fehler von mir dabei.

Ansonsten ich mich auch nicht genötigt, hier irgendwem Rechenschaft abzulegen. Ich unterhalte mich gerne über unterschiedliche Erfahrungen, aber sobald mir jemand sagt, der meine Probleme und meinen Background nicht kennt, dass mir die Vorstellungskraft fehlt oder mir Regeln mit "immer" erklärt, sinkt auch meine Bereitschaft, irgendetwas zu begründen. Wenn's vorher nicht interessierte, interessiert nun auch keinen.

Hier kann man drüber reden, weshalb ich welche Meinung vertrete, aber ich sehe keinen Grund in jeder zweiten Diskussion erklärt zu bekommen, dass ich Dinge falsch mache und dann auf dem Standpunkt zu stehen, dass ich mich verteidigen müsste. Wen's interessiert hätte, hätte wohl gefragt, statt einen Schlagabtausch zu initiieren.

"Es funktioniert" muss dann reichen. Dass meine Software funktioniert weiß ich schon und dass ich zumindest gut genug bin um für meine Programmierkenntnisse akzeptabel bezahlt zu werden, weiß ich auch. Hier um Recht zu kämpfen hingegen oder dafür zu sorgen, dass jemand eine sinnvolle Antwort lesen kann, nachdem er sowieso überzeugt ist, dass ich keine Ahnung habe, macht weder meine Software funktionstüchtiger, noch erhöht es meinen Kontostand.

Eine freundlich formulierte Frage, die Interesse zeigt und die Chance auf eine für beide Seiten inspirierende Diskussion birgt, hat da für mich einen viel höheren Reiz. Das bietet die Chance, meine Software zu verbessern.

Nexus

Okay, dann sind wir uns ja grösstenteils doch einig.

Wie gesagt, das mit der Vorstellungskraft habe ich geschrieben, weil du meine Aussage mit der polymorphen Basisklasse wörtlich genommen hast, statt sie sinnvoll zu interpretieren.

"Es funktioniert" ist schon deswegen kein Argument in unserer Diskussion über Programmiertechniken, weil die Beobachtung der Semantik alleine nichts über Codequalität aussagt. Neben einem funktionierenden Resultat ist nämlich auch Entwicklungszeit relevant -- daher zahlen sich Techniken aus, welche die Umsetzung eines Features in kürzerer Zeit, mit weniger Wartungs- und Debugaufwand ermöglichen.

Eisflamme

dot:
Stört Dich bei QT die Compilezeit wegen dem moc oder wo genau kommst Du so sehr mit der "Ästhetik" in Berührung, dass Dich das traurig stimmt?

Ich habe auch Mal überlegt C# für UI zu verwenden, aber ich kriege mit QT alles hin (teilweise nach etwas Suche, wie man Probleme löst, gut).

Ethon

Ich finde C# sehr elegant, unproduktiver als C++ gefühlsmäßig nicht.

Ein GC ist in der Verwendung doch deutlich angenehmer als Smartpointer ... ich habe mal tief unten in einer Hierachie, in der viele Objekte andere Objekte besitzen einen vector<unique_ptr<Foo>> verwendet ... GCC hat ein paar Seiten Fehler ausgespuckt und ich habe recht lange gebraucht bis ich die Stelle gefunden habe, an der ein Unterobjekt nicht gemoved sindern kopiert wurde. Die Fehlermeldungen haben 0 geholfen.

Klar ist das toll so den Fehler zu finden, aber ich persönlich opfere lieber ein paar Mikrosekunden Laufzeit als ewig auf Fehlersuche zu gehen.
War schon auf dem Sprung einfach shared_ptr zu verwenden damit ich meine Ruhe habe, hab mich aber doch durchgebissen.