Programmier-"Niveau"

[cooky451]

Ja ja, Java ist doof, hatten wir doch schon. Nicht zu weit abweichen. Die Frage war eigentlich, wie bei euch (ich nehme einfach mal an, dass einige hier in Firmen arbeiten die Software entwickelt) so der Eindruck ist. Wenn ihr Code von Kollegen lest, müsst ihr euch dann fragen wie die denn an ihren Job gekommen sind? Spielen Standards bei euch eine Rolle, oder wird einfach geliefert was funktioniert? Darf man überhaupt etwas koplexeren Templatecode schreiben, oder beschweren sich die Kollegen dann, wenn sie das nicht lesen können? Achtet man bei euch auf Exception Sicherheit?

[Shade Of Mine]

cooky451 schrieb:

Mich würde viel mehr einfach mal interessieren, wie viele Leute in eurem Umfeld schon mal MVC gehört haben, simple TMP Programme schreiben können, wissen was RAII ist, wie ein GC etwa funktioniert, sich mehr oder weniger im C++ (oder C) Standard zurecht finden, überhaupt in der lage sind Exception sichere Programme schreiben zu können, ...
Denn die einzigen Leute von denen ich weiß, dass sie diese Kriterien erfüllen, "kenne" ich sozusagen aus dem Internet, und selbst da sind die rar.

Es ist vorallem eine Frage der Anforderung.

MVC zB kennt jeder bei uns - es sind Webentwickler und damit, auch wenn ihnen MVC jetzt direkt vielleicht nichts sagt, so verwenden sie es - denn im Web geht es kaum anders (man kann frontend und backend eh nicht mischen).

Aber Design Patterns und so sind ziemlich rar. Bringt ihnen ja auch keiner bei. Wir holen uns die Leute idR direkt von den Unis und FHs - und egal in welcher Abteilung sie landen, der Ausbildungsstandard an den Unis und FHs ist unter aller sau.

Alle guten Leute bei uns, haben sich das Wissen ausserhalb der Bildungseinrichtungen angelernt (und ich rede nicht nur von der Entwicklungsabteilung).

Das Problem ist also: die guten Leute sind die, die sich selber weiterbilden. Das tun aber nicht alle. Ergo ist der Durchschnitt nur Mittelmass

PS:
Was den Code meiner Kollegen betrifft - es gibt ein paar Spezialisten, da schaut man lieber nicht hin und betet :p Aber eigentlich passt es. Viel von unserem Code ist Fire&Forget und bei den wichtigen Sachen laesst man die Spezialisten halt nicht ran

Das Problem ist aber auch: guter Code wird nicht honoriert.

[dot]

RAII in Java? Meinst du dieses try-with-resources?

[Gast]

cooky451 schrieb:

SideWinder schrieb:

Liege ich hier falsch?

Stell dir einfach vor da würden Dateien geöffnet, da war ich wohl etwas zu faul. Das Problem sollte dann offensichtlich sein.

FileNotFoundException?

Softwarequalität bereitet mir auch Sorgen, da ich die Software letztendlich auch warten und erweitern muss. Hat etwas damit zu tun, dass die Softwarebranche vergleichsweise jung ist. Wir müssen eben die Entwicklung durchmachen, die andere Ingenieure schon hinter sich haben...

L. G.
Steffo

[Shade Of Mine]

Steffo schrieb:

cooky451 schrieb:

SideWinder schrieb:

Liege ich hier falsch?

Stell dir einfach vor da würden Dateien geöffnet, da war ich wohl etwas zu faul. Das Problem sollte dann offensichtlich sein.

FileNotFoundException?

Er meint Resource Leaks.

Das ist ein Standard Beispiel.

[Gast]

Shade Of Mine schrieb:

Steffo schrieb:

cooky451 schrieb:

SideWinder schrieb:

Liege ich hier falsch?

Stell dir einfach vor da würden Dateien geöffnet, da war ich wohl etwas zu faul. Das Problem sollte dann offensichtlich sein.

FileNotFoundException?

Er meint Resource Leaks.

Das ist ein Standard Beispiel.

Achso, du meinst das close() fehlt. Was das wirklich bedeutet, habe ich erst mit C gelernt...

