default auto statt default int

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

[take_muple]

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.