default auto statt default int

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.

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.

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

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.

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.

Arcoth schrieb:

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

Was "Neh"? Wer redet denn von C++17? Weder GCC 7 noch Clang 4 haben kompletten C++17-Support, zumal C++17 noch nicht einmal endgültig verabschiedet wurde. Und ohne C++17 ist meine Aussage korrekt, nichts "Neh".
Dein abschätzendes und arrogantes Aufführen geht übrigens nicht nur mir auf den Wecker.

Columbo

take_muple schrieb:

Arcoth schrieb:

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

Was "Neh"? Wer redet denn von C++17?

Ich.

take_muple schrieb:

Weder GCC 7 noch Clang 4 haben kompletten C++17-Support,

Natürlich nicht. Mein Proposal wurde ja auch in letzter Minute von Core akzeptiert. Hat im Übrigen wenig damit zu tun, wie sinnvoll meine Anmerkung war.

take_muple schrieb:

zumal C++17 noch nicht einmal endgültig verabschiedet wurde.

Das hat wieder niemand behauptet. Das von mir erwähnte Feature ist garantiert drin, schau dir doch mal die Polls im EDG Wiki an. Es ist bereits in GCC implementiert, aber nicht nur das—deduction guides werden in die Standardbibliothek integriert. Zudem war meine Aussage mehr als ein Tipp gemeint, weniger als eine Korrektur. Du versuchst krampfhaft mich so misszuverstehen, dass ich als erniedrigend rüberkomme. Lass doch einfach mal mein überproportionales Ego aus dem Spiel.