[cooky451]

Steffo schrieb:

Achso, du meinst das close() fehlt. Was das wirklich bedeutet, habe ich erst mit C gelernt...

Nein, das meine ich nicht, lol. Das Problem ist, dass viele Java Programmierer (na ja viele, jedenfalls die, die mir bekannt sind), einfach nicht raffen bzw. nicht daran denken, dass die zweite Datei eine Exception werfen kann, und da deshalb ein try/finally hingehört.

[Mechanics]

cooky451 schrieb:

Mich würde viel mehr einfach mal interessieren, wie viele Leute in eurem Umfeld schon mal MVC gehört haben, simple TMP Programme schreiben können, wissen was RAII ist, wie ein GC etwa funktioniert, sich mehr oder weniger im C++ (oder C) Standard zurecht finden, überhaupt in der lage sind Exception sichere Programme schreiben zu können, ...

Hmm... Das kann ich dir so direkt nicht beantworten. Es kommt drauf an, worauf man Wert legt und was im Endeffekt tatsächlich wichtig ist. Ich würde sagen, jeder der bei uns als C++ Entwickler arbeitet (die anderen Abteilungen kenn ich kaum), ist gut. Die schlechten halten sich bei uns nicht. Wer nicht von Anfang an ordentlich mitarbeiten kann, fliegt ziemlich schnell raus. Also Leute, die nur an der Uni programmieren gelernt haben und sich selber nicht dafür interessieren und daher wenig Erfahrung haben bekommen bei uns nicht die Zeit, sich erstmal jahrelang einzuarbeiten, dafür sind wir zu klein und wir wollen das nicht.
Der Standard interessiert keinen (und mich auch nicht), bis auf 2-3 Leute, die sich hauptsächlich um die Unix Portierungen kümmern. Template Code ist auch sehr selten. Es gibt einige interne Bibliotheken, die sehr stark template lastig sind und die überall verwendet werden, aber normaler Code ist meist komplett template frei.
Bei Design Patterns usw. denk ich mir oft (bzw. habs mir am Anfang gedacht, jetzt hab ich mich dran gewöhnt), es hätte den Kollegen gut getan, etwas Java zu lernen. Da hätte man mehr oder weniger automatisch viele höhere Patterns wie MVC, ORM oder DI kennengelernt. Viele Konstrukte in unserer Software hätte man schon um einiges eleganter designen können. Aber die Leute lernen auch dazu, der Code wird eindeutig besser und durchdachter. Wir haben halt sehr viel Altlasten, viele Features, die als kleine schnelle Erweiterung für 1-2 Kunden gedacht waren, waren dann plötzlich bei hunderten Kunden im Einsatz und dann sind noch etliche andere Features dazugekommen, die darauf aufbauen. Aber der Unterbau, der als klein, billig und unflexibel gedacht war, kann schlecht als Basis für hunderte verschiedener Anforderungen und Erweiterungen dienen. Aber wir nehmen uns auch ab und zu Zeit für Refactoring und dann werden wichtige zentrale Komponenten halt komplett neu designed und entwickelt.
RAII und Exception Safety sind allen ein Begriff. Spätestens seit wir Code Reviews machen.
Jetzt ist halt die Frage, nach welchen Kriterien man entscheidet, ob ein Entwickler gut ist. Für mich ist es völlig unwichtig, auswendig irgendwelche Details aus dem Standard zu kennen oder alles über unlesbaren Template Code aufzubauen. Wir haben eine große und komplexe Software mit sehr vielen und sehr unterschiedlichen Anforderungen, und Entwickler, die damit zurecht kommen, die den Durchblick haben, und die (mittlerweile) auch den Weitblick haben, neue Anforderungen ensprechend umzusetzen, dabei möglichst alle bisherigen Anforderungen, Probleme und Lösungen zu berücksichtigen, und an möglichst viele zukünftige zu denken. Das ist schon weit mehr, ais ich von den meisten anderen Entwicklern behaupten kann, die ich außerhalb der Firma kennengelernt habe.
Ansonsten kenn ich viele, die einfach nur grottenschlecht sind, in jeglicher Hinsicht... Brauch ich denk ich nicht zu vertiefen.
Dann kenn ich paar, die die von dir beschriebenen fachlichen Aspekte gut beherrschen. Weiß aber nicht, ob die wirklich gute Entwickler sind. Das sind meist eher Leute, die sich zu sehr auf die technischen Aspekte konzentrieren und sich für den Rest überhaupt nicht interessieren und auch nicht in der Lage sind, Projekte sauber durchzuziehen.
Welche, die in jeder Hinsicht sehr gut sind, kenne ich persönlich nicht (zähle mich selber auch nicht dazu). Keine Ahnung, obs die wirklich gibt, und ob die Welt sie wirklich braucht ^^ Würde grob sagen, es gibt Techniker, die sich rein für die technischen Aspekte interessieren und die aus dem Effeff beherrschen, und es gibt die "Anderen" (hab grad keine Idee, wie man sie bezeichnen könnte), die sich eher für interessante Probleme und Problemlösungen interessieren und die Technik eher als Werkzeug und Mittel zum Zweck sehen und sich da nicht übertrieben reinsteigern. Und halt viele dazwischen (entweder welche, die sich ein bisschen für beides interessieren, oder auch für beides überhaupt nicht interessieren).

