default auto statt default int

[asdasdsadsad]

wob schrieb:

???

Ich meinte das damalige default int bei main().

auto variable = funktion_mit_return();

Ich würde behaupten, dass ein überwiegender Teil sich das auto auch sparen könnte.

Du meinst also statt void f(){} soll auch f(){} ausreichen?

Ich meine so etwas:

if( container.empty )

und ja, am besten ohne die if klammern...

Sicherlich könnte man sowas machen, aber das verändert doch schon gewaltig die Sprachregeln. Und wer weiß, wo man dann Mehrdeutigkeiten erzeugt.

Türlich... Vieles war auch vor 10 Jahren nicht denkbar.

Außerdem wären mir andere Dinge wichtiger, ich zum Beispiel ne größere STL. Insbesondere in std::string, beispielsweise vermisse ich starts_with und ends_with . Aber andere Leute werden ne andere Meinung haben.

Am besten beginnen wir in der STL bei Dingen die auch sonst jede Sprache hat. Tokenize, Trim, ...
Es ist schon krass das so etwas wie to_string, to_wstring, thread, regex es erst seit 11++ gibt.
Damit müssen sich die meisten Anfänger erst einmal eine ganze Toolbox selbst schreiben. Deren Qualität kann sich dann jeder selbst vorstellen.
Von GUI und Matrix Klassen die mit LAPACK und BLAS schon lange abgefrühstückt sind will ich gar nicht anfangen .

Das andere, was mir noch einfallen würde, wäre eher "irgendwas mit Modulen".

So etwas ist zu mindest mMn schon angedacht ... dauert noch.

Also irgendwie auotmatisch erzeugte Header, die dann nur die Public-Variablen + "hier N bytes private" enthalten. Das müsste doch alles irgendwie zu vereinfachen sein! Das wäre mein größter Wunsch.

Der ist auch gut!

Die verdammten Semikolons und die geschweiften Klammern gehen mir auch auf den Sack, die gehören wie bei python durch \n und \t ersetzt

Viele solcher

[wob]

asdasdsadsad schrieb:

auto variable = funktion_mit_return();

Ich würde behaupten, dass ein überwiegender Teil sich das auto auch sparen könnte.

Damit ich mich gut verschreiben kann oder nicht mehr erkenne, dass ich irgendeine Variable verstecke? Ich finde gut, dass man Variablen explizit als solche kennzeichnen muss. Vor allem sieht man mit auto auf den ersten Blick, wo der Scope anfängt!

asdasdsadsad schrieb:

Die verdammten Semikolons und die geschweiften Klammern gehen mir auch auf den Sack, die gehören wie bei python durch \n und \t ersetzt

Hier sind wir schon anderer Meinung. Das mag ich an Python genau nicht. Dinge wie if (a > b) continue; möchte ich auf einer Zeile schreiben können und die Klammern erleichtern mir zusammen mit Einrückung das Erkennen der Blöcke.

Viel wichtiger aber: Kompatibilität mit älterem C++-Code. Daher bin ich klar gegen solche Änderungen an der Syntax, die daher auch nicht kommen werden!

[;zerg]

Ich würde behaupten, dass ein überwiegender Teil sich das auto auch sparen könnte.

Und wenn du dich jetzt vertippst, legst du still eine neue Variable an, statt einen Compilerfehler zu bekommen. Dann wären wir auf das Niveau des Krebsgeschwürs PHP gefallen. Kann sein, dass ich mir die Statistik gerade ausgedacht habe, aber 99% aller Sicherheitslücken im Web sind auf solche PHP-Scherze zurückzuführen.

if( container.empty )

Hm...

auto f=[](){return [](){return [](){return 4;};};};
if (f)...;

Wofür steht f? Für f? f()? f()()? f()()()?
Bin mir da nicht ganz sicher, ob in deinem Weltbild schon Funktionen existieren.

[asdasddsasd]

