C++ im Wandel

[sheel]

Mal etwas Offtopic von mir...

was halten die C++ - Kenner hier von der Richtung, in die die Sprache entwickelt wird?

...

C++11 war ja im Großen und Ganzen wirklich nett. Aber imho bringt jede neue Standardversion (14, 17, das kommende 20...) mehr und mehr Unsinn - und es könnte ruhig mal wieder aufgehört werden, an der Sprache herumzudoktern.

Zwei grandiose und komplett unnötige "Fails", die mir gerade einfallen, wären:
a) Der relativ neue Variablentyp "byte". Ist es ein Byte groß und speichert Werte von 0 bis 255? Nein, in C++ ist beides anders.
b) Es ist eine Änderung geplant, dass (unter bisher noch unbekannten Bedingungen) 4294967295 "kleiner" als 0 sein kann. Und zwar gerade "nicht" weil irgendwas zu signed konvertiert wird. Wtf.

...

Und da ist natürlich auch noch das anscheinend unwichtige Problem, dass "C++ lernen" immer mehr zur Lebensaufgabe wird

Von riesigen Umbauten wie Modulen fang ich wohl besser nicht an.

 

[cwriter]

was halten die C++ - Kenner hier von der Richtung, in die die Sprache entwickelt wird?

Es ist ein zweischneidiges Schwert. Manche Dinge, die in Entwicklung sind, wären echt nett, z.B. transactional memory
Anderes wiederum ist völlig sinnbefreit (std::iota, std::byte).

b) Es ist eine Änderung geplant, dass (unter bisher noch unbekannten Bedingungen) 4294967295 "kleiner" als 0 sein kann. Und zwar gerade "nicht" weil irgendwas zu signed konvertiert wird. Wtf.

Hö? Erinnert mich an die Leute, die sagen, dass abs() eine schlechte Funktion ist, weil int abs(int i) { return -i; } bei INT_MIN einen Overflow hat. Dass man das mit einem Rückgabewert von unsigned int beheben kann, ist da egal.
Falls die Idee ist, -1 zu fangen: Dafür gibt es 0xffffffff.

Und da ist natürlich auch noch das anscheinend unwichtige Problem, dass "C++ lernen" immer mehr zur Lebensaufgabe wird

Ich denke, kein C++-Programmierer nutzt alles existente C++, aber ja: Wenn man Code lesen will, kommt man sehr schnell an noch nie Gesehenes. Hach, die unschuldige Einfachheit von C++89.

Ich sehe eher ein Grundsatzproblem: C++ ist wirklich gross geworden. So gross, dass man es nicht für Low-Level einsetzen kann (neben anderen Problemen wie RTTI). Der Standard umfasst sehr viel nutzloses Zeug (wie std::byte), statt die Wurzel des Problems zu packen und z.B. Bit-Order festlegen zu können.

Ich denke nicht, dass C++ zu einer schlechteren Sprache wird. Ich denke aber, dass dem Komitee nicht ganz klar zu sein scheint, in welche Richtung sie gehen wollen: Universalsprache oder Performancesprache.
Grundsätzlich halte ich es mit neuen Features immer so: Sie sind gut, kann man sie benutzen (wie z.B. [[nodiscard]]). Sind sie sinnlos/schlecht, benutzt man halt etwas anderes.
Nur einen C++-Compiler mit STL und Co. würde ich heutzutage nicht mehr selbst machen wollen.

Von riesigen Umbauten wie Modulen fang ich wohl besser nicht an.

Ich hoffe, die kommen nicht. Die Cyclic Inheritence ist bei C++ ja noch schlimmer, da auch die Member nicht zyklisch sein dürfen. Das momentane System hat zwar durchaus Macken, aber es zwingt einen zu einigermassen sauberem Code.

cwriter

 

[Technipion]