[Jodocus]

Mechanics schrieb:

...

Augenkrebs.

[Xin]

cooky451 schrieb:

Ja ja, Java ist doof, hatten wir doch schon. Nicht zu weit abweichen. Die Frage war eigentlich, wie bei euch (ich nehme einfach mal an, dass einige hier in Firmen arbeiten die Software entwickelt) so der Eindruck ist. Wenn ihr Code von Kollegen lest, müsst ihr euch dann fragen wie die denn an ihren Job gekommen sind?

Beispiel aus der Praxis: Eine Dame entwickelt eine Routine, die ein char-Array fester Größe, welches einen Dateinamen enthält, um eine Dateiendung erweitert.
Ich frage sie, was denn passiert, wenn die Erweiterung (sagen wir .txt) an einen Dateinamen angehängt wird der (Arraygröße-2) groß ist. Antwort: Das ist noch nie vorgekommen.
Da hilft nur Lächeln, Problembewusstsein schaffen und am Abend die Zehennägel wieder glatt bügeln.

Zum Thema "Java ist doof"... ich beschloss nachdem ich Java gelernt habe, keinen Job mit Java anzunehmen. Das habe ich zwei Firmen durchgehalten, dann war da ein verlockendes Angebot. Alle meine Vorurteile wurden binnen Monaten bestätigt und ich wurde wieder C++-Entwickler und debuggte verbuggten Java-Code. Dann wechselte ich die Stelle.

cooky451 schrieb:

Spielen Standards bei euch eine Rolle, oder wird einfach geliefert was funktioniert? Darf man überhaupt etwas koplexeren Templatecode schreiben, oder beschweren sich die Kollegen dann, wenn sie das nicht lesen können? Achtet man bei euch auf Exception Sicherheit?

In der Firma: Templates ja, aber bitte nicht zuuuu kompliziert. Aber das Niveau steigt deutlich. Ich würde es in meinem direkten Umfeld durchaus als 'gut' bezeichnen, teilweise zu gut, da wir auch zeitkritische Sachen entwickeln und ich da teilweise andere Vorstellungen habe. Da liegt mir der Kompromiss aus Optimierung und gutem Design schon zu sehr beim Design.
Es ist auch schon zweimal vorgekommen, das Code von mir weggeworfen wurde, weil mein Code zwar das Problem löste, aber angeblich unverständlich war. Der Kollege entwickelte den Code dann komplett neu und da er das gleiche Problem löste, glich der Code dann auch meinem ziemlich, nun war er aber natürlich viel verständlicher, schließlich hatte er ihn selbst geschrieben.
Beim zweiten Mal waren die Klassen Model, View und Control absolut unverständlich und wurde daher ersetzt. Nur die die komplexeren Berechnungen, sehen noch stark nach meinem Code aus. Nach der Neuentwicklung entstand eine deutlich allgemeinverständlichere Architektur, die sich in den Klassen Model, View und Controller (<- man beachte das -er hinten) widerspiegelt, wobei aber bereits festgestellt wurde, dass einige Datenmember von View eigentlich ins Model gehören... Manches muss man einfach mit Humor nehmen.

