Ist C++ noch zu retten?

hustbaer

@Enumerator Es muss nicht jeder mit C++ programmieren. Wenn es dir zu komplex ist und du es nicht verstanden hast, dann lass es bleiben. Für dich hat der Herrgott BASIC erfunden.

Aber jetzt ernsthaft: genau so wie manche nie müde werden zu posaunen dass C ein Werkzeug für Profis ist, ist C++ eben auch ein Werkzeug für Profis. Wenn man weiss wie man es sinnvoll einsetzt, kann man damit schön arbeiten. Vor allem wenn es nicht auf den letzten Taktzyklus ankommt.

Was dein auto vs. auto& Beispiel angeht: wenn dadurch irgendwas gecrasht ist, dann gibt es in eurem Code ein viel grundlegenderes Problem. Und wenn das Problem lediglich war dass eine Kopie verändert wurde statt des Originals, und die Änderung nicht dort angekommen ist wo sie hin sollte... naja dann ist die Ursache einfach dass jemand ein Sprachfeature verwendet hat von dem er nichtmal die grundlegensten Grundlagen verstanden hat. Nämlich dass autocv-ref wegmacht. Und das soll jetzt die Schuld von C++ sein?

Enumerator

@hustbaer, 5script, Jockelx
Genau diese Einstellung ist es die der Threadersteller auch beklagt hat. Keinerlei Argumente bringen nur unverschämte Beleidigungen. Anstatt einzusehen, dass z.B. Smart-Pointer und auch z. B. das auto Schlüsselwort eine Fehlkonstruktion sind. Wie wäre es mal etwas über den Tellerrand hinauszuschauen :). Aber mit Hobbyentwicklern wie euch über soetwas zu diskutieren ist sowieso sinnlos. Die Verwendung von auto ist einfach extrem Fehleranfällig weil auto etwas suggeriert was es nicht ist und zu sehr schlecht lesbarem Code führt. Es gibt nunmal sicherheitskritische Bereiche in der Softwareentwicklung wo ein solches Fehlerpotenzial nicht akzeptabel ist. Als ich damals noch in der Luftfahrtbranche gearbeitet hatte war es nicht mal erlaubt dynamisch Speicher zu allokieren. Es gibt nunmal Bereiche wo es um Menschleben geht. Da würde niemand und wirklich niemand auch nur auf die Idee kommen "Smart-Pointer", "auto" & co zu verwenden. Aber jetzt lasse ich euch weiter eure "Hello World" Programme weiter frickeln...

Bashar

@Enumerator sagte in Ist C++ noch zu retten?:

@hustbaer, 5script, Jockelx
Keinerlei Argumente bringen nur unverschämte Beleidigungen. [...] Aber mit Hobbyentwicklern wie euch über soetwas zu diskutieren ist sowieso sinnlos.

Enumerator

@Bashar
Was die können kann ich auch ;).

Zitat:
@Enumerator Es muss nicht jeder mit C++ programmieren. Wenn es dir zu komplex ist und du es nicht verstanden hast, dann lass es bleiben. Für dich hat der Herrgott BASIC erfunden.

@hustbaer
Ich schätze deine Meinung hier im Forum ja sehr aber mit deinem "Experten"-Kommentar hast du dich wirklich lächerlich gemacht.
Ich stelle mir gerade vor wie sich Boeing nach den beiden Abstürzen durch das MCAS Debakel hingestellt hätte:

Die 737 MAX ist halt nur was für Experten zum Fliegen...
Die Piloten haben den Flieger einfach falsch bedient.
Man kann sich das Leben so schön einfach machen...

Solche Statements kommen in der Regel nur von Personen die Pfusch schönreden wollen. Schade dass es in C++ scheinbar keine Diskussion über die vielen Fehlkonstruktionen geben darf. Und auto wird C++ einst den Gnadenstoß versetzen wie einst Dim Visual Basic das Genick gebrochen hat (Ich weiß auto ist "typsicher", von Referenzen mal abgesehen). In C# haben sie die Sprache nun leider auch noch nachträglich um diesen "var" Murks erweitert.

hustbaer

@Enumerator sagte in Ist C++ noch zu retten?:

Die Verwendung von auto ist einfach extrem Fehleranfällig weil auto etwas suggeriert was es nicht ist und zu sehr schlecht lesbarem Code führt. Es gibt nunmal sicherheitskritische Bereiche in der Softwareentwicklung wo ein solches Fehlerpotenzial nicht akzeptabel ist.

OK. Und der Fehler wenn dein Kollege auto verwendet (obwohl er nicht weiss wie es funktioniert) ist dann nicht dass er etwas verwendet wovon er nicht weiss wie es funktioniert sondern dass C++ sowas wie auto überhaupt anbeitet. Komische Einstellung.

Wie sollte auto denn deiner Meinung nach funktionieren?

Kleiner Tip: auto var = expression; ergibt den selben Typ für var wie wenn du expression beim Aufruf eines function templates verwenden würdest:

template <class T>
void fun(T var);

// ....
    fun(expression);

Das macht mächtig viel Sinn. Alles andere wäre komisch und mMn. viel fehleranfälliger.

Swordfish

@Enumerator sagte in Ist C++ noch zu retten?:

Er hätte "auto&" schreiben müssen. Das ist Grund genug für mich auto zu verbieten.

So ein Quatsch. Das ist ein Anfängerfehler den man ein, zweimal macht und dann nie wieder.

hustbaer

@Enumerator sagte in Ist C++ noch zu retten?:

@hustbaer
Ich schätze deine Meinung hier im Forum ja sehr aber mit deinem "Experten"-Kommentar hast du dich wirklich lächerlich gemacht.

OK. Lass es mich anders sagen: Wer Sprachkonstrukte verwendet von denen er einfach nicht weiss wie sie funktionieren, darf sich bitte nicht über die Sprache aufregen wenn sie nicht so funktionieren wie es das Stück Code das er damit gebastelt hat gerade brauchen würde.

Ich stelle mir gerade vor wie sich Boeing nach den beiden Abstürzen durch das MCAS Debakel hingestellt hätte:

Die 737 MAX ist halt nur was für Experten zum Fliegen...
Die Piloten haben den Flieger einfach falsch bedient.
Man kann sich das Leben so schön einfach machen...

Du vergleichst hier Äpfel mit Birnen.

Solche Statements kommen in der Regel nur von Personen die Pfusch schönreden wollen. Schade dass es in C++ scheinbar keine Diskussion über die vielen Fehlkonstruktionen geben darf.

Du kannst mit mir jederzeit eine Diskussion über Fehlkonstruktionen im C++ Standard führen. Da gibt's mMn. einige. auto gehört bloss nicht dazu. Und eine Geschichte von jmd. der es falsch verwendet hat, weil er nichtmal ansatzweise Ahnung davon hatte wie es funktioniert, wird mich nicht vom Gegenteil überzeugen.

Solche Leute sind ein grosses Problem in der Softwareentwicklung. Was meinst du was los ist wenn du so jemandem etwas wie Threads in die Hand gibtst? Der schreibt dann jahrelang kaputten Code weil's bisher eh immer funktioniert hat. Und irgendwann kommst du drauf dass das Programm manchmal falsch rechnet oder abkackt. Bloss ist dann alles schon so kaputt dass man es nicht mehr in vernünftiger Zeit reparieren kann.

Und auto wird C++ einst den Gnadenstoß versetzen wie einst Dim Visual Basic das Genick gebrochen hat (Ich weiß auto ist "typsicher", von Referenzen mal abgesehen). In C# haben sie die Sprache nun leider auch noch nachträglich um diesen "var" Murks erweitert.

Sehe ich anders.
Und: was soll "von Referenzen mal abgesehen" heissen? Auch da ist es typsicher. Und mMn. auch sicherer gegenüber Falschverwendung als wenn es anders rum wäre.

hustbaer

@Enumerator sagte in Ist C++ noch zu retten?:

Zitat:
@Enumerator Es muss nicht jeder mit C++ programmieren. Wenn es dir zu komplex ist und du es nicht verstanden hast, dann lass es bleiben. Für dich hat der Herrgott BASIC erfunden.

Der nächste Paragraph geht halt auch mit "Aber jetzt ernsthaft:" los. Kann man beim Zitieren natürlich unterschlagen. Ist dann aber auch irgendwie komisch.