Meine Meinung dazu ist leider auch noch nicht so ganz gefestigt. Ich habe beruflich viel mit der Datenverarbeitung in der Teilchenphysik zu tun, und dort kommen vor allem C, C++ und Python zum Einsatz. In letzter Zeit auch immer öfter Java. C ist imho DIE vielseitigste Sprache, die es im Moment gibt. Ausreichend low-level, ausreichend high-level, aber nicht zu kompliziert zu lesen und ziemlich leichtgewichtig. Aber natürlich hat jede Sprache ihre Anwendungen. Ich möchte auch Python nicht mehr missen müssen.
Von C++ bin ich schon sehr lange ein großer Fan, für mich war es immer die "Erweiterung" von C (liegt ja gewisserweise im Namen). Trotzdem ist viel von dem alten Kram bis heute noch in C. Teilweise meckern die Distros wenn man nur ein int im Kopf einer for-Schleife definieren will
Als dann C++11 rauskam war ich ziemlich happy darüber und habe mich auf die neuen Features gefreut. Auch wenn es ewig gedauert hat bis ich das doofe auto endlich gecheckt hatte. Aber der wichtigste Punkt war: Es tut sich noch was. Die Sprache lebt noch, und jemand arbeitet aktiv daran. Und naja, es wurde ehrlichgesagt auch Zeit. Also C++11 habe ich absolut begrüßt, und sehr gefallen hat mir die (nahezu) vollständige abwärtskompatibilität. (Sehr wichtig! Müssen sie unbedingt weiterhin einhalten!)
Naja dann kam C++14 und habe mir so gedacht: Komm, das waren viele Änderungen auf einmal, und die wollen jetzt bloß noch etwas nachbessern... was soll's. Aber mittlerweile denke ich auch das Komitee will jetzt irgendwas überkompensieren. Alle 3 Jahre ist einfach zu oft. Vielleicht hätte man alle 5 oder 8 Jahre anstreben sollen.

Obwohl wir alle dazu angehalten sind das "neue" C++11 zu benutzen, sind die meisten Quellcodes bunt durcheinander gewürfelt. Manche nutzen auto, manche nicht. Manche benutzen Verschiebesemantik, andere nicht. Und es gibt so viele Stile wie es Programmierer gibt (und gab). Richtiger Spaghetticode teilweise.

Manchmal frage ich mich, ob das "neue" C++ (ist ja nicht neu, ist der de-facto Standard) nicht vielleicht im Geheimen den Konkurrenten (Java, Python, etc.) ein kleinwenig nacheifert. Wäre meines Erachtens schade. Auf jeden Fall müsste man eine klare Linie fahren.

Gruß Technipion

 

[sheel]

Danke schonmal für die Antworten ...

Falls die Idee ist, -1 zu fangen: Dafür gibt es 0xffffffff.

Ja, es hat mit Underflow zu tun, mehr Details zu dem angeblichen Problem weiß ich aber auch nicht (und nein, eigentlich ist 0xffffffff nicht portabel )
Nur scheint das Kommitee zu vergessen, dass C++ nicht Mathematik ist. Variablen haben eben Eigenschaften aufgrund ihrer Größe usw., C++ hat genaue Regeln zu impliziten Umwandlungen bei Operationen mit verschiedenen Typen usw., und die ganzen bisherigen Regeln mit einer Ausnahme für irgendeinen seltsamen Spezialfall zu durchbrechen ist ...

Ich denke, kein C++-Programmierer nutzt alles existente C++,

Wie auch

So gross, dass man es nicht für Low-Level einsetzen kann

Was irgendwelche Microcontroller angeht war aber das erste C++ auch schon ein großer Schritt weg. C kann man sehr "verbiegen" - C++ hat aber ein paar Garantien im Standard die sich auch vielen Geräten einfach nicht erfüllen lassen.

neben anderen Problemen wie RTTI

Btw., es gibt Bestrebungen in Richtung von vollen Compile-time Reflections (und evt. später auch für dynamischere Sachen Richtung virtual-Auflösung in Klassen usw.)
Klingt derzeit nach einer von den besseren Änderungen (sehr sogar) - solang dafür nichts anderes grob kaputtgemacht wird.