Zur Frage mit dem Standards habe ich ein Zitat, ich schreibe so etwas gerne mit.
> Entwickler: "Haben wir da keinen Standard?"
> Entwicklungsleiter (ernstgemeint): "Wir haben da viele Standards."

Die Software ist älter und hat diverse Entwicklungsleiter und deren Vorstellungen durchlebt. Wir sprechen von sogenannten Ländern. Man bemüht sich, den Code an die Umgebung anzupassen - andere Länder, andere Sitten. Neuer Code wird nach Standard geschrieben - also nach dem, was halt derzeit Standard ist.

Exceptionhandling in C++ ist eher zurückhaltend. Die meisten Datenhaltungs-Objekte sind allerdings auch vergleichsweise einfacherer Natur, soviele Ausnahmen gibt's da eigentlich nicht. Spaßiger ist halt, was man damit macht. Die Methoden liefern entsprechende Rückgabecodes, aber eben keine Exceptions. Ansonsten ist die Software darauf ausgelegt, keine Daten zu verlieren. Abstürze sind sehr selten, sogar erstaunlich selten, aber selbst dann startet man die Software neu und arbeitet von da aus eben weiter. Normalerweise ohne Datenverlust.
Was das Kriterium angeht, ist die Software eigentlich top, kann man anders nicht sagen. Sowas wünschte ich mir von einiger anderer Software auch.

Privat mache ich Ableitungen von Template-Templates, alles, was das Herz begehrt. Exceptionbehandlung weniger, lieber Factories, die entweder was zurückliefern oder einen Null-Pointer. Exceptions sind in meinen Augen ein Ausnahmekonzept, das ich auch nur ausnahmsweise benutze.

[Cpp_Junky]

Xin schrieb:

cooky451 schrieb:

Ja ja, Java ist doof, hatten wir doch schon. Nicht zu weit abweichen. Die Frage war eigentlich, wie bei euch (ich nehme einfach mal an, dass einige hier in Firmen arbeiten die Software entwickelt) so der Eindruck ist. Wenn ihr Code von Kollegen lest, müsst ihr euch dann fragen wie die denn an ihren Job gekommen sind?

Beispiel aus der Praxis: Eine Dame entwickelt eine Routine, die ein char-Array fester Größe, welches einen Dateinamen enthält, um eine Dateiendung erweitert.
Ich frage sie, was denn passiert, wenn die Erweiterung (sagen wir .txt) an einen Dateinamen angehängt wird der (Arraygröße-2) groß ist. Antwort: Das ist noch nie vorgekommen.
Da hilft nur Lächeln, Problembewusstsein schaffen und am Abend die Zehennägel wieder glatt bügeln...

Auch "lustig" ist, wenn man einen Anruf bekommt das die Eingabe z.B. des Namens nicht funktioniert und man sieht dann beim Nachgucken die Fehlermeldung "ORA-01401: Inserted value too large for column" ... "Tut uns leid Herr sowieso, legen Sie sich bitte einen kürzeren Namen zu"
Nun gehen natürlich alle Alarmglocken an, das Datenmodell wird per "Instant-Eingriff" (ALTER TABLE xyz ) geändert und gut... Nein Murphys Law greift natürlich ein und ein Dominoeffekt an ungeahnten Nebenwirkungen zwischen Datenmodell, Geschäftslogik und GUI setzt ein, mit denen fünf Entwickler den Rest der Woche beschäftigt sind nur deshalb weil irgendwer meinte, die vom BWLer künstlich verknappte Entwicklungszeit lässt sich beim Datenmodell wieder reinholen (Das mit dem Namen ist natürlich schon krass, aber sowas hab ich durchaus schon erlebt)

[knivil]