ps: Ich finde es auch sprechend dass du anscheinend nicht weisst wie man hier im Forum "korrekt" zitiert bzw. es dich nicht schert es korrekt zu machen.

Enumerator

Ich glaube wir drehen uns da im Kreis :). Ich wollt doch nur darauf hinweisen, dass auto den Code sehr viel schlechter lesbar macht. Wollt ihr mir erzählen ihr erkennt im folgenden Code dass hier ein & beim auto vergessen wurde:

Zitat:
Kleiner Tip: auto var = expression; ergibt den selben Typ für var wie wenn du expression beim Aufruf eines function templates verwenden würdest:

@hustbaer
Ja eben genau nicht:

const vector<int>& GetInts()
{
    static vector<int> s_ints;
    return s_ints;
}
static auto unexpectedCopy = GetInts();

Der Code würde wenn ich nicht total daneben liege eine Kopie des Vectors anlegen. Das ist ja die Krux.

Da können dann auch ein dutzend Entwickler drüber schauen und erkennen das fehlende & nicht. Dann soll man solche Krücken gefälligst weg lassen. Aber jeder wie er will ich werde auto jedenfalls nicht verwenden :).

Zum "aber jetzt ernsthaft". Ich schlage auch immer den Leuten erst ins Gesicht und entschuldige mich danach [Ironie off].

Ja ich gebe zu ich finde die Zitieren Funktion extrem umständlich weil man ja meistens nur eine kleine Passage zitieren möchte und nicht den ganzen Post. Insofern gebe ich dir recht. Ich bin ein Zitier-Legasteniker ;). Mal davon abgesehen, dass das Forum ohne Referrer und Skripte komplett unbenutzbar ist.

hustbaer

@Enumerator sagte in Ist C++ noch zu retten?:

Ich glaube wir drehen uns da im Kreis :). Ich wollt doch nur darauf hinweisen, dass auto den Code sehr viel schlechter lesbar macht. Wollt ihr mir erzählen ihr erkennt im folgenden Code dass hier ein & beim auto vergessen wurde:

Zitat:
Kleiner Tip: auto var = expression; ergibt den selben Typ für var wie wenn du expression beim Aufruf eines function templates verwenden würdest:

@hustbaer
Ja eben genau nicht:
const vector<int>& GetInts()
{
    static vector<int> s_ints;
    return s_ints;
}
static auto unexpectedCopy = GetInts();

Ja eben genau doch:

vector<int>& GetInts()
{
    static vector<int> s_ints;
    return s_ints;
}

template <class T>
void appendInt(T container) { // <-- Quatsch
    container.push_back(42);
}

void fun() {
    appendInt(GetInts());
}

Hier wird bei appendInt genau so (unerwartet?) eine Kopie angelegt wie in deinem Beispiel. Wie gesagt: die selben Regeln, selbes Ergebnis. Sind deswegen Templates eine einzige riesen Fehlkonstruktion?

Da können dann auch ein dutzend Entwickler drüber schauen und erkennen das fehlende & nicht.

Ja, kann passieren. Ich sage auch nicht dass man immer und überall auto verwenden soll. Das heisst aber auch nicht dass auto grundsätzlich schlecht und eine Fehlkonstruktion ist.

Zum "aber jetzt ernsthaft". Ich schlage auch immer den Leuten erst ins Gesicht und entschuldige mich danach [Ironie off].

Sowas kommt vor (nicht immer, aber manchmal) wenn jemand einen Beitrag schreibt der für mich so haarstreubend lächerlich (sorry) ist wie deiner hier.

5cript

@Enumerator sagte in Ist C++ noch zu retten?:

Als ich damals noch in der Luftfahrtbranche gearbeitet hatte

Würdest du mir die betroffenen Flugzeugtypen nennen? Möchte mich nicht unnötig in Gefahr begeben.
(EDIT: Ich hatte den post nicht seziert, weil hustbaer das für mich gemacht hatte).

Bashar

@Enumerator sagte in Ist C++ noch zu retten?:

@Bashar
Was die können kann ich auch ;).

Aber kannst du sonst noch was? Bisher bist du mir eigentlich nur negativ aufgefallen. Wenn du positiv auffallen möchtest, solltest du dich nicht an denen orientieren, die du kritisierst.

Enumerator