Ich denke nicht, dass C++ zu einer schlechteren Sprache wird. Ich denke aber, dass dem Komitee nicht ganz klar zu sein scheint, in welche Richtung sie gehen wollen:

Jedes Mitglied in eine andere

Sind sie sinnlos/schlecht, benutzt man halt etwas anderes.

Zum Glück wird meistens hoher Wert auf Abwärtskompatibilität gelegt, ja ...

Ich hoffe, die kommen nicht

Leider bin ich mir ziemlich sicher, dass das keiner mehr aufhalten kann. Auch wenn es ziemlichen Widerstand dagegen gibt (speziell außerhalb vom Komittee).
... aber, wie schon im vorderen Punkt, keiner zwingt einen zum Verwenden.
Und beim Vergleichen vom Aufwand (Einlernen, Tools, Code) mit dem Nutzen ist die Möglichkeit jedenfalls da, dass das eine Totgeburt wird.Btw., federführend ist ein MS-Mitarbeiter. Natürlich.

Obwohl wir alle dazu angehalten sind das "neue" C++11 zu benutzen

Warum

Sicher gibt es manche "Blasen", wo man mit einer anderen Meinung virtull totgeprügelt wird, aber sonst ...
Und bisher hat noch keines der nennenswerten neuen C++-Features irgendein anderes "vollständig" ersetzt. Es gibt immer Fälle, wo das alte besser (oder sogar das einzig richtige) ist. Und natürlich spielt auch der Stil eine große Rolle...

Manche nutzen auto, manche nicht. Manche benutzen Verschiebesemantik, andere nicht.

...und manche benutzen es nur dann, wenn es etwas einfacher/schneller/etc. macht. Imho ist genau das der Sinn von einem Werkzeug, und nicht die krampfhafte Verwendung wo immer es auch geht, auch wenn dadurch alles umständlicher wird.

Manchmal frage ich mich, ob das "neue" C++ (ist ja nicht neu, ist der de-facto Standard) nicht vielleicht im Geheimen den Konkurrenten (Java, Python, etc.) ein kleinwenig nacheifert.

Naja, alle großen Sprachen beeinflussen sich irgendwie; das war schon immer so. Und persönlich seh ich auch kein Problem darin, die guten Teile von anderen Sprachen als Anregung zu nehmen wie man das eigene Ding machen könnte.

 

[cwriter]

Ja, es hat mit Underflow zu tun, mehr Details zu dem angeblichen Problem weiß ich aber auch nicht (und nein, eigentlich ist 0xffffffff nicht portabel )