Ach Leute, ein Jammerthread oder Selbstbeweiraeucherung? Nicht jeder kann alles, auch in meiner Firma scheint das Programmierniveau niedrig, wenn idiomatisches C++ als Messlatte angelegt wird. Der Quelltext ist grauenhaft und Bugfixing ist die Hoelle. Aber trotzdem: Code von Person A oder B wuerde ich ungesehen vertrauen. Softwarequalitaet besteht nicht nur aus schoenem Design oder klarem verstaendlichen Code.

Leider ist hier fuer einige C++ zur Religion geworden. Loesungen in C sind nicht mehr denkbar, da smart_point, RAII, Templates oder Objekte fehlen. Alle jene, welche ohne diese Features programmieren, werden herabgestuft. Ich habe kein Problem damit, wenn der "C-Quelltext" mit einem C++ Compiler uebersetzt wird.

PS: Ja, ich bin dagegen.

[Gast]

cooky, ja es ist echt mau in meinem Umfeld. Das Niveau, das wir versuchen im C++ Forum zu erreichen, habe ich noch nie in meinem beruflichen und studentischen Leben gesehen.

Jeder programmiert so wie er lustig ist und jeder denkt er könne C++. Es hängt einfach damit zusammen, dass Leute wie wir leidenschaftlich sich mit der Sprache beschäftigen, der Rest lernt es weil er es lernen oder können muss. Die Zeit für die Sprache nehmen sich diese Leute nicht und können es auch gar nicht.

[phcn.fraggle]

cooky451 schrieb:

Hi,
mir fällt immer mehr auf, dass meine Vorstellung von "programmieren können" und die von den meisten anderen ziemlich weit auseinander geht. In meinem Umfeld interessiert sich eigentlich niemand wirklich für den Standard, Patterns, etc. Das bleibt größtenteils auch so bei Studenten in höheren Semestern, und viele Profs oder Angestellte die sich mit so etwas beschäftigen scheint es auch nicht zu geben.

Bei Studenten würde ich sagen das viele auch im Grundstudium vom Programmieren mehr oder weniger abgeschreckt werden. Dazu kommt auch das ein bestimmter Teil vorher noch nie wirklich was mit Programmieren oder Informatik zu tun gehabt hat. Deswegen reicht es für diese Leute wenn sie nur irgendwie die Programmier-Übungen oder Klausuren bestehen. Dementsprechend sind dann die Kenntnisse in der jeweiligen Programmiersprache die sie "können".

"Hauptsache es läuft"

[Gregor]

Xin schrieb:

Seit bald 30 Jahre programmiere ich, aber was RAII ist, habe ich vor etwa 2 Jahren gelernt. Frag mich nicht wie lange ich es schon benutze. Für mich ist es durchaus ein Problem, dass für jede Technik alle 5 Jahre ein neues Buzzword rauskommt. Teilweise können Informatiker nicht miteinander reden, weil sie erstmal damit beschäftigt sind, ihr Vokabular abzugleichen.

Viele gute Programmierer haben gelernt, was funktioniert. Sie vermeiden zu tun, was sie nicht kennen. Ich kann Dir nicht die Namen der Design Pattern nicht runterbeten, aber als ich mir das GoF-Buch durchgelesen habe, stellte ich fest, dass ich das soweit schon alles kenne. Trotzdem eine gute Zusammenfassung. Diese Programmierer, die direkt nach Pattern arbeiten, sind fachlich hochkompetent und haben gleichzeitig Scheuklappen an, weil alles was sie nicht gelernt haben, auch nicht denkbar ist.

Mit langjaehriger Erfahrung lernt man natuerlich jede Menge Konzepte kennen, die man dann auch nutzt. Und diese Konzepte werden dann halt irgendwann von irgendwelchen Leuten als "Pattern" benannt. Als Standardloesungen fuer bestimmte Probleme. Natuerlich ist der Nutzen dieser Namensgebung fuer Leute, die derartiges auf natuerliche Weise kennengelernt haben, recht gering. Es bringt ihnen praktisch nur etwas bei der Kommunikation mit anderen Leuten, die die entsprechende Fachsprache auch sprechen.