@hustbaer
Achso, jetzt verstehe ich worauf du hinaus wolltest. Aber nochmal. Bei auto erwarte "ich" dass es sich genauso verhalten würde wie ein typedef. Dass das auto den "Typ" bei Referenzen ändert ist für mich einfach ein Unding und unerwartet. Das wird wohl auch niemand ernsthaft in Abrede stellen können. Genauso wie dass es den Code schlechter lesbar macht. Was gewinnt man also durch Verwendung von auto (Ja, ich weis es gibt ein paar wenige Codekonstrukte die ohne auto nicht möglich wären)?

Grundsätzlich ist das Problem aber auch bei Templates existent. Im Beispiel im Code unten wird man sich wundern warum die spezialisierte Funktion zwar mit Pointern funktioniert, nicht aber mit Referenzen, weil der Compiler die "T" Variante ohne "&" erwarten würde, obwohl eine Referenz an die Print-Funktion übergeben wurde. Findet ihr das wirklich zugänglich? Vor allem wenn sich auto dann womöglich noch anders verhält wie man es aus anderen Sprachen gewohnt ist.

class A
{
template <class T> void Print(T arg);
};

template <>
void A::Print(MyObject* arg)
{
...
}

template <>
void A::Print(MyObject& arg)
{
...
}

@Bashar
@5script
Sorry, aber darauf gehe ich gar nicht weiter ein.

Enumerator

Und was sagt ihr zu den von mir genannten Smart-Pointer Fehlkonstruktionen? Mir ging es eignetlich hauptsächlich darum. Darüber verliert ihr komischwerweise kein einziges Wort. Eisiges schweigen im Walde. Das mit dem auto war nur als kleine Anekdote gedacht. Furchtbar wie ihr euch daran aufhängt weil ihr selber wisst, dass C++ einfach viele Fehlkonstruktionen hat die man auch nicht leugnen kann. Und bitte nehmt es doch nicht persönlich. Man sollte eine Diskussion niemals auf sich selber projezieren. Ich greife hier doch niemanden persönlich an deswegen. Natürlich könnt ihr für die Situation auch nichts. Danke. Ich denke der Thread kann geschlossen werden.

5cript

@Enumerator sagte in Ist C++ noch zu retten?:

Was ich z.B. total ätzend finde ist, dass man einen Smart-Pointer im Konstruktor nicht mit this initialisieren kann (wenn von enable_weak_from_this abgeleitet)

Warum würdest du das wollen? Zur Selbsthaltung?

@Enumerator sagte in Ist C++ noch zu retten?:

Oder auch siehe zirkuklare Abhängigkeiten und memory leaks.

Klingt verdächtig nach dem angedeuteten shared_ptr abuse.

Alles was ich in dem Post lese sind:

Mangelhafte Software Architektur.
Anfänger C++ beizubringen ist hard und sie machen viele Fehler.

Für letzteres kann ich auch argumentieren, also will ich das gar nicht kritisieren.

Bashar

Zyklische Abhängigkeiten bei referenzgezählten Zeigern sind ein generelles Problem, das weiß man schon sehr lange und das hat mit der speziellen Konstruktion von shared_ptr nichts zu tun.

Jockelx

@Enumerator sagte in Ist C++ noch zu retten?:

Furchtbar wie ihr euch daran aufhängt weil ihr selber wisst,

Furchtbar, dass du nicht einfach sagen kannst "ja, mit dem auto war quatsch von mir, reden wir doch bitte über smart-pointer".
Dein smart-pointer-Problem habe ich leider nicht verstanden, sonst hätte ich da was zu gesagt. Wobei wahrscheinlich eher nicht, da ich nur pointer und unique_ptr nutze und mit smart/weak kaum Erfahrung habe.

Enumerator

Huch

hustbaer

@Enumerator sagte in Ist C++ noch zu retten?:

@hustbaer
Achso, jetzt verstehe ich worauf du hinaus wolltest. Aber nochmal. Bei auto erwarte "ich" dass es sich genauso verhalten würde wie ein typedef.

Das ist jetzt ein schlechter Vergleich, da du nicht typedef myFunctionThatReturnsInt() MyNewNameForInt schreiben kannst. Dazu brauchst du declspec. Und bei declspec macht es im Gegensatz zu auto schon Sinn dass Referenzen nicht einfach so verschwinden. Obwohl es auch dort viele Fälle gibt wo man cv-ref weg haben möchte.