;zerg schrieb:

Und wenn du dich jetzt vertippst, legst du still eine neue Variable an, statt einen Compilerfehler zu bekommen.

Klappt bei anderen Sprachen wunderbar, fühlst du dich nicht in der Lage solche Fehler zu entdecken?

;zerg schrieb:

Wofür steht f? Für f? f()? f()()? f()()()?
Bin mir da nicht ganz sicher, ob in deinem Weltbild schon Funktionen existieren.

Da gibt es auch Sprachen die so etwas ohne Probleme auflösen können. MATLAB zum Beispiel. Ich würde mal behaupten dass 99% f() sind, ab da an tendiert es eher gegen Sonderfälle die mit Verstand auch übersichtlicher programmiert werden könen.

[ewrdsadas]

wob schrieb:

Damit ich mich gut verschreiben kann oder nicht mehr erkenne, dass ich irgendeine Variable verstecke? Ich finde gut, dass man Variablen explizit als solche kennzeichnen muss. Vor allem sieht man mit auto auf den ersten Blick, wo der Scope anfängt!

Variablen mittels scope überschreiben, da haben wir wieder etwas gefunden Ich finde man sollte mittlerweile ein Buch über verpönte C++ Funktionen schreiben. Preprozessorfunktionen, typedefs, ...

wob schrieb:

Hier sind wir schon anderer Meinung. Das mag ich an Python genau nicht. Dinge wie if (a > b) continue; möchte ich auf einer Zeile schreiben können und die Klammern erleichtern mir zusammen mit Einrückung das Erkennen der Blöcke.

Mag sein, Python kennt da keine Kompromisse. Hier und da entstehen teilweise unnötige Zeilen. Insgesamt ist das Fehlerpotential (mMn) geringer.

wob schrieb:

Viel wichtiger aber: Kompatibilität mit älterem C++-Code. Daher bin ich klar gegen solche Änderungen an der Syntax, die daher auch nicht kommen werden!

Wichtig ist, dass es sich kompilieren lässt. Ich würde es begrüssen wenn -std=c+11 und später gewisse 'Möglichkeiten' als obsolet markiert, mit einer Warnung versieht und irgendwann komplett entfernt. Damit wird über Zeit Raum für neue Syntax frei von Altlasten. Wir haben noch keine 100 Jahre C++ und müssen schon solche Kurven laufen um Kompatibilität zu erhalten.

[wpm]

asdasdsadsad schrieb:

wünschte ich mir (leider) ein paar Brüche mit dem Standard um sich ein wenig Tipparbeit zu sparen.

Einfach WPM trainieren...

asdasdsadsad schrieb:

Meine Favoriten wären zum Beispiel default auto an Stelle von default auto. Dann würde ich mir bei 90% aller Deklarationen auch das auto sparen.

Totaler Unsinn. Ob ein Ausdruck eine Definition oder eine Zuweisung ist, möchte ich gerne auch ohne Kontext wissen.

asdasdsadsad schrieb:

Dann wäre da noch operator () ohne Argumente. In diesem Fall wäre es mir recht Klammern einfach wegzulassen

Totaler Unsinn. Die bereits komplizierten Konvertierungsregeln werden noch um ein Vielfaches schwieriger, nur um sich 2 (oder 1 mit vielen Editoren) Tastenanschlag zu sparen.

asdasdsadsad schrieb:

Am besten beginnen wir in der STL bei Dingen die auch sonst jede Sprache hat. Tokenize, Trim, ...

Ich habe alles Weiterführende lieber in Boost als in der STL. Da muss ich nicht drei Jahre auf einen Bugfix warten.

asdasdsadsad schrieb:

Die verdammten Semikolons und die geschweiften Klammern gehen mir auch auf den Sack, die gehören wie bei python durch \n und \t ersetzt