Bei Studenten ist das aber etwas anderes. Die haben keinen Programmierhintergrund von einigen Jahrzehnten und trotzdem sollen sie moeglichst schnell guten Code schreiben koennen. Deswegen muss man ihnen diese Konzepte explizit naeherbringen und dafuer muss man sie entsprechend formal definieren. Aus meiner Sicht macht es also einen Unterschied, wer einen auf die Frage nach Patterns eine ablehnende Antwort gibt. Spricht aus demjenigen Erfahrung oder einfach fehlendes Interesse?

[asc]

knivil schrieb:

Nicht jeder kann alles...

Das ist richtig und auch okay wenn man bereit ist sich weiteres Wissen anzueignen. Ich kenne es aber aus einigen Firmen wie folgt: Wenn jemand der etwas zu sagen hat nicht mit deinen Code (weil für ihn 20 Jahre zu neu) klar kommt, blockiert er alles von dir. Und statt dem C++ std::vector soll man bloss seine Strukturen (mit 5fach-Zeigern etc. [JA, das ist ein Beispiel aus der Praxis...]) verwenden, weil der std::vector ja sooo langsam ist - zumindest hat er das gehört.

Ich mag nicht der beste Softwareentwickler sein, aber wenn ich von Leuten wie den oberen dann auch ständig hören muss wie langsam ich bin, weil die etwas in 3 Tagen zusammenklatschen, wofür ich 3 Wochen brauche mag das auf dem ersten Blick so stimmen, wenn bei mir vielleicht noch 1 Woche an Fehlerkorrekturen drauf geht wo selbiger 2 Monate braucht bis es so läuft wie der Kunde wünscht, kann ich nur sagen: Nicht selten zählt sich Nachdenken, sauberes Design und sauberer Code doch aus.

knivil schrieb:

...Der Quelltext ist grauenhaft und Bugfixing ist die Hoelle. Aber trotzdem: Code von Person A oder B wuerde ich ungesehen vertrauen...

In dem Fall würde ich dem Code niemals vertrauen. Man programmiert in den meisten Firmen nicht für sich alleine; der Code muss jederzeit auch von Anderen übernommen werden können. Da ist ein gewisses gemeinsames Grundwissen nicht verkehrt, und wenn das fehlt so sollte es eigentlich durchaus möglich sein, das man sich gegenseitig etwas beibringt.

knivil schrieb:

Softwarequalitaet besteht nicht nur aus schoenem Design oder klarem verstaendlichen Code.

Es gibt natürlich immer auch Negativextreme wie z.B. beim Design das Overengineering. Was wiederum lesbaren Code angeht habe ich noch kein Negativbeispiel gesehen (Überpflasterung mit Kommentaren ist kein lesbarer Code).

Für mich kann ein Stück Software nur dann auch wirklich "Qualität" bedeuten, wenn es zumindest im Grundsatz verständlich bleibt. Code den niemand außer einem selbst verstehen kann ist niemals inakzeptabel (außer vielleicht in einer 1-Mann Klitsche).

[knivil]

Code den niemand außer einem selbst verstehen kann ist niemals inakzeptabel

Code den nur einer versteht gibt es nicht. Sich einzuarbeiten ist manchmal ungemein schwieriger aber machbar.

Nicht selten zählt sich Nachdenken, sauberes Design und sauberer Code doch aus.

Leider ist das Management nicht so vorausschauend.

fehlt so sollte es eigentlich durchaus möglich sein, das man sich gegenseitig etwas beibringt

Es fehlt nicht, es aendert sich. Auch ist es schwer jemanden von 15 Jahren Gewohnheit in dieser Firma "umzulernen".

[Xin]

Gregor schrieb:

Xin schrieb:

Seit bald 30 Jahre programmiere ich, aber was RAII ist, habe ich vor etwa 2 Jahren gelernt. Frag mich nicht wie lange ich es schon benutze. Für mich ist es durchaus ein Problem, dass für jede Technik alle 5 Jahre ein neues Buzzword rauskommt. Teilweise können Informatiker nicht miteinander reden, weil sie erstmal damit beschäftigt sind, ihr Vokabular abzugleichen.