Dass das auto den "Typ" bei Referenzen ändert ist für mich einfach ein Unding und unerwartet. Das wird wohl auch niemand ernsthaft in Abrede stellen können.

Ich kann nicht in Abrede stellen dass es für dich ein Unding ist. Aber ich bin gänzlich anderer Meinung. Es ist gut dass auto cv-ref wegmacht.

Genauso wie dass es den Code schlechter lesbar macht. Was gewinnt man also durch Verwendung von auto (Ja, ich weis es gibt ein paar wenige Codekonstrukte die ohne auto nicht möglich wären)?

auto const x = a + b; // interessiert mich doch nicht die Bohne welchen Type a und b haben
                      // (mal abgesehen davon dass der Typ von `a + b` nicht identisch zum Typ von `a` oder `b` sein muss),
                      // ich will bloss das Ergebnis mit dem passenden Typ einfangen
auto const it = cont.find(...); // IMO viel lesbarer als ohne auto
if (it != cont.end())
    ...

Davon abgesehen...

template <class T>
T popAndReturnBack(T& cont) {
    auto val = cont.back();
    cont.pop_back();
    return val; // Kaboom nach deinen Regeln, kein Problem mit den echten Regeln
}

Grundsätzlich ist das Problem aber auch bei Templates existent. Im Beispiel im Code unten wird man sich wundern warum die spezialisierte Funktion zwar mit Pointern funktioniert, nicht aber mit Referenzen, weil der Compiler die "T" Variante ohne "&" erwarten würde, obwohl eine Referenz an die Print-Funktion übergeben wurde. Findet ihr das wirklich zugänglich?

Nein. Ist aber wieder so ein Fall von Dinge verwenden über die man sich nicht ausreichend informiert hat. Gerade wenn man Code schreibt wo es extrem wichtig ist dass er korrekt funktioniert, darf man das einfach nicht machen. Einfach was hinschreiben von dem man sich denkt es könnte vielleicht die Syntax sein für das was man erreichen möchte, und es ausliefern sobald es compiliert... ohne es getestet zu haben... so kann man einfach nicht vernünftig Software entwickeln. Und wenn man es testet, dann merkt man meistens dass es nicht funktioniert.

Vor allem wenn sich auto dann womöglich noch anders verhält wie man es aus anderen Sprachen gewohnt ist.

z.B.?

5cript

@Enumerator sagte in Ist C++ noch zu retten?:

Eine Klasse wie die shared_ptr Klasse die es zulässt dass man sich selber in das Knie schießt ist broken by design. Da sind wir dann einmal gemeinsam einer Meinung ;). Und Fehler passieren nur Anfängern. Ganz ehrlich diese Arroganz wiedert mich an. Ich hoffe du kommst nie in eine Position mit Verantwortung.

Ich habe nicht gesagt dass Fehlern nur Anfänger passieren.
Du hast auch meine Frage nicht beantwortet.
Ich kann mir auch mit nem Hammer auf die Finger haun, das macht den Hammer nicht broken by Design.

Ich habe schon eine Zyklische Referenzen mit shared_ptr hinbekommen über lambda capture, wo das lambda in einem std::function war und das wieder als Member des Objekts im shared_ptr und dadurch eine Selbsthaltung ungewollt gebaut.
So eine Fehler würde ich ja noch akzeptieren. Aber manche billig sachen sind mit Erfahrung einfach mega schnell gefunden.

shared_ptr hat nunmal ein caveat den man kapiert haben muss.
Sowieso hoffe ich dass aus guten Gründen zu shared_ptr gegriffen wurde, statt unique_ptr.

Darüber hinaus möchte ich noch sagen, dass JockelX und hustbaer angesehene Foristen hier sind und das berechtigt hier über Zeit aufgebaut haben. Eine Meinungsverschiedenheit mit denen rechtfertigt eine Selbstreflektion der eigenen Ansicht. Was mich selbst angeht muss ich mich nicht für meinen Source schämen.
Mein code wird bei Siemens, Bio Unternehmen (Menschen Gesundheit) und Straßenbau verwendet (Messtechnik zur Qualitätssicherung bezüglich grip und audiocharacteristik der Oberfläche).