Totaler Unsinn. Die Pseudolösung von Python ist viel fehleranfälliger, u.A. da dort diesbezüglich keine Warnungen existieren. Mein C++-Compiler warnt mich sofort, wenn der Kontrollfluss nicht mit der Einrückung übereinstimmt (was so gut wie nie passiert). Außerdem ist es keine Sache, { oder ; zu tippen. Wie gesagt: einfach WPM trainieren...

asdasddsasd schrieb:

;zerg schrieb:

Und wenn du dich jetzt vertippst, legst du still eine neue Variable an, statt einen Compilerfehler zu bekommen.

Klappt bei anderen Sprachen wunderbar, fühlst du dich nicht in der Lage solche Fehler zu entdecken?

Nein, bei anderen Sprachen klappt es nicht wunderbar. Sprachen wie Python (die du sehr zu verfechten scheinst, deinen Vorschlägen nach zu urteilen) werden, im Gegensatz zu C++, nicht für Projekte desselben Ausmaßes verwendet. Python ist gut, wenn man kurz eine Funktion plotten will oder ein bisschen Text transformieren will. Für alles Andere ist sie unbrauchbar - by design.
Außerdem: fühlst du dich nicht in der Lage, fünf Zeichen zu tippen, um Kontextsensibilität zu vermeiden?

asdasddsasd schrieb:

;zerg schrieb:

Wofür steht f? Für f? f()? f()()? f()()()?
Bin mir da nicht ganz sicher, ob in deinem Weltbild schon Funktionen existieren.

Da gibt es auch Sprachen die so etwas ohne Probleme auflösen können. MATLAB zum Beispiel. Ich würde mal behaupten dass 99% f() sind, ab da an tendiert es eher gegen Sonderfälle die mit Verstand auch übersichtlicher programmiert werden könen.

Du hast die Problematik verstanden.

[asdasdsadsad]

wpm schrieb:

Ob ein Ausdruck eine Definition oder eine Zuweisung ist, möchte ich gerne auch ohne Kontext wissen.

Ist nur ne persönliche Meinung, genau so unsinnig wie einige Java Programmierer meinen dass auto schlecht ist, weil sie immer wissen wollen mit welchem Typ sie es zu tun haben. Im Prinzip ne Ansichtssache, wobei wiederum okay, da ich wissen wollte was die Leute sonst so nervt. Vernünftige IDE's zeigen bei Bedarf den Typ sobald man mit der Maus über die Variable fährt.

wpm schrieb:

Die bereits komplizierten Konvertierungsregeln werden noch um ein Vielfaches schwieriger, nur um sich 2 (oder 1 mit vielen Editoren) Tastenanschlag zu sparen.

Wenn's einmal implementiert ist, ist es irrelevant während Millionen damit täglich Zeichen sparen. Dadurch wird es übersichtlicher und leichter zu lesen. (mMn)

wpm schrieb:

Ich habe alles Weiterführende lieber in Boost als in der STL. Da muss ich nicht drei Jahre auf einen Bugfix warten.

Guter Punkt, verstehe ich und sehe es genau so. Allerdings gibt es Dinge die schon längst abgefrühstückt sind. Da findet sich höchstens alle 10 Jahre mal ein Bug. Die können ruhig in die STL wandern. Es gibt leider immer wieder externe Vorgaben die Boost ausschließen.

wpm schrieb:

Die Pseudolösung von Python ist viel fehleranfälliger, u.A. da dort diesbezüglich keine Warnungen existieren.

Stimmt nicht, diesbezüglich gibt es überhaupt keine Probleme. Dies ist übrigens (mMn) einer der Gründe weswegen Python, MATLAB und co. hauptsächlich dafür verwendet werden schnell und elegant eine Lösung zu programmieren während C++ zunehmend in die Systemprogrammierung zurückfällt.

wpm schrieb:

Mein C++-Compiler warnt mich sofort, wenn der Kontrollfluss nicht mit der Einrückung übereinstimmt (was so gut wie nie passiert).

Mit dem Hinweis, dass es "-Wmisleading-indentation" erst seit GCC6? gibt.

wpm schrieb:

Außerdem ist es keine Sache, { oder ; zu tippen. Wie gesagt: einfach WPM trainieren...

Klar ist es. Es gibt sogar Mitarbeiter die nach jedem {} ein ; setzen. Egal ob notwendig oder nicht. Der Rotz sieht dann so aus:

void func()
{
   if( test )
   {
       // ...
   };
};

Mit dem Kommentar dass es so logisch und konsequent ist.

;zerg schrieb:

Sprachen wie Python (die du sehr zu verfechten scheinst, deinen Vorschlägen nach zu urteilen) werden, im Gegensatz zu C++, nicht für Projekte desselben Ausmaßes verwendet.

Hier hast du recht. Über die Gründe kann man sich dennoch unterhalten.

;zerg schrieb:

Python ist gut, wenn man kurz eine Funktion plotten will oder ein bisschen Text transformieren will. Für alles Andere ist sie unbrauchbar - by design.

Sehe ich nicht so, da gibt es andere Probleme. Python ist zu Jung, es gibt vieles noch nicht bzw. zuerst in C/C++. Außerdem ist Python per se lahm und muss es bei mathematischen Berechnungen über Wrapper in LAPACK usw.. ausgleichen. Außerdem kann man Python nicht vernünftig debuggen. Was mMn viel schlimmer ist als alle anderen Gründe zusammen.

;zerg schrieb:

Außerdem: fühlst du dich nicht in der Lage, fünf Zeichen zu tippen, um Kontextsensibilität zu vermeiden?

Es gibt einfach Funktionen die nur wegen ihrer Abwärtskompatibilität existieren und sonst nur für unbersichtlichen Sourcecode sorgen. Es ist ohnehin ein Thread um zu sehen was euch so ärgert, nothing to be offended of

[wob]

Ich stimme dir in allen Punkten zu, außer in:

wpm schrieb:

asdasdsadsad schrieb:

Am besten beginnen wir in der STL bei Dingen die auch sonst jede Sprache hat. Tokenize, Trim, ...

Ich habe alles Weiterführende lieber in Boost als in der STL. Da muss ich nicht drei Jahre auf einen Bugfix warten.

Es sollen ja gar nicht komplexe Dinge rein, sondern einfache Funktionen, die man häufig braucht. Klar kann ich boost/algorithm/string includen, aber erstens vergesse ich immer, ob es starts_with oder begins_with heißt (gut, der Editor hilft ja, aber in boost:: ist die Liste der möglichen Funktionen länger als wenn es eine String-Memberfunktion wäre, d.h. ich muss länger suchen). Und außerdem muss ich mir jedes Mal überlegen, in welcher Reihenfolge der Teilstring und der volle String übergeben werden müssen. Editor hilft wieder und sagt const Range1T &Input, const Range2T &Test . Gut, "Input" würde ja auf beides passen. Ah, Test aber passt nicht auf beides. So, wieder XXX Sekunden vergangen. Ist sehr nervig. Und vor allem ist boost::starts_with(s, "#") schwerer zu lesen als s.starts_with("#") .

Mir ist klar, dass man nicht jeden Sch... in der STL abdecken will. Andererseits sind zum Beispiel in <random> viele Pseudo-Random-Engines drin, die nur in irgendwelchen Spezialfällen gebraucht werden. Da hätte ich eher erwartet, ausschließlich mt19937 in der STL zu finden und den Rest in irgendeiner Mathematik-Bibliothek. Aber string::starts_with halte ich für so basic, dass es meiner Meinung nach in die STL gehört.

Eine Frage: was ist WPM? Meinst du words/min? Ergibt für mich keinen Sinn, denn das Tippen ist ja nicht das Problem, sondern das Überlegen, was man eigentlich machen will.

[wob]

PS: Mit "stimme dir zu" im vorherigen Post meinte ich WPMs Post.

[wpm]

asdasdsadsad schrieb:

genau so unsinnig wie einige Java Programmierer meinen dass auto schlecht ist, weil sie immer wissen wollen mit welchem Typ sie es zu tun haben.

Auch in C++ ist auto kein Allheilmittel und sollte auch nicht so verwendet werden. Man soll zwischen einem deduzierten und einem deklarativen Kontext (eigens erfundene Begriffe) unterscheiden. Speichert man den Rückgabewert, das Resultat, einer Operation oder einer Funktion, so ist auto fast immer korrekt, hin und wieder auch mal decltype(auto) . Legt man aber Objekte oder Variablen an, ist auto oft inkorrekt. Ich bekomme Krämpfe, wenn ich Abscheulichkeiten wie for(auto i = 0; zu lesen bekomme.

asdasdsadsad schrieb:

Vernünftige IDE's zeigen bei Bedarf den Typ sobald man mit der Maus über die Variable fährt.

Die Mehrheit der Programmierer nutzen Texteditoren und nicht IDEs.

asdasdsadsad schrieb:

wpm schrieb:

Die bereits komplizierten Konvertierungsregeln werden noch um ein Vielfaches schwieriger, nur um sich 2 (oder 1 mit vielen Editoren) Tastenanschlag zu sparen.

Wenn's einmal implementiert ist, ist es irrelevant während Millionen damit täglich Zeichen sparen. Dadurch wird es übersichtlicher und leichter zu lesen. (mMn)

Nein. Wenn ich ein Objekt vom Typ A in einen Kontext gebe, der einen Typ B erwartet, dann sind bislang die einzigen Konvertierungswege der implizite Konvertierungsoperator in A und der implizite Konstruktor in B. Mit deiner vorgeschlagenen Änderung werden aus diesen zwei Möglichkeiten unendlich viele, z.B.: B(A()) , B(A()()) etc. Als Programmierer, insbesondere als Library-Dev, muss ich all diese Sonderfälle berücksichtigen und u.U. explizit ausschließen.
Ein anderes Argument dagegen ist, dass man nicht mehr auf einen Blick sieht, welche Ausdrücke Nebeneffekte nach sich ziehen können. Wenn ich einen Block an Anweisungen ohne Klammerpaare habe, bin ich mir schon sehr sicher, dass der Code keine Nebeneffekte erzeugt. Das ist insbesondere in einer stark parallelen Umgebung hilfreich. Ohne dass man () schreiben muss, um eine Funktion aufzurufen, muss ich mir bei jedem Bezeichner überlegen, ob es sich um ein Objekt oder um eine Funktion handelt, bevor ich das beurteilen kann.
Und noch eins: wie soll man das lösen, wenn man z.B. einen Funktionszeiger übergeben möchte? Wie entscheidet der Compiler, ob er die Funktion vor der Übergabe aufrufen soll oder nicht? Ist m.E.n. unlösbar, insb. bei Template-Code. Oder was ist, wenn man eine Funktion aufruft, die ein Lambda zurückgibt? Da liegt der Hase im Pfeffer.

asdasdsadsad schrieb:

Es gibt leider immer wieder externe Vorgaben die Boost ausschließen.

Ist m.M.n. kein Argument, die Boost-Bibliotheken in die STL einzubetten. Das Problem liegt da nicht auf Seiten von C++ oder der STL, sondern ist auf idiotische Vorgaben zurückzuführen, zumal die Boost License die Nutzung im proprietären Kontext explizit vorsieht und gutheißt. Ferner ist Boost so konzipiert, dass sie sich wie als eine Erweiterung der STL verwenden lässt, und so fühlt sie sich auch an.

asdasdsadsad schrieb:

Sehe ich nicht so, da gibt es andere Probleme. Python ist zu Jung, es gibt vieles noch nicht bzw. zuerst in C/C++. Außerdem ist Python per se lahm und muss es bei mathematischen Berechnungen über Wrapper in LAPACK usw.. ausgleichen. Außerdem kann man Python nicht vernünftig debuggen. Was mMn viel schlimmer ist als alle anderen Gründe zusammen.

Stimme dir zu und will nur kurz hinzufügen, dass Python absolut nicht jung ist.

wob schrieb:

Es sollen ja gar nicht komplexe Dinge rein, sondern einfache Funktionen, die man häufig braucht. Klar kann ich boost/algorithm/string includen, aber erstens vergesse ich immer, ob es starts_with oder begins_with heißt (gut, der Editor hilft ja, aber in boost:: ist die Liste der möglichen Funktionen länger als wenn es eine String-Memberfunktion wäre, d.h. ich muss länger suchen). Und außerdem muss ich mir jedes Mal überlegen, in welcher Reihenfolge der Teilstring und der volle String übergeben werden müssen. Editor hilft wieder und sagt const Range1T &Input, const Range2T &Test . Gut, "Input" würde ja auf beides passen. Ah, Test aber passt nicht auf beides. So, wieder XXX Sekunden vergangen. Ist sehr nervig. Und vor allem ist boost::starts_with(s, "#") schwerer zu lesen als s.starts_with("#") .

Bei <string> (aber auch nur dort) stimme ich dir zu, denn dieser Header ist leider broken. Auch das Gewirr mit Iteratoren und Indices ist haarsträubend.

wob schrieb:

Mir ist klar, dass man nicht jeden Sch... in der STL abdecken will. Andererseits sind zum Beispiel in <random> viele Pseudo-Random-Engines drin, die nur in irgendwelchen Spezialfällen gebraucht werden. Da hätte ich eher erwartet, ausschließlich mt19937 in der STL zu finden und den Rest in irgendeiner Mathematik-Bibliothek.

Sehe ich nicht so. std::mt19937 hat einen gigantischen Zustand. Wenn ich einen Vektor von sagen wir 100 Elementen shufflen will, dann nutze ich in absolut jedem Fall etwas Kleines, wie beispielsweise minstd.

wob schrieb:

Eine Frage: was ist WPM? Meinst du words/min? Ergibt für mich keinen Sinn, denn das Tippen ist ja nicht das Problem, sondern das Überlegen, was man eigentlich machen will.

Der OP hat ursprünglich oft mit Tipparbeit argumentiert, was m.M.n. Blödsinn ist. Ein Klammerpaar zu tippen, sollte als Programmierer keine relevante Zeit in Anspruch nehmen.

[asc]

wpm schrieb:

Die Mehrheit der Programmierer nutzen Texteditoren und nicht IDEs.

Hast du für diese Aussage Quellen? Ich kenne nahezu keinen Entwickler (zumindest nicht im beruflichen Umfeld) der vorwiegend reine Editoren zum programmieren nutzt.

[asdasdsadsad]

wpm schrieb:

Ich bekomme Krämpfe, wenn ich Abscheulichkeiten wie for(auto i = 0; zu lesen bekomme.

Dürfte sich mit for( const auto & i : container ) ohnehin halbwegs erledigt haben. Im Zweifel fahre ich einfach mit der Maus drüber. Dann wäre noch for( auto i = 0u ; ... ) usw...

wpm schrieb:

Die Mehrheit der Programmierer nutzen Texteditoren und nicht IDEs.

Wusste ich ich jetzt nicht. Würde eher denken dass in der Praxis eher IDE's eingesetzt werden. Mein Debugging ist deutlich bequemer geworden, seit sich Variablen pinnen lassen und expressions live ausgeführt werden. Dann wären noch Debugging-Zustände speichern, Profiling, UML, Automatische Klassenerstellung, Versionsverwaltung, OpenGL Debugger, Architecture Maps, Multiarch Builds, Compiler/Linker Settings durch Klicks, Metriken, Packaging. Ist schon bequemer alles aus einem Guß zu nehmen. Soweit ich weiß beherrschen freie IDE's wie Eclipse CDT oder QT Creator schon das meiste aus dier Liste. Ich könnte nie wieder in die GDB Konsole um etwas zu debuggen.

wpm schrieb:

Nein. Wenn ich ein Objekt vom Typ A in einen Kontext gebe, der einen Typ B erwartet, dann sind bislang die einzigen Konvertierungswege der implizite Konvertierungsoperator in A und der implizite Konstruktor in B. Mit deiner vorgeschlagenen Änderung werden aus diesen zwei Möglichkeiten unendlich viele, z.B.: B(A()) , B(A()()) etc. Als Programmierer, insbesondere als Library-Dev, muss ich all diese Sonderfälle berücksichtigen und u.U. explizit ausschließen.

Ich denke dass sich der meiste Rotz mit explicit und '= delete' aus dem Weg räumen lässt. Es wurde in der Vergangenheit auch einiges behauptet was sich im Praxisfall als einfach entpuppte, allerdings manchmal auch andersherum. Dinge die du beschreibst existieren auch so und werden weiterhin existieren.

Es geht darum ein paar Ideen für die Zukunft zu sammeln. Ich schreibe gerade an einem Regex welches leere Funktionsaufrufe, Klammern und Semikolons mit 50% opaque markiert. Mal sehen wie es aussieht und ob es doch nicht störend ist

Ein anderes Argument dagegen ist, dass man nicht mehr auf einen Blick sieht, welche Ausdrücke Nebeneffekte nach sich ziehen können. Wenn ich einen Block an Anweisungen ohne Klammerpaare habe, bin ich mir schon sehr sicher, dass der Code keine Nebeneffekte erzeugt. Das ist insbesondere in einer stark parallelen Umgebung hilfreich. Ohne dass man () schreiben muss, um eine Funktion aufzurufen, muss ich mir bei jedem Bezeichner überlegen, ob es sich um ein Objekt oder um eine Funktion handelt, bevor ich das beurteilen kann.
Und noch eins: wie soll man das lösen, wenn man z.B. einen Funktionszeiger übergeben möchte? Wie entscheidet der Compiler, ob er die Funktion vor der Übergabe aufrufen soll oder nicht? Ist m.E.n. unlösbar, insb. bei Template-Code. Oder was ist, wenn man eine Funktion aufruft, die ein Lambda zurückgibt? Da liegt der Hase im Pfeffer.

C++ hat schon jetzt für bestimmte Bereiche leicht abgeänderte Syntaxregeln... habe ja nicht gesagt dass die Arbeit am Standard trivial ist.

Ist m.M.n. kein Argument, die Boost-Bibliotheken in die STL einzubetten.

Ist aber derzeitige Praxis. Nach und nach wandert immer mehr von Boost in die STL, teilweise 1 zu 1.

Das Problem liegt da nicht auf Seiten von C++ oder der STL, sondern ist auf idiotische Vorgaben zurückzuführen, zumal die Boost License die Nutzung im proprietären Kontext explizit vorsieht und gutheißt. Ferner ist Boost so konzipiert, dass sie sich wie als eine Erweiterung der STL verwenden lässt, und so fühlt sie sich auch an.

Ohne es bewerten zu wollen ist es gängige Praxis.

Stimme dir zu und will nur kurz hinzufügen, dass Python absolut nicht jung ist.

Glaubt man fragwürdigen Ratings ( http://www.tiobe.com/tiobe-index/python/ ) so ist dessen Bekanntheit nur sehr beschränkt gewesen. Mit der Einführung von Jupyter und PTVS ist es stark gewachsen. Wenn es sich irgendwann im Jupyter noch vernünftig debuggen lässt und Plots so wie MATLAB dynamisch verändern kann dann kommt der nächste Sprung.

[Mechanics]

asc schrieb:

wpm schrieb:

Die Mehrheit der Programmierer nutzen Texteditoren und nicht IDEs.

Hast du für diese Aussage Quellen? Ich kenne nahezu keinen Entwickler (zumindest nicht im beruflichen Umfeld) der vorwiegend reine Editoren zum programmieren nutzt.

Das ist nicht mal so relevant... Ich nutze meist eine IDE, aber ich will trotzdem nicht die ganze Zeit mit der Maus über irgendwas drüberfahren. Wir haben sehr viel Code und den meisten kenne ich nicht auswendig. Wenn ich Code lese, will ihn gleich verstehen.
Wenn ich irgendwo

auto ret = func(x, y, z);

sehe, habe ich auf den ersten Blick keine Ahnung, was ret ist. Ich wills aber wissen, und nicht erst zur Maus greifen müssen.
Die einzige Stelle überhaupt, wo ich auto verwende, sind Iteratoren.

[Columbo]

Mechanics schrieb:

Die einzige Stelle überhaupt, wo ich auto verwende, sind Iteratoren.

Und Lambdas. Und Boost.Spirit Ausdrücke. Und all die anderen Stellen, die du bereits vergessen hast, weil auto so furchtbar angenehm ist.

[take_muple]

Und std::make_tuple . Und std::make_unique . Und std::make_shared . Und std::chrono::*_clock::(duration|time_point) .

[Mechanics]

Ok, ihr habt Recht.
Aber jedenfalls nicht für auto irgendwas = irgendeineFunktionDieKeinerKennt();

[dot]

asdasdsadsad schrieb:

Obwohl C++ mit den Standards 11/14/17 schon deutlich übersichtlicher geworden ist, wünschte ich mir (leider) ein paar Brüche mit dem Standard um sich ein wenig Tipparbeit zu sparen.

https://isocpp.org/std/submit-a-proposal

[Columbo]

take_muple schrieb:

Und std::make_tuple . Und std::make_unique . Und std::make_shared . Und std::chrono::*_clock::(duration|time_point) .

Neh, das ändert sich dann mit C++17 (siehe template argument deduction for constructors - sehr nettes Feature).

[asdasdsadsad]

Mechanics schrieb:

Das ist nicht mal so relevant... Ich nutze meist eine IDE, aber ich will trotzdem nicht die ganze Zeit mit der Maus über irgendwas drüberfahren. Wir haben sehr viel Code und den meisten kenne ich nicht auswendig. Wenn ich Code lese, will ihn gleich verstehen.
Wenn ich irgendwo

auto ret = func(x, y, z);

sehe, habe ich auf den ersten Blick keine Ahnung, was ret ist. Ich wills aber wissen, und nicht erst zur Maus greifen müssen.
Die einzige Stelle überhaupt, wo ich auto verwende, sind Iteratoren.

Ich verwende auto wo es möglich ist. Ist soweit ich weiß auch eine Empfehlung von Sutter, Meyers und co. Damit spart man sich bei Änderungen einiges Tipparbeit. Gerade wenn die Bibliotheken umfangreicher sind. Klar es gibt auch Nachteile für diejenigen deren IDE oder Editor nicht den Typ selbst ableiten kann oder wer seine Maus nicht schubsen will aber dennoch überwiegen die Vorteile.

[manni66]

Mechanics schrieb:

Wenn ich irgendwo

auto ret = func(x, y, z);

sehe, habe ich auf den ersten Blick keine Ahnung, was ret ist

Wenn die Namensgebung tatsächlich so sinnfrei wie im Beispiel ist, wundert mich das nicht.

Mechanics schrieb:

Die einzige Stelle überhaupt, wo ich auto verwende, sind Iteratoren.

Ich verwende es fast überall.