Dann geht halt sowas wie INT_MAX/LONG_MAX und co. (Wobei: Zeig mir ein modernes System, das nicht auf two's-complement basiert...).
Das Problem greift aber auch tiefer: CPUs werden nicht plötzlich beginnen, ihre Definition zu ändern. Die Sign/Overflow/Carry-Flags werden ja nach anderen Regeln gesetzt.

Was irgendwelche Microcontroller angeht war aber das erste C++ auch schon ein großer Schritt weg. C kann man sehr "verbiegen" - C++ hat aber ein paar Garantien im Standard die sich auch vielen Geräten einfach nicht erfüllen lassen.

Ja, aber manchmal vermisse ich auf Lowlevel echt Klassen oder zumindest namespaces. Alles mit defines vollzupflastern ist mir ein bisschen zu mühsam, und enums übernehmen ja auch den Elternscope. Mehr bräuchte es nicht, aber wenn man sich einmal durch einige Kerneldriver liest, bestehen die ersten 300 Zeilen aus defines, von denen man nicht genau weiss, zu welchem Registerfile sie jetzt gehören, dann wird immer mit Offsets gearbeitet (Registerfile_base + register_offset) usw. Und warum? Weil der C-Standard nicht stabil genug ist, um z.B. bitfields und Konsorten für so etwas verwenden zu können.
Sowas wie das hier wäre echt etwas nettes: https://www.systems.ethz.ch/sites/default/files/file/aos2012/Reading/week3/TN-002-Mackerel.pdf
Aber das kommt wohl nie in den Standard.

Btw., es gibt Bestrebungen in Richtung von vollen Compile-time Reflections (und evt. später auch für dynamischere Sachen Richtung virtual-Auflösung in Klassen usw.)
Klingt derzeit nach einer von den besseren Änderungen (sehr sogar) - solang dafür nichts anderes grob kaputtgemacht wird.

Das wäre in der Tat sehr interessant.

Btw., federführend ist ein MS-Mitarbeiter. Natürlich.

Herb Sutter oder Lavadej(?, finde ihn gerade nicht) ? Wobei, wenn VS das standardmässig einführt, dann wird es ziemlich sicher ein Standard, zumindest unter Windows.

Zum Glück wird meistens hoher Wert auf Abwärtskompatibilität gelegt, ja ...

Ist zwar schon etwas länger her, aber: export (bzw. die Entfernung davon)

Manche nutzen auto, manche nicht.

...und manche benutzen es nur dann, wenn es etwas einfacher/schneller/etc. macht. Imho ist genau das der Sinn von einem Werkzeug, und nicht die krampfhafte Verwendung wo immer es auch geht, auch wenn dadurch alles umständlicher wird.

Auto kann beissen. Wenn ich in irgendeiner Form auf den Typ angewiesen bin, dann nehme ich den expliziten Typ. Aber auto ist extrem praktisch bei Templates. Manchmal spart man sich damit schon 20 Zeichen lange Typen.


cwriter

 

[sheel]

Herb Sutter oder Lavadej(?, finde ihn gerade nicht) ?

Gabriel Dos Reis

 

[Technipion]

Btw., federführend ist ein MS-Mitarbeiter. Natürlich.

Ich glaube leider nicht, dass sich das jemals wieder ändern wird. Die Industrie hat ja überall ihre Finger drin. Das ist prinzipiell nichts schlechtes, solange der Herr MS Entwickler auch wirklich an einem Standard interessiert ist, und keinen Alleingang unternimmt (jopp, ich bin vertraut mit der Vergangenheit).

Was z.B. die Geschichte mit auto angeht, da ziehe ich jetzt ganz dreist das Buch "Effective Modern C++" von Scott Meyers heran. Auf Seite 38 schreibt er: "auto variables have their type deduced from their initializer, so they must be initialized." Ist nur eines von vielen Beispielen, aber es gibt zumindest Motivatoren auto zu benutzen. Das macht natürlich "altes" C++ nicht ungültig, es ist lediglich eine neue Art Stil. Und wie schon gesagt, es gibt wohl so viele Stile wie es Programmierer gibt. Wir sind jedenfalls dazu angehalten. Unterm Strich ist es besser es gibt in einem größeren Projekt Vorschriften (auch wenn sie eigenartig sind), als dass jeder macht was er will. Meiner Hand sind deshalb schon solche Zeilen entsprungen:

auto i = (int)0;

Man kann sich natürlich darüber streiten...
Wo auto definitiv ein Vorteil ist, ist bei den berüchtigten foreach-Schleifen (mittlerweile werden sie range-based for loops genannt, am Anfang hießen sie aber glaube ich alle noch foreach):

langer_und_ermüdender_typ a;
// fülle a

for (const auto& i : a) {
    // benutze i
}

Ich hatte leider noch keine Zeit mich richtig in C++17 einzulesen (chronische Zeitknappheit ), aber ich habe aufgeschnappt, dass da sogar folgendes gehen soll:

std::map<foo, bar> test = { /* Zeugs */ };

for (const auto& [key, value] : test) {
    std::cout << key << " = " << value << std::endl;
}

Damit sind wir dann ja schon verdammt nahe an der pythonischen Variante dran:

a_dict = {'a': 1, 'b': 2, 'c': 3}

for key, value in a_dict.items():
    print(key, '=', value)

Wie ich schon sagte, ich begrüße es sehr dass aktiv an der Sprache entwickelt wird. Und obiger Code ist natürlich in C++ enorm (!!) schneller als in Python, dem Compiler macht niemand was vor. Und prinzipell finde ich es auch gut, dass das Komitee ständig nach neuen Funktionen sucht um die Sprache zu ergänzen - SOLANGE sie abwärtskompatibel bleiben. Ich glaube die Diskussion läuft eigentlich eher auf die Frage raus: Muss die Sprache alle 3 Jahre erneuert werden? Bzw. muss man dann mit Gewalt alle neuen Features (teilweise noch unausgereift) reindrücken?

Wie ich schon sagte, ich glaube das Komitee eifert dann ein wenig Java/Python/etc. nach. In Python z.B. kommen sehr regelmäßig neue Versionen heraus (in Python3, Python2 wird nur zur Abwärtskompatibilität behalten - sehr lobenswert). Ist ja nichts schlechtes, aber braucht C++ das?

Und warum hauen die soetwas wie std::byte rein? Es wirkt einfach nicht komplett durchdacht...
Unser einziger Trost ist wohl, dass die Einführung eines std::byte nichts kaputt macht. Und imho braucht das Komitee nicht auf Teufel komm raus einen neuen Standard verabschieden, die Konkurrenz ist auch nicht schneller. Man bedenke nur, dass Java erst in Version 8 ein switch-Statement erhalten hat.
Wie wir alle wissen, bleiben die meisten Menschen bei der Erlernung von C++ spätestens bei Templates hängen, und kommen gar nicht erst zu auto und co. Von daher finde ich es viel wichtiger den Neulingen die Konzepte von Clean Code beizubringen, als ihnen unbedingt C++17 Features einzutrichtern. Und "klassisches" C++ ist nicht schlechter, wenn es beherrscht wird.

Ich freue mich aber immer über eine Diskussion über die Sprache, nur so entwickelt sie sich schließlich weiter!

Gruß Technipion

 

[sheel]

Ich glaube leider nicht, dass sich das jemals wieder ändern wird. Die Industrie hat ja überall ihre Finger drin. Das ist prinzipiell nichts schlechtes, solange der Herr MS Entwickler auch wirklich an einem Standard interessiert ist, und keinen Alleingang unternimmt (jopp, ich bin vertraut mit der Vergangenheit).

Ich will ja auch nicht sagen, dass es schlecht ist - aber ja, eben keine MS-Features im IE6-Style (nur ein Beispiel von vielen)

Ich hatte leider noch keine Zeit mich richtig in C++17 einzulesen (chronische Zeitknappheit )

So wirklich solide, wie ich es gern hätte, ging auch bei mir noch nicht

aber ich habe aufgeschnappt, dass da sogar folgendes gehen soll:

Ja

Damit sind wir dann ja schon verdammt nahe an der pythonischen Variante dran:

Was da zB. indirekt sichtbar ist, was in C++ derzeit nicht möglich ist (denk ich zumindest): Strukturen/Klassen mit mehreren Memberwerten zu initialisieren und dabei immer den Membernamen anzugeben (statt ein paar Werte einfach so hinschreiben und "raten" ob die Reihenfolge passt).

Und warum hauen die soetwas wie std::byte rein? Es wirkt einfach nicht komplett durchdacht...

So wie zB. vector<bool> und ziemlich viel anderes...

Speziell Byte macht im Kontext vom C++-Standard ja eigentlich sehr viel Sinn - nur muss das Komitee sich endlich mal kollektiv klar werden, dass 99.9999% der Programmierer was anderes unter Byte verstehen.

Von daher finde ich es viel wichtiger den Neulingen die Konzepte von Clean Code beizubringen, als ihnen unbedingt C++17 Features einzutrichtern.

Für letzteres ist eine neue Arbeitsgruppe im Komittee geplant (oder vielleicht gibts es sie ja inzwischen schon...)

 

[cwriter]

Ich führe die Diskussion mal weiter, da ich das einfach loswerden muss:

Ich habe mittlerweile Qt Creator 4.6rc installiert, wo mit Clang5.1 ein "besseres" Code Model vorhanden ist. "Besser", weil es 1.5GB RAM frisst (1GB mehr als mit dem klassischen Modell) und jede Code Completion einige Sekunden geht und einen Kern voll auslastet. Naja, ist ja alles noch Beta(TM).
Jedenfalls gibt es jetzt so nette Codestyle-Warnings:

(m_serial_monitor ist ein std::unique_ptr).

Hier sehe ich mittlerweile das grösste Problem von C++: Je neuer der Standard, desto mehr wird die Herkunft geleugnet. Ich habe echt nichts gegen Syntaxerweiterungen, die Boilerplate wegnehmen, wie die foreach-Loops.
Aber irgendwie wird krampfhaft versucht, Pointer zu verstecken, eigentlich beginnend schon mit Referenzen in C++98(?), dann weiterführend mit auto_ptr, shared_ptr, unique_ptr, etc.
Ich finde diese Hilfen sehr nett, gerade durch RAII kann man sich viele Kopfschmerzen ersparen, aber den Grundsatz "never use new/delete", der u.a. auf SO so dermassen beliebt ist, ist doch irgendwie falsch.

Das artet dann in solchen Artikeln aus: https://www.quora.com/Why-is-C++-considered-a-bad-language
(Wobei der nette Mensch vergisst, dass GCs dafür einfach irgendwann mal einspringen, und der Optimizer ziemlich gut ist für Function calls).

Wie schon gesagt, was gebraucht wird, ist ein C, das syntaktisch einfacher/kürzer ist, namespacing/(Classes) besitzt, und eine Art Smartpointer hat, um Leaks zu vermeiden. Dazu noch ein bisschen Würze wie Typesafety, meinetwegen auch Templates. Das wäre dann ein C++. Exceptions meide ich persönlich wie die Pest, da es in der Regel zu sehr schlimmen Code führt (try-catches als control flow oder für Rückgabewerte (schauder)). CryptoPP spielt in dem Gruselkabinett recht weit vorne mit, mit Exceptions für falsche Schlüssel, self-deleting Parameter Pointers etc.

An unserer Uni hatten wir kürzlich eine Code Review für Java-Code. Codefragmente, die mehr als 20 Zeilen lang waren, wurden als schlecht erachtet, da man mehr in Funktionen auslagern sollte. OOP wird nicht mehr als Ausweg für zu unübersichtlichen Code, sondern als Standard gelesen.
Jedes mal, wenn ich sage, meine Klassen haben etwa 50 Funktionen und manche Funktionen sind 200 Zeilen lang heisst es, dass das schlechter Stil ist. Wenn ich in einer Gruppenarbeit eine Referenz auf ein Objekt übergebe, das eine State-Variable hat, die dann innerhalb der Funktionen verändert wird, kommt jemand daher und refactort das Ganze, sodass bei jedem Iterationsschritt (State-Change) ein Objekt erstellt wird, das den letzten State und den nächsten State hält, das dann als State übergeben wird, da das ja eher Funktional und daher besser sei. Da die Klasse aber auch den Kontext hielt, wird die Referenz dann einfach per Konstruktor an den Arbeiter übergeben. Somit macht man dasselbe quasi doppelt, kopiert sich und den Speicher zu Tode, aber es sieht funktionaler aus! Ziel erreicht, Performance ist ja eh egal.

Wenn ich aber jeweils die privaten Projekte vergleiche, machen meine Projekte echte Arbeit (CPU-Emulation, Logik-Emulation) in einem annehmbaren Zeitrahmen (1 durchschnittliche ARMv6-Instruktion auf einem 7500U @ 2.7GHz in ~200ns, keine besonderen Performancemassnahmen), während die Fans von OOP und 2-Zeilen-Funktionen einfach ein paar Standardfunktionen zusammenkleben und Bilder ausgeben oder aus Prinzip mit JSON arbeiten.
Ich will damit nicht sagen, dass ein aufgeräumter Stil schlecht ist, sondern, dass es auf den Anwendungsbereich ankommt. Man kann keine komplexen Bitoperationen in 5 Zeilen abschliessen; man kann nicht SmartPointer verwenden, wenn man innerhalb eines Scratch Buffers arbeiten will, etc. Wenn man aber ein PoC machen will, dann ist JSON legitim. Für Apps am Mobilnetz ist es mittlerweile Standard, danke auch für den Datenverbrauch.
Aber irgendwie ist dieser "Nutz doch die riesige Standardbibliothek für alles" aus Java, C# und mittlerweile Rust ein erklärtes Ziel von C++.
Und genau das, denke ich, ist das Problem des Komitees. Statt die Stärken von C zu betonen und die Schwächen auszumerzen, will man unbedingt modern sein und alles haben, was andere auch haben, ungeachtet dessen, was C so gut macht.
Das artete dann auch in diesem Aprilscherz aus: https://www.heise.de/developer/artikel/No-New-New-Das-Ende-von-Zeigern-in-C-4009347.html

Was mich aber wundert, ist der scheinbare Konsens auf dem OOP/Funktional/"Moderne Sprache"-Wahn. Kaum jemand jemand, mal von den Kernel-Entwicklern abgesehen, scheint den alten Stil zu verteidigen.
Ich weiss nicht, ob es daran liegt, dass heutzutage niemand mehr direkt auf Hardware arbeitet (da ist mir oft selbst C zu ungenau, bzw. GCC mit seinen Register-readbacks after write) oder dass mittels IDEs das Nachverfolgen von Codepfaden einfacher ist, aber irgendwie missfällt mir diese Entwicklung. Aber wer weiss, vielleicht bin ich auch der einzige ¯\_(ツ)_/¯

Gruss
cwriter

 

[sheel]

Danke für die Fortführung
...
Zu Stackoverflow und Pointer-verstecken zuerst ... hab da so eine kleine Theorie, die sich relativ gut hält

• Leute kennen sich mit Pointern nicht aus. Bzw. dass die überwiegende Mehrheit der Menschen sich damit nicht auskennt ist sowieso klar, aber auch beim Rest sind viele dabei, die es zwar in normalen Fällen richtig anwenden können, sichd abei aber nicht so recht wohl fühlen
• Daraus entsteht Angst - Angst etwas falsch zu machen, deswegen Probleme zu bekommen (alles von "Im Codereview blöd dastehen" bis zu "gefeuert werden" etc.). Und/oder sowas ist schon passiert und man sucht die Schlud bei der Sprache, statt bei sich.
• Im Internet gibts bekannten Blog X, der sagt, Pointer sind schlecht. Dadurch fühlt man sich bestätigt, Pointer müssen weg.
• Weitere Verstärker Richtung "Generation Schneeflocke" usw.
• Und natürlich gibts noch die "Hipsters", die bei teilweise/ganz überlappenden Features nur das Neuere als die einzige Wahrheit akzeptieren.

.... um fair zu sein, die Hipstereinstellung ist in offiziellen Sachen von Kommitee nicht zu finden (afaik). Pointer sind im Standard also sind sie erlaubt, Punkt. ... Aber da das Kommitee auch aus Leuten besteht, und immer wieder mal neue dazukommen die anfangen Proposals schreiben, wird das Ganze immer mehr unterwandert; von zB. solchen Leuten die auch diese Clang-Warnungen machen.

Speziell SO betreffend, würde mir über die einfach nicht den Kopf zerbrechen. Zwar eine der größten "Communities" (haha, vergifteter gehts nicht mehr), aber im Durchschnitt auch eine der dümmsten (auch immer wieder mal mit öffentlichen Statistiken bestätigt).

...

Zu diesem Quorapost, bei einem (C++-unabhängiger) Punkt muss ich dem sehr zustimmen: Krampfhafte Patternisierung ist böse (was sich übrigens wieder darauf zurückführen lässt, dass viele Leute OOP nie wirklich verstanden haben. So wie Pointer. usw.usw.).

...

Zu Resourcenverbrauch, meine einfache Erklärung dazu, die Meisten mussten einfach noch nie was schreiben was schnell+speichersparend ist. In ihren Entwicklungsumgebungen war alles akzeptabel, kein Chef/Kunden/etc. haben sich über lLangsamkeit beschwert, usw ... und deshalb verstehen sie es nicht, warum man BequemesLangsamesFeatureX nicht als zwingenden Teil in die Sprache einbauen kann.

(zu den Kunden - was nicht bedeuten soll, dass alles ok ist. Mein aktuelles Topproblem auf der Arbeit: Ein RestAPI-Ding, bei dem der einfachste Request 20sec braucht. Und im Idealfall würde ich gern für ca. jede Minute Arbeit einen Request starten und brauch das Ergebnis dann zum weitermachen. Es zu verbessern, oder sich beim Ersteller beschweren, ist leider beides explizit nicht genehmigt
... Und da ist auch noch der bitte-mehr-als-16GB-Firefox
...)

...

try-catches als control flow oder für Rückgabewerte (schauder)

Außer den zwei Sachen bleibt aber nichts übrig
... wie immer gibts Situationen, wo es gut geeignet ist, und andere.

(Die Exception für falsche Keys hört sich für mich gar nicht so schlimm an...)

An unserer Uni hatten wir kürzlich eine Code Review für Java-Code. Codefragmente, die mehr als 20 Zeilen lang waren, wurden als schlecht erachtet, da man mehr in Funktionen auslagern sollte.

Jaa...das hab ich auch mal gehört ... zusammen mit der Aussage, dass man mehr als drei verschachtelte Level von Schleifen/if/... in der Realität nie sehen wird lol

Auf die Frage, was man bei Funktionen mit 20 Parametern (bei der man die Parameterliste nicht ädnern kann!) und gleich am Anfang 200 Zeilen Validierung der Parameter, bevor es zum eigentlichen Sinn der Funktion kommt, tun soll, konnte mir bisher niemand von solchen Leuten eine überzeugende Antwort geben.
meineFunktion_validateParam1_Part1(), meineFunktion_validateParam1_Part2(), meineFunktion_validateParam1_Part3()? Die Werte für die lokalen Variablen immer oorgendwie mit Referenzen mitübertragen? Die 60 validate-Funktionen dann in 3 weitere zu je 20 Funktionsaufrufen zusammenfassen, die drei wieder in einer, und die dann in der Hauptfunktion aufrufen? Und am besten jede Funktion noch mit einer eigenen Klasse?
Wohl kaum.

...Erinnert mich an einen Kollegen, der tatsächlich jedes if-foo-then-error-4 in zwei Klassen ausgelagert hat (eine für das if, eine mit den Fehlerdaten). Könnte ja wiederverwendbar sein. War es teilweise auch, aber natürlich keine Nettoersparnis an Zeilen und Arbeitszeit. Inzwischen hat sogar er eingesehen, dass es Unsinn ist.

Jedes mal, wenn ich sage, meine Klassen haben etwa 50 Funktionen und manche Funktionen sind 200 Zeilen lang heisst es, dass das schlechter Stil ist.

Hast du auch mal einen Grund bekommen? Also einen außer "ich mag es nicht" und/oder "RandomPersonImInternet mag es nicht"?
Erinner sie doch bitte mal, dass wir nicht Modedesigner sind, sondern was praxistaugliches machen wollen.

(Zum Niveau von "RandomPersonImInternet": Ein Artikel a la "Austrias [X] is the only thing worldwide that has [Y]" auf einer englischen Zeitungsseite. Ca. 50 Nutzerkommentare, die Hälfte davon waren Witze über Känguruhs. ... Ein paar andere Kommentare waren der Meinung, dass der Artikel nicht stimmt, weil auf den ganzen Bildern teilweise deutscher Text zu sehen war und man in Austria ja ganz offensichtlich nicht german spricht).

...
du bis nicht allein