Viele gute Programmierer haben gelernt, was funktioniert. Sie vermeiden zu tun, was sie nicht kennen. Ich kann Dir nicht die Namen der Design Pattern nicht runterbeten, aber als ich mir das GoF-Buch durchgelesen habe, stellte ich fest, dass ich das soweit schon alles kenne. Trotzdem eine gute Zusammenfassung. Diese Programmierer, die direkt nach Pattern arbeiten, sind fachlich hochkompetent und haben gleichzeitig Scheuklappen an, weil alles was sie nicht gelernt haben, auch nicht denkbar ist.

Mit langjaehriger Erfahrung lernt man natuerlich jede Menge Konzepte kennen, die man dann auch nutzt. Und diese Konzepte werden dann halt irgendwann von irgendwelchen Leuten als "Pattern" benannt. Als Standardloesungen fuer bestimmte Probleme. Natuerlich ist der Nutzen dieser Namensgebung fuer Leute, die derartiges auf natuerliche Weise kennengelernt haben, recht gering. Es bringt ihnen praktisch nur etwas bei der Kommunikation mit anderen Leuten, die die entsprechende Fachsprache auch sprechen.

Richtig, wir sprachen eigentlich immer davon, dass die Variablen/Objekte auf dem Stack liegen. Irgendwann hieß das dann RAII und ich wunderte mich, dass es eine neue Technik gibt und stelle fest, dass RAII auch nur Variablen auf den Stack legt...
Bei vielen Dingen kommen halt im 5 Jahres Takt neue Buzzwords raus und man wundert sich immer wieder, was das für eine Aktion ist, um schlussendlich festzustellen, dass es ein alter Hut ist.

Gregor schrieb:

Bei Studenten ist das aber etwas anderes. Die haben keinen Programmierhintergrund von einigen Jahrzehnten und trotzdem sollen sie moeglichst schnell guten Code schreiben koennen. Deswegen muss man ihnen diese Konzepte explizit naeherbringen und dafuer muss man sie entsprechend formal definieren. Aus meiner Sicht macht es also einen Unterschied, wer einen auf die Frage nach Patterns eine ablehnende Antwort gibt. Spricht aus demjenigen Erfahrung oder einfach fehlendes Interesse?

Mit formalen Definitionen erreiche ich in der Regel nur Verwirrung. Wenn die Leute verstanden haben, was lokale Variablen sind und wann sie nicht mehr sind, dann sind Objekte auf dem Stack eine logische Schlussfolgerung.

Formal definierte Aussagen sind auch gut, aber imho erst, nachdem sie "begriffen" wurden, um das Begriffene dann auch scharf zu definieren. Eine scharfe Abgrenzung von einem Gedankengebilde hingegen erscheint mir eher ein solides Fundament für ein Luftschloss zu sein.

[SeppJ]

Xin schrieb:

Richtig, wir sprachen eigentlich immer davon, dass die Variablen/Objekte auf dem Stack liegen. Irgendwann hieß das dann RAII und ich wunderte mich, dass es eine neue Technik gibt und stelle fest, dass RAII auch nur Variablen auf den Stack legt...

Entweder hast du das Beispiel schlecht gewählt oder du hast RAII selber nicht verstanden. Nicht jeder Fachbegriff ist ein Buzzword für etwas altbekanntes.

[Xin]

SeppJ schrieb:

Xin schrieb:

Richtig, wir sprachen eigentlich immer davon, dass die Variablen/Objekte auf dem Stack liegen. Irgendwann hieß das dann RAII und ich wunderte mich, dass es eine neue Technik gibt und stelle fest, dass RAII auch nur Variablen auf den Stack legt...

Entweder hast du das Beispiel schlecht gewählt oder du hast RAII selber nicht verstanden.

Aktuell gehe ich davon aus, dass das Beispiel okay ist und ich RAII verstanden habe. Aber ich lasse mich gerne eines Besseren belehren, wenn Du was besseres im Angebot hast.

Die Klasse, die die benötigten Resourcen bereitstellt, wird als lokale Variable auf dem Stack instantiiert und initialisiert. In der Funktion verwendet man die Resource über den entsprechenden Variablennamen und mit Verlassen des Scopes wird die Resource über den Destruktor abgebaut.

Eine Variable/Objekt auf'm Stack. Was habe ich falsch gewählt oder falsch verstanden?