Programmiersprachen: Erste Pläne für C++20 veröffentlicht https://www.heise.de/developer/meldung/Programmiersprachen-Erste-Plaene-fuer-C-20-veroeffentlicht-3772568.html
Die sollen mal aufhören alle paar Jahre die Sprache komplett umzukrempeln. Wer soll denn da hinterher kommen, den Kram zu lernen... ;-)
Was heißt hier komplett umkrempeln. Es ist schön das C++ sich nach all den Jahren wieder ein wenig bewegt. Viele Sachen waren einfach nicht mehr Zeitgemäß. Kein Wunder, der Standard von 1989 war ja ewig Stand der Dinge. So wichtige Sachen wie Threads, Lambdas etc. gehören einfach in eine moderne Sprache.
Ich freue mich erstmal auf C++17. Ich denke, dahin werde ich dann mein Wissen mal erweitern. Ich stehe ehrlich gesagt noch auf C++98… Wie lange dauert es eigentlich, bis Compiler neue Standards unterstützen? Ab wann ist zum Beispiel damit zu rechnen, dass g++ oder Clang C++17 unterstützen? Oder tun sie das schon?
nicht"Gast" schrieb: > Was heißt hier komplett umkrempeln. Es ist schön das C++ sich nach all > den Jahren wieder ein wenig bewegt. > > Viele Sachen waren einfach nicht mehr Zeitgemäß. Kein Wunder, der > Standard von 1989 war ja ewig Stand der Dinge. So wichtige Sachen wie > Threads, Lambdas etc. gehören einfach in eine moderne Sprache. Huhu, wir haben 2017! Und C++17, was soll sich nach all den Tagen dringend ändern?
Dussel schrieb: > Oder tun sie das schon? https://gcc.gnu.org/projects/cxx-status.html#cxx1z https://clang.llvm.org/cxx_status.html#cxx17
Dussel schrieb: > Ab wann ist zum Beispiel damit zu rechnen, dass g++ oder > Clang C++17 unterstützen? Oder tun sie das schon? Klar, schon lange.
Beitrag #5080576 wurde vom Autor gelöscht.
Hi, die sollten lieber mal veraltete Dinge über Bord werfen, um den Sprachumfang, und somit nicht zuletzt die Komplexität etwas in Zaun zu Halten. Gruß
Mod schrieb: > Hi, die sollten lieber mal veraltete Dinge über Bord werfen, um > den > Sprachumfang, und somit nicht zuletzt die Komplexität etwas in Zaun zu > Halten. > Gruß C++ aktualisieren ohne Abwärtskompatibilität? Dann kann man es sich auch gleich sparen, da steigt keiner um. Es zwingt einen ja keiner die "veralteten Dinge" zu verwenden, oder?
Da D. schrieb: > Die sollen mal aufhören alle paar Jahre die Sprache komplett > umzukrempeln. Wer soll denn da hinterher kommen, den Kram zu lernen... > ;-) Die Weiterentwicklung von C++ geschieht ja noch relativ langsam. Schau dir mal an, mit welcher Frequenz neue C#-Versionen hinausgeballert werden :) Mod schrieb: > Hi, die sollten lieber mal veraltete Dinge über Bord werfen, um den > Sprachumfang, und somit nicht zuletzt die Komplexität etwas in Zaun zu > Halten. Mal angenommen, Abwärtskompatibilität wäre kein Kriterium: Welche alten Features sollte man deiner Ansicht weglassen, so dass 1. der Sprache keine wesentliche Funktionalität genommen wird und 2. tatsächlich eine deutliche Verschlankung der Sprache erreicht wird? So arg viel gibt es da nicht. Ich mag C++ auch nicht besonders, aber es ist eine der ganz wenigen Sprachen, in der man einserseits so maschinennah und performant wie in C programmieren kann, auf der anderen Seite aber auch eine ganze Menge High-Level-Features geboten bekommt. Das macht es für mich trotz vieler Holprigkeiten interessant. Die seit C++11 neu eingeführten Sprachelemente betreffen vor allem die High-Level-Programmierung und die Reduktion der stellenweise durch die Verwendung von High-Level-Features bedingten Performanceverluste. Das stellt IMHO einen deutlichen Fortschritt dar und macht für mich C++ zunehmend attraktiv. Leider sind meine C++-Kenntnisse recht bruchstückhaft, und die neuen Features wollen z.T. richtig gelernt werden (in Python fällt es mir bspw. viel leichter, Schritt mit der aktuellen Entwicklung zu halten). Mein letztes C++-Buch ist von 1998, darüber hinausgehendes Wissen habe ich stückweise (und damit unvollständig) aus dem Internet erlangt. Deswegen werde ich meine Vorbehalte etwas zurückstellen und mir demnächst nach einem guten Lehrbuch umsehen und dieses systematisch durcharbeiten. Selbst wenn mir dann C++ immer nocht nicht gefällt, kann ich wenigstens fundiert darüber meckern ;-)
Hallo, Mod schrieb: > Hi, die sollten lieber mal veraltete Dinge über Bord werfen, um > den > Sprachumfang, und somit nicht zuletzt die Komplexität etwas in Zaun zu > Halten. das ist so ein Barnum-Satz wie in Horoskopen. Kann man auf einen Großteil aller Änderungen / Neuerungen antworten. Was konkret wären denn solche veralteten Dinge, die über Bord gehören? Ich arbeite mich seit kurzem in C++14 ein (früher viel mit c++98 gemacht) und bin bisher extremst begeistert und habe bisher eigentlich den Eindruck, dass der Großteil recht übersichtlich, im Sinne von logisch konsistent, ist. Vor allem nach aktuell wirklich frustrierenden Erfahrungen mit den dauernden alles umstürzenden Swift Releases. vlg Timm Edit: Ja gut, man könnte zum Beispiel argumentieren, dass std::bind weg kann. Ich denke aber, man müsste da schon zwischen Sprachfeatures im engeren Sinne und unter Benutzung der Sprachfeatures zur Verfügung gestellten Funktionen in der Standardbibliothek unterscheiden. Abgesehen davon schafft das Beibehalten von std::bind keine Komplexität. Wenn ich es nicht benutzen will, muss ich mich 0.00 damit beschäftigen, es entgeht einem absolut gar nichts, weil die c++14 Lambdas ein vollwertiger Ersatz sind. Das einzige Ergebnis wäre, dass alter Code nicht mehr funktionieren würde. Anders sieht es mit der type deduction aus, die ist so allgegenwärtig, dass man sich damit beschäftigen muss, ob man will oder nicht. Die schafft etwas Komplexität, ist aber keine Altlast. Also: Wo ist die Altlast, die Komplexität schafft?
:
Bearbeitet durch User
Timm R. schrieb: > ... > Ich denke aber, man müsste da schon zwischen Sprachfeatures im engeren > Sinne und unter Benutzung der Sprachfeatures zur Verfügung gestellten > Funktionen in der Standardbibliothek unterscheiden. > > Abgesehen davon schafft das Beibehalten von std::bind keine Komplexität. > Wenn ich es nicht benutzen will, muss ich mich 0.00 damit beschäftigen, > es entgeht einem absolut gar nichts, weil die c++14 Lambdas ein > vollwertiger Ersatz sind. Das einzige Ergebnis wäre, dass alter Code > nicht mehr funktionieren würde. > > Anders sieht es mit der type deduction aus, die ist so allgegenwärtig, > dass man sich damit beschäftigen muss, ob man will oder nicht. Die > schafft etwas Komplexität, ist aber keine Altlast. > > Also: Wo ist die Altlast, die Komplexität schafft? Da C++17, ff. immer noch abwärtskompatibel sind, muss(!) man sich mit type-deduction nicht beschäftigen. Setzt man aber type-deduction richtig ein, wird der Code leichter verständlich. Und das ist ein wesentliches Feature. Vor allem bei automatischer Typinferenz von class-template Parametern. Dasselbe gilt für concepts/constraints (mein persönliches highlight zusammen mit modules). Wobei concepts/constraints wirklich Möglichkeiten schaffen, die es in der Form vorher nicht gab (man kann nicht alles mit SFINAE erschlagen). Hier also ein Feature, das neue Möglichkeiten schafft (zusammen mit constexpr-if) und gleichzeitig Altlasten / Hacks wie SFINAE entsorgt.
Kaj G. schrieb: > Dussel schrieb: >> Ab wann ist zum Beispiel damit zu rechnen, dass g++ oder >> Clang C++17 unterstützen? Oder tun sie das schon? > Klar, schon lange. Laut dieser Seite: http://en.cppreference.com/w/cpp/compiler_support unterstützen sie C++17 zu 99%. P0067R5 scheint noch zu fehlen.
Mir fallen schon ein paar Dinge ein, die man weglassen kann. Was mich an C++ am meisten stört (und es wird ja auch so kommuniziert): Es wird immer gesagt, dieses und jenes könne man in C++ besser lösen (einfachstes Beispiel: ptr vs. smart_ptr). Nur richtig umgesetzt wirds nicht. Es ist zwar vorhanden (smart_ptr) aber der Programmierer wird nicht dazu gezwungen. Und das ist für mich ein gewaltiger Nachteil. Und es gibt viele Dinge wo es so umgesetzt wird. Das ist ein gewisser Grad von Inkonsistenz. Jeder weiß, dass C gewisse Nachteile hat. Diese Nachteile will man mit C++ abfangen bzw. verbessern. Aber um die Abwärtskompatibilität unbedingt aufrecht zu erhalten zieht man es doch nicht richtig durch. Das heißt für mich, man kombiniert die negativen Eigenschaften von C mit neuen negativen Eigenschaften (z.B. Ellenlange Definitionen).Warum nicht
1 | uint8_t *ptr |
per default zu einem smart_ptr machen? Was spricht denn dagegen? Die Macher von C++ müssen sich IMHO entscheiden was sie wollen: Entweder eine moderne, typsichere Sprache die C# und Java Konkurrenz machen kann, oder sie bleibt halt immer C mit Erweiterung. Ein ähnlicher harter Schritt wie in python würde dem Standard denke ich gut tun.
Hallo Wilhelm, Wilhelm M. schrieb: > Da C++17, ff. immer noch abwärtskompatibel sind, muss(!) man sich mit > type-deduction nicht beschäftigen. Klar. Man muss sich nicht damit beschäftigen. Was ich meinte ist, dass einem wesentliches entgeht, wenn an es nicht tut. Anders als (soweit ich erkennen kann), wenn man sich nicht mit std::bind beschäftigt. Da entgeht einem praktisch gar nichts. imho. vlg Timm Edit: Vielen Dank übrigens für die extrem interessanten Stichworte!
:
Bearbeitet durch User
ui schrieb: > Mir fallen schon ein paar Dinge ein, die man weglassen kann. Was mich an > C++ am meisten stört (und es wird ja auch so kommuniziert): Es wird > immer gesagt, dieses und jenes könne man in C++ besser lösen > (einfachstes Beispiel: ptr vs. smart_ptr). Nur richtig umgesetzt wirds > nicht. Es ist zwar vorhanden (smart_ptr) aber der Programmierer wird > nicht dazu gezwungen. Und das ist für mich ein gewaltiger Nachteil. Und > es gibt viele Dinge wo es so umgesetzt wird. Das ist Aufgabe desjenigen, der er Interface schreibt. Und da es noch reine C-Bibliotheken und auch alte C++ Bibliotheken gibt, wird das so bleiben. Im Übrigen ist daran auch wenig Schlimmes. Man muss sich eben nur über die unterschiedlichen Zeigertypen und ihre Semantik im klaren sein. Es gibt eben Zeiger mit Eigentümerschaft und solche ohne (reine Benutzungsrelation). > Das ist ein gewisser Grad von Inkonsistenz. Jeder weiß, dass C gewisse > Nachteile hat. Diese Nachteile will man mit C++ abfangen bzw. > verbessern. Aber um die Abwärtskompatibilität unbedingt aufrecht zu > erhalten zieht man es doch nicht richtig durch. Das heißt für mich, man > kombiniert die negativen Eigenschaften von C mit neuen negativen > Eigenschaften (z.B. Ellenlange Definitionen). Sehe ich nicht. > Warum nicht >
1 | > uint8_t *ptr |
2 | >
|
> per default zu einem smart_ptr machen?
Weil das nicht sinnvoll ist (s.o.).
Hallo, ehrlich gesagt frage ich mich, ob Du nicht eventuell „keinen Durchblick haben" mit Komplexität verwechselst? Dein Ansatz Implentierungsentscheidungen des Entwicklers durch Eingleisigkeit der Sprachumgebung zu ersetzen ist, soweit ich das erkennen kann, ziemlich genau das Gegenteil der Philosophie von C++. ui schrieb: Warum nicht >
1 | > uint8_t *ptr |
2 | >
|
> per default zu einem smart_ptr machen? Was spricht denn dagegen?
Na dann mal Butter bei die Fische, wie das hier bei uns heißt, welcher
Smart Pointer solls denn sein? Dann wirst Du auch sehen warum das eine
schlechte Idee ist.
smart_ptr gibt es nicht.
vlg
Timm
ui schrieb: > Warum nicht > uint8_t *ptr > per default zu einem smart_ptr machen? Die verschiedenen Typen von Smart Pointern in C++ sind nur sinnvoll und überhaupt verwendbar in Verbindung mit dynamisch allozierten Objekten. Solange nicht alle Objekte in einem Programm dynamisch alloziert werden, braucht man auch klassische Pointer bzw. Referenzen.
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Die verschiedenen Typen von Smart Pointern in C++ sind nur sinnvoll und > überhaupt verwendbar in Verbindung mit dynamisch allozierten Objekten. > Solange nicht alle Objekte in einem Programm dynamisch alloziert werden, > braucht man auch klassische Pointer bzw. Referenzen. Nein (also: ... nicht alle ...): wenn mindestens ein Objekt dynamisch allokiert wird (und dies sollte man in MCPP mit std::make_shared<>() bzw. std::make_unique<>() machen), verwendet man Intelligente Zeiger.
Wilhelm M. schrieb: > Nein (also: ... nicht alle ...): wenn mindestens ein Objekt dynamisch > allokiert wird (und dies sollte man in MCPP mit std::make_shared<>() > bzw. std::make_unique<>() machen), verwendet man Intelligente Zeiger. Ja, aber eben nur für die dynamischen Objekte. Ein shared_ptr oder unique_ptr auf andere Variablen führt i.Allg. zu einem fehlerhaften Verhalten zur Laufzeit. Wenn man einen Pointer auf eine dieser anderen Variablen zeigen lassen möchte, kommt man um einen klassischen Pointer (oder alternativ eine Referenz) nicht herum.
ui schrieb: > Warum nicht >
1 | > uint8_t *ptr |
2 | >
|
> per default zu einem smart_ptr machen? Was spricht denn dagegen? 1) ist `std::uint8_t *ptr` einfach eine Referenz auf ein std::uint8_t. Smart Pointer verwendet man aber nur da, wo es um die Verwaltung von dynamischen Speicher und dessen Besitz geht. 2) Welchen smart pointer möchtest Du den haben? shared_ptr<> wäre wohl in den meisten Fällen nicht falsch. unique_ptr<> aber wohl in den allermeisten Fällen richtig (Vorraussetzung). Wenn Du in C++ einfach blind jeden Zeiger durch einen smart pointer ersetzt, dann wirst Du sehr wahrscheinlich jede Menge Fehler in Deine Applikation bauen. Vorallem, wenn man denkt, sich dann keine Gedanken mehr um Design machen zu müssen. Die meisten Probleme mit Memory-Problemen, die ich bis jetzt gesehen haben, waren in Java und C# Applikationen, weil die Kollegen erst am Ende der Entwicklung gemerkt haben, dass Garbage-Collection halt nicht alles heil macht. > Die Macher von C++ müssen sich IMHO entscheiden was sie wollen: Entweder > eine moderne, typsichere Sprache die C# und Java Konkurrenz machen kann, > oder sie bleibt halt immer C mit Erweiterung. Worin glaubst Du, sind die VMs von C# und Java geschrieben?
Hallo, Yalu X. schrieb: > Ja, aber eben nur für die dynamischen Objekte. Ein shared_ptr oder > unique_ptr auf andere Variablen führt i.Allg. zu einem fehlerhaften > Verhalten zur Laufzeit. Wenn man einen Pointer auf eine dieser anderen > Variablen zeigen lassen möchte, kommt man um einen klassischen Pointer > (oder alternativ eine Referenz) nicht herum. warum gibt das denn eine Abwertung? Auf einen einfachen Datentyp wie zB float, als normale Variable kann man doch keinen Smart Pointer setzen? Stimmt doch? Will man auch gar nicht, aber das ist eine andere Frage. Ich habe noch zwei Fragen / Anmerkungen. 1) Ein shared_ptr und ein unique_ptr haben doch einen memory overhead? Das könnte doch unter Umständen auch ein Grund für einen raw pointer sein? 2) Bei einer cyclischen Referenz wie dieser (oder so ähnlich):
1 | class X |
2 | {
|
3 | public:
|
4 | std::shared_ptr<X> sibling; |
5 | }
|
6 | |
7 | int main() |
8 | {
|
9 | std::shared_ptr a = make_shared<X>(); |
10 | std::shared_ptr b = make_shared<X>(); |
11 | a->sibling = b; |
12 | b->sibling = a; |
13 | }
|
ist doch mit shared_ptr Schicht im Schacht, während es sich in diesem Fall mit raw Pointern, auch wenn X einen speziellen dtor hätte, einfach in Wohlgefallen auflösen würde? Jeder Pointer hat halt so seine Funktionalität und danach muss man sie eben auswählen, auch der raw-Pointer? Zurück zum ursprünglichen Thema: Der auto_ptr ist doch mittlerweile tot, oder? Das wäre doch ein Beispiel für eine beerdigte Altlast? vlg Timm
Timm R. schrieb: > 1) > Ein shared_ptr und ein unique_ptr haben doch einen memory overhead? Das > könnte doch unter Umständen auch ein Grund für einen raw pointer sein? Eigentlich hat nur der std::shared_ptr<>() einen memory-overhead. (Solange beim std::unique_ptr<> kein spezieller deleter eingesetzt wird). Der Indirektionsnachteil sollte bei beiden null sein. > > 2) > Bei einer cyclischen Referenz wie dieser (oder so ähnlich): ... > ist doch mit shared_ptr Schicht im Schacht, während es sich in diesem > Fall mit raw Pointern, auch wenn X einen speziellen dtor hätte, einfach > in Wohlgefallen auflösen würde? Dafür haben wir std::weak_ptr. > Jeder Pointer hat halt so seine Funktionalität und danach muss man sie > eben auswählen, auch der raw-Pointer? Ja, wie schon (so oft) geschrieben: non-owning-pointer bzw. Zeiger, die nur eine Benutzungsrelation ausdrücken. > > Zurück zum ursprünglichen Thema: Der auto_ptr ist doch mittlerweile tot, > oder? Das wäre doch ein Beispiel für eine beerdigte Altlast? Ja, wobei er von Anfang an tot war und deswegen so gut wie nie verwendet wurde (ist ein Spezialfall mit Verschiebungssemantik).
:
Bearbeitet durch User
cpp schrieb: > Programmiersprachen: Erste Pläne für C++20 veröffentlicht > https://www.heise.de/developer/meldung/Programmiersprachen-Erste-Plaene-fuer-C-20-veroeffentlicht-3772568.html Das einzige was man muss, ist das #pragma/compilerschalter um den Code genauso wie bewährt schreiben und übersetzen zu können.
Yalu X. schrieb: > Deswegen werde ich meine Vorbehalte etwas zurückstellen und mir > demnächst nach einem guten Lehrbuch umsehen und dieses systematisch > durcharbeiten. Was für ein Buch wäre für C++17 denn zu empfehlen ?
interrupt schrieb: > Yalu X. schrieb: >> Deswegen werde ich meine Vorbehalte etwas zurückstellen und mir >> demnächst nach einem guten Lehrbuch umsehen und dieses systematisch >> durcharbeiten. > > Was für ein Buch wäre für C++17 denn zu empfehlen ? Derzeit gibt es eigentlich nur Bücher zu c++11/14. Aber das reicht eigentlich auch, die wesentlichen Dingen sind schon im Übergang c++98->c++11 gewesen. Den Rest kann man sich eigentlich aus http://en.cppreference.com/w/ erlesen und den einschlägigen Blogs wie https://isocpp.org/blog oder C++Weekly von Jason, bzw. auch den guten Beiträgen von https://herbsutter.com/ http://foonathan.net/ https://akrzemi1.wordpress.com/ http://www.fluentcpp.com/ u.dgl.m. Wobei die Themen concepts/constraints (nur im gcc) und modules (nur im clang) naturgemäß schwer zu finden sind.
ui schrieb: > Warum nicht uint8_t *ptr > per default zu einem smart_ptr machen? Wäre das nicht problematisch an Stellen, wo man Pointer nutzt, ohne in irgendeiner Weise (auch nicht indirekt) malloc/free zu verwenden? Vor allem in bestehendem Code, den man nicht extra umschreiben will?
Nop schrieb: > ui schrieb: > >> Warum nicht uint8_t *ptr >> per default zu einem smart_ptr machen? > > Wäre das nicht problematisch an Stellen, wo man Pointer nutzt, ohne in > irgendeiner Weise (auch nicht indirekt) malloc/free zu verwenden? Selbstverständlich!!! Das darf nicht sein! Aber das ist auch alles schon oben geschrieben worden. Nochmal: es gibt Zeiger mit Eigentümerschaft (typischerweise als SmartPointer bezeichnet) wie std::unique_ptr<> und std::shared_ptr<> und solche ohne Eigentümerschaft wie std::observer_ptr<> oder std::weak_ptr<> und natürlich auch Rohe Zeiger. Und natürlich darf man Zeiger mit Eigentümerschaft auch nur dort einsetzen, wo man ein Objekt erzeugt hat, dessen Lebensdauer nicht-automatisch geregelt wird, also typischerweise Objekte auf der Halde. Und damit man dabei so wenig Fehler wie möglich machen kann, ist in MCPP die Erzeugung von Objekten mit dyn. storage durch die Hilfsfunktionstemplates std::make_unique<> und std::make_shared<> bevorzugt (nie mehr ein explizites new/delete). Damit wäre dann auch obiges Konstrukt ersetzt durch einen SmartPointer zwar nicht unmöglich, jedoch sofort durch statische Code-Analyse aufzudecken. Die rohen Zeiger bleiben damit für die Modellierung einer reinen Benutzungsrelation ohne Eigentümerschaft. Dies können auch Zeiger auf statische oder lokale Objekte sein. Im allg. sollte man Referenzen vorziehen, wenn man kann, und rohe Zeiger benutzen, wenn man muss, bspw. wenn man auch ausdrücken können muss, dass man kein Objekt referenziert (nullptr).
Wilhelm M. schrieb: > Derzeit gibt es eigentlich nur Bücher zu c++11/14. Und welches wäre da zu empfehlen ?
interrupt schrieb: > Wilhelm M. schrieb: >> Derzeit gibt es eigentlich nur Bücher zu c++11/14. > > Und welches wäre da zu empfehlen ? m.E. Breymann; "Der C++Programmierer", neue Auflage! Grimm, "C++11" Meyers, "Effective modern C++" Josuttis, "The C++ Standard Library" Bancila, "Modern C++ Programming Cookbook"
Hallo, Wilhelm M. schrieb: > oder C++Weekly von Jason, bzw. auch den guten Beiträgen von > > https://herbsutter.com/ > > http://foonathan.net/ > > https://akrzemi1.wordpress.com/ > > http://www.fluentcpp.com/ Hammer! Wer noch nicht reingeschaut hat und 98er ist, wie ich, sollte unbedingt mal reinstöbern. Fluentcpp zum Beispiel schreibt wirklich locker und auch didaktisch sehr sehr gut. Danke! Vlg Timm
Timm R. schrieb: > Hallo, > > Wilhelm M. schrieb: > >> oder C++Weekly von Jason, bzw. auch den guten Beiträgen von >> >> https://herbsutter.com/ >> >> http://foonathan.net/ >> >> https://akrzemi1.wordpress.com/ >> >> http://www.fluentcpp.com/ > > Hammer! Wer noch nicht reingeschaut hat und 98er ist, wie ich, sollte > unbedingt mal reinstöbern. Fluentcpp zum Beispiel schreibt wirklich > locker und auch didaktisch sehr sehr gut. > > Danke! > > Vlg > Timm Hatte vergessen https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines explizit zu erwähnen (oh, ich höre schon den Aufschrei: eine Sprache, die so etwas braucht, ist nicht zu gebrauchen ...) Ich finde diese Guidelines und die GSL aus zwei Aspekten interessant: 1) Wie die C++-SuperFAQ ein gut strukturiertes Nachschlagewerk, das speziell auf MCPP ausgerichtet ist (beantwortet damit auch die Frage nach den Altlasten (s.o.). 2) Es sind schon viele Hinweise auf die künftigen Änderungen / Planungen eingebaut (z.B. uniform-function-call Syntax und Concepts / Constraints).
Wilhelm M. schrieb: > 1) Wie die C++-SuperFAQ ein gut strukturiertes Nachschlagewerk, das > speziell auf MCPP ausgerichtet ist (beantwortet damit auch die Frage > nach den Altlasten (s.o.). Du benutzt immer wieder den Begriff MCPP, von dem ich noch nie gehört habe. Eine Web-Suche liefert im Wesentlichen drei Bedeutungen: Eine psychoaktive Substanz: https://en.wikipedia.org/wiki/Meta-Chlorophenylpiperazine Ein C/C++-Präprozessor: http://mcpp.sourceforge.net/ bzw. dessen Nachfolger: https://github.com/zeroc-ice/mcpp Managed C++, der Vorgänger von C++/CLI für .NET von Microsoft: https://www.it-visions.de/glossar/alle/600/Managed_C.aspx Falls du keine dieser drei Bedeutungen meinst (was ich fast vermute), welche dann? Und wo kann man mehr darüber lesen? Edit: Wilhelm M. schrieb: > Breymann; "Der C++Programmierer", neue Auflage! Gestern war ich in einem Buchladen, habe mir dieses Buch (aktuelle Auflage von 2016) angeschaut. Einen Stroustrup (2013) zum direkten Vergleich war leider nicht vorrätig. Da ich nicht mit leeren Händen nach Hause gehen wollte, habe ich mich kurzerhand für den Breymann entschieden. Nach den ersten ca. 100 Seiten bin ich mit dem Buch trotz des leicht unsystematischen Aufbaus und einiger kleiner Fehler ganz zufrieden. Wenn ich durch bin, werde ich evtl. einen kleinen Erfahrungsbericht schreiben.
:
Bearbeitet durch Moderator
Hallo Yalu, naja, wohl using MCPP = Modern CPP, also post-C++98. vlg Timm
Timm R. schrieb: > using MCPP = Modern CPP, also post-C++98. Ah, jetzt ja, vielen Dank fürs Augenöffen :) Da muss man erst einmal draufkommen. Aber du hast natürlich recht, so ergibt das einen Sinn. Trotzdem scheint die Abkürzung MCPP nicht sehr gebräuchlich zu sein. Auch dürfte der Begriff "Modern C++ Programming" einem ständigen Bedeutungswandel unterworfen sein. Heute ist MCPP = Post-C++98, in ein paar Jahren wird MCPP = Post-C++17 sein ;-)
Yalu X. schrieb: > Timm R. schrieb: >> using MCPP = Modern CPP, also post-C++98. > > Ah, jetzt ja, vielen Dank fürs Augenöffen :) Ja, so war es gedacht. > Da muss man erst einmal draufkommen. Aber du hast natürlich recht, so > ergibt das einen Sinn. Dachte, dass das "selbsterklärend" wäre. Man schreibt ja auch nicht immer Konstruktor oder Destruktor, sondern kürzt das oft mit ctor und dtor ab. Und das ist auch kein Akronym, was in Wikipedia steht ... > Trotzdem scheint die Abkürzung MCPP nicht sehr gebräuchlich zu sein. Wird aber mehr: das erste Mal habe ich das glaube im Vortrag von Scotty gesehen, weil sein letztes Buch ja auch "Effective MODERN C++" heißt. > Auch dürfte der Begriff "Modern C++ Programming" einem ständigen > Bedeutungswandel unterworfen sein. Selbstverständlich, weil er ja ein moving-target ist. > Heute ist MCPP = Post-C++98, in ein > paar Jahren wird MCPP = Post-C++17 sein ;-) Da wird er hoffentlich obsolet sein, denn im Moment befindet sich die überwiegende Mehrzahl der CPP-Programmierer in einer Situation, wo sie entweder selbst noch den Umstieg machen oder eben mit altem Code zu tun haben. Das Kommittee will ja auch, dass die Sprache sich bewegt durch den 3-jährigen Zyklus und durch die Arbeitsweise über die TS-Prozedur.
Hallo, Wilhelm M. schrieb: > https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines na, das kommt doch einem C++14 Lehrbuch durchaus recht nahe? Sehr cool finde ich den Abschnitt N: Non-Rules :-) Endlich mal! Eine Sache beschäftigt mich allerdings: eine ganze Reihe von Vorschlägen sowohl aus diesen Guidelines, als auch in anderen Quellen, zB fluentcpp würden IMHO nahelegen, dass es nett wäre benannte Parameter zu haben. Für Compiler / Präprozessor sollte das nur eine entspannte Fingerübung sein, dennoch scheinen benannte Parameter (also beim Aufruf mit Namen versehen) absolut niemanden besonders zu bewegen? vlg Timm
Benannte Funktionsparameter in der Sprache wären sicher eine praktische Sache und vermutlich kein Problem für den Compiler. Aber wie könnte das in C++ aussehen? Die Vorschläge, die ich bis jetzt gesehen habe, hatten entweder offensichtliche Problme, waren unleserlich oder viel zu kompliziert. Wenn du nen praktikable Lösung kennst würde mich das sehr interessieren.
Hallo, mh schrieb: > Benannte Funktionsparameter in der Sprache wären sicher eine praktische > Sache und vermutlich kein Problem für den Compiler. Aber wie könnte das > in C++ aussehen? Die Vorschläge, die ich bis jetzt gesehen habe, hatten > entweder offensichtliche Problme, waren unleserlich oder viel zu > kompliziert. > Wenn du nen praktikable Lösung kennst würde mich das sehr interessieren. vielleicht gibts da ein Missverständnis. Ich meinte als syntaktische Neuerung. Nicht als Lösung mit bestehenden Sprachmitteln. Die Lösungen mit bestehenden Sprachmitteln finde ich alle grauenhaft. Strong Types zähle ich mal nicht dazu, die finde ich schon sehr nett und auch logisch zusätzlich können ja auch noch sehr viel mehr, Überladungen auflösen zum Beispiel. Aber wenn man für jeden benannten Parameter einen starken Typen einführt ... Wahrscheinlich sind andere Dinge im Moment erstmal wichtiger ... vlg Timm
Kein Missverständnis, ich hab auch von einer Erweiterung der Sprache gesprochen. Wie kann C++ um benannte Funktionsparameter Erweitert werden?
Timm R. schrieb: > Hallo, > > Wilhelm M. schrieb: > >> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines > > na, das kommt doch einem C++14 Lehrbuch durchaus recht nahe? > > Sehr cool finde ich den Abschnitt N: Non-Rules :-) Endlich mal! > > > Eine Sache beschäftigt mich allerdings: eine ganze Reihe von Vorschlägen > sowohl aus diesen Guidelines, als auch in anderen Quellen, zB fluentcpp > würden IMHO nahelegen, dass es nett wäre benannte Parameter zu haben. > Für Compiler / Präprozessor sollte das nur eine entspannte Fingerübung > sein, dennoch scheinen benannte Parameter (also beim Aufruf mit Namen > versehen) absolut niemanden besonders zu bewegen? Dafür gibt es Vorschläge: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4172.htm Doch gibt es eben auch schon immer einige Alternativen und es sind auch noch einige dazu gekommen: 1) strong-types und parameter-permutation 2) named-parameter idiom In C++20 kommen dann designated-initializers hinzu. Auf dem Weg dahin kann man die durch IIFE ersetzen. Es gibt auch Möglichkeiten über Proxy-Templates zu gehen oder auch std::tuple einzusetzen. Aber das ist alles mit viel boilerplate verbunden. In meinen Augen sind 1) und 2) absolut ausreichend und designated-initializers wären eine tolle Ergänzung. Leider sehe ich in der Praxis immer noch sehr viel Code, der DIE wichtigste Schnittstellenregel nicht beachtet: Eine Schnittstelle sollte leicht richtig und schwer falsch zu benutzen sein! Und das erreicht man m.E. sehr gut mit 1) und / oder 2).
Hallo, ich hätte noch einen Lesetipp: Es gibt die Präsentation von Scott Meyers Overview of the New C++ (C++11) Die wird aktualisiert, in der neuesten verfügbaren ist C++14 eingearbeitet. Kostet leider $30 Hier kann man reinschauen: https://www.artima.com/samples/cpp11-14NotesSample.pdf So roundabout 400 Slides, vielleicht 300 slides netto, geht ziemlich zur Sache, mit recht wenig Erklärung. Aber für mich das perfekte Curriculum. Für mich eine absolute Empfehlung, weil einfach jedes Wort sitzt und es wirklich um das Delta C++98 / C++14 geht. Vlg Timm
mh schrieb: > Wie kann C++ um benannte Funktionsparameter Erweitert werden? Wurde wohl abgelehnt. https://gcc.gnu.org/ml/gcc/2015-03/msg00202.html > Note that a proposal for named arguments was recently presented to > the C++ standards committee [1], and they did not seem receptive > to it [2]. > > The proposal was for a different syntax (name : value), but the > objections were not related to the syntax.
:
Bearbeitet durch User
ui schrieb: > Warum nichtuint8_t *ptr > per default zu einem smart_ptr machen? Was spricht denn dagegen? Dass man mündigen Individuen diese Entscheidung auch selbst überlassen kann, die dann auch High-Level-C++ auf einem Micro-Controller mit 512 byte RAM hinbekommen. Denn Yalu X. schrieb: > durch die > Verwendung von High-Level-Features bedingten Performanceverluste gab und gibt es in C++ einfach nicht, wenn man die Sprache unter Kontrolle hat. Da kann man noch ganz genau das ausdrücken, was man haben will. Und wenn man mal in der Situation ist, eine C++-Library, die mit Compiler und stdlib A kompiliert wurde, mit Compiler und stdlib B benutzen zu wollen, weiß man auch, warum man in den Schnittstellen besser nur PODs verwendet!
zer0 schrieb: > Yalu X. schrieb: >> durch die >> Verwendung von High-Level-Features bedingten Performanceverluste > > gab und gibt es in C++ einfach nicht Nach Reflektion muss ich das nochmal einschränken. Die Compile-Time hat mitunter gewaltig gelitten...
opravo schrieb: > C++ aktualisieren ohne Abwärtskompatibilität? Ist doch Gang und Gebe. Schon seit C++-11 funktionieren keine Container mehr, die structs mit mindestens einem const-member enthalten. Mit Copy-Construct ging das noch. Mit move nicht mehr.
zer0 schrieb: > opravo schrieb: >> C++ aktualisieren ohne Abwärtskompatibilität? > > Ist doch Gang und Gebe. Schon seit C++-11 funktionieren keine Container > mehr, die structs mit mindestens einem const-member enthalten. Mit > Copy-Construct ging das noch. Mit move nicht mehr. Kannst du ein minimales Beispiel geben, dass mit c++98 compiliert aber nicht mit c++11?
mh schrieb: > zer0 schrieb: > opravo schrieb: > C++ aktualisieren ohne Abwärtskompatibilität? > > Ist doch Gang und Gebe. Schon seit C++-11 funktionieren keine Container > mehr, die structs mit mindestens einem const-member enthalten. Mit > Copy-Construct ging das noch. Mit move nicht mehr. > > Kannst du ein minimales Beispiel geben, dass mit c++98 compiliert aber > nicht mit c++11?
1 | struct C { |
2 | const int s; |
3 | };
|
4 | vector<C> v; |
5 | ...
|
6 | v.push_back(...); |
Will moven. Oder war's ein v.remove(...)? Sorry müsste den Source erst suchen. Aber jedenfalls gab es da ja noch dollere Dinger. Siehe Exceptions in C++03. Kann man wohl nur froh sein, das nicht mitgemacht zu haben. Das wäre ein sinnvolles Betätigungsfeld: Eine noexcept-Variante der Stdlib. Obwohl man, wenn man die cycles zählt vermutlich sowieso seine eigenen Container mit weniger Speicheroverhead nutzt. Was sagt modernes C++ denn so? Gibt's mittlerweile iconv integriert?
zer0 schrieb: > Sorry müsste den Source erst > suchen. Mach mal. Das würde mich auch interessieren... Und welcher Compiler wars denn? Oliver
zer0 schrieb: > mh schrieb: >> zer0 schrieb: >> opravo schrieb: >> C++ aktualisieren ohne Abwärtskompatibilität? >> >> Ist doch Gang und Gebe. Schon seit C++-11 funktionieren keine Container >> mehr, die structs mit mindestens einem const-member enthalten. Mit >> Copy-Construct ging das noch. Mit move nicht mehr. >> >> Kannst du ein minimales Beispiel geben, dass mit c++98 compiliert aber >> nicht mit c++11? > struct C { > const int s; > }; > vector<C> v; > ... > v.push_back(...); > Will moven. Oder war's ein v.remove(...)? Sorry müsste den Source erst > suchen. Bis c++11 galt für std::vector<T>, dass T copy constructible and assignable sein muss. > Aber jedenfalls gab es da ja noch dollere Dinger. Siehe Exceptions in > C++03. Kann man wohl nur froh sein, das nicht mitgemacht zu haben. Das > wäre ein sinnvolles Betätigungsfeld: Eine noexcept-Variante der Stdlib. > Obwohl man, wenn man die cycles zählt vermutlich sowieso seine eigenen > Container mit weniger Speicheroverhead nutzt. Ich kann dir nicht wirklich folgen. Was ist/war das Problem? > Was sagt modernes C++ denn so? Gibt's mittlerweile iconv integriert? Mit iconv meinst du: https://en.wikipedia.org/wiki/Iconv ? Warum braucht möchte man das integriert in die Sprache?
Hallo, ich bin ein bisschen verwirrt, ich hatte gedacht, dass Du die Tatsache, dass so ein Sch*** nicht geht als Feature verstanden hast: zer0 schrieb: >
1 | > struct C { |
2 | > const int s; |
3 | > }; |
4 | > vector<C> v; |
5 | > ... |
6 | > v.push_back(...); |
7 | >
|
aber bist Du ganz sicher, dass das jemals funktioniert hat? Also bei mir jedenfalls hat das nie funktioniert, da bin ich ziemlich sicher. Mein aktueller gcc98 liefert dazu, oder besser gesagt zum MCE:
1 | #include <iostream> |
2 | #include <vector> |
3 | #include <algorithm> |
4 | |
5 | struct Foo { |
6 | const int id_; |
7 | public:
|
8 | Foo() |
9 | : id_(42) { |
10 | }
|
11 | };
|
12 | |
13 | std::vector<Foo> foo_vector; |
14 | |
15 | int main(int argc, const char * argv[]) { |
16 | std::swap(*foo_vector.begin(), *(foo_vector.begin() + 1)); |
17 | return 0; |
18 | }
|
Cannot define the implicit copy assignment operator for 'Foo', because non-static const member 'id_' cannot use copy assignment operator. Womit gcc98 ja auch absolut recht hat. Clang C++11 und C++14 liefern No matching function for call to 'swap' Womit sie ja auch absolut recht haben. Irgendwo verstehe ich garnicht, worum es da gehen soll, was für einen Sinn sollte ein non-static const member haben, den man in einen Vector kopieren will? Das ist doch einfach Nonsens und war schon immer Nonsens und sonst muss man die Klasse halt entsprechend ausstatten, dass es geht, warum auch immer man das wollen können sollte. Oder halt einen Pointer verwenden. Vlg Timm
:
Bearbeitet durch User
Timm R. schrieb: > Hallo, > > ich bin ein bisschen verwirrt, ich hatte gedacht, dass Du die Tatsache, > dass so ein Sch*** nicht geht als Feature verstanden hast: > > zer0 schrieb: > >>> struct C { >> const int s; >> }; >> vector<C> v; >> ... >> v.push_back(...); >> > aber bist Du ganz sicher, dass das jemals funktioniert hat? Also bei mir > jedenfalls hat das nie funktioniert, da bin ich ziemlich sicher. Mein > aktueller gcc98 liefert dazu, oder besser gesagt zum MCE:#include > <iostream> > #include <vector> > #include <algorithm> > > struct Foo { > const int id_; > public: > Foo() > : id_(42) { > } > }; > > std::vector<Foo> foo_vector; > > int main(int argc, const char * argv[]) { > std::swap(*foo_vector.begin(), *(foo_vector.begin() + 1)); > return 0; > } > > Cannot define the implicit copy assignment operator for 'Foo', because > non-static const member 'id_' cannot use copy assignment operator. > > Womit gcc98 ja auch absolut recht hat. > > Clang C++11 und C++14 liefern > No matching function for call to 'swap' > Womit sie ja auch absolut recht haben. > > Irgendwo verstehe ich garnicht, worum es da gehen soll, was für einen > Sinn sollte ein non-static const member haben, den man in einen Vector > kopieren will? Das ist doch einfach Nonsens und war schon immer Nonsens > und sonst muss man die Klasse halt entsprechend ausstatten, dass es > geht, warum auch immer man das wollen können sollte. > > Oder halt einen Pointer verwenden. > > Vlg > Timm Hmm, ich glaub' da müsstest du schon eine ältere VC-Variante oder einen "ebenbürtigen" gcc zücken. CopyAssignable usw. sind die Konzepte aus dem C++11-Standard. Ein "guter, alter" stl-container muss nirgendwo unbedingt eine Zuweisung a=b machen und tut es deswegen auch nicht. Oder wo brauchte man explizit a=b, ohne dass construct(&a,b) ginge? Das ist doch move-only! -- Ziel der Übung ist selbstverständlich das Key-Element einer struct konstant zu halten und die Dinger in einem vector zu speichern quasi als (im konkreten Fall) besseres std::set. Lustig finde ich übrigens das hier: CopyAssignable: "Given t, a modifiable lvalue expression of type T ... t = rv ... (is a valid expression)". => "Given t, a modifiable lvalue expression of type 'const int' ... t = rv ... is a valid expression". Schiene mir ja zuzutreffen... Jetzt muss ich erstmal überlegen, was die wohl mit "modifiable" meinen :)
mh schrieb: > Bis c++11 galt für std::vector<T>, dass T copy constructible and > assignable sein muss. Echt?! Wozu das denn? Eine zwingende Notwendigkeit gibt es doch erst mit den move-Semantics oder meinst du jetzt auf dem Papier? mh schrieb: > Ich kann dir nicht wirklich folgen. Was ist/war das Problem? Dass da offensichtlich gerne mal im großen Maßstab hin- und dann wieder zurück gerudert wird, was mich ja ggf. gewaltig ärgern würde: mh schrieb: > Mit iconv meinst du: https://en.wikipedia.org/wiki/Iconv ? Warum braucht > möchte man das integriert in die Sprache? War doch ein naheliegender Gedanke, oder nicht? Könnte man doch als Vorschlag zum Ersatz von codecvt* einreichen.
zer0 schrieb: > Hmm, ich glaub' da müsstest du schon eine ältere VC-Variante oder einen > "ebenbürtigen" gcc zücken. Nee, der C++98 Standard genügt völlig: 23.1.3: The type of objects stored in these components must meet the requirements of CopyConstructible types (20.1.3), and the additional requirements of Assignable types. Fertig. Dein Beispiel erfüllt diese Anforderung nicht. Das wars. Nichts mit bösen C++11 Erfindungen. > CopyAssignable usw. sind die Konzepte aus dem > C++11-Standard. Nö, ist bei 2003 auch schon drin. > Ein "guter, alter" stl-container muss nirgendwo > unbedingt eine Zuweisung a=b machen und tut es deswegen auch nicht. Oder > wo brauchte man explizit a=b, ohne dass construct(&a,b) ginge Jetzt im Ernst? Eine Zuweisung auf ein bestehendes Objekt, eine der wesentlichen Operationen, mit dtor/ctor? Genial. Viele liebe Grüße Timm
Mod schrieb: > , die sollten lieber mal veraltete Dinge über Bord werfen Damit sich alte Programm(teil)e nicht mehr kompilieren lassen. Wie dumm ist das denn. (ich habe z.B. letzte Woche mal wieder schnellen getesteten Datenbankcode von 1997 in mein Projekt übernommen weil in den letzten 20 Jahren von der open source Community nichts brauchbareres geschaffen wurde, der war noch so alt, dass ein Define ihn K&R kompatibel machte) Nicht ohne Grund laufen auch heute noch viele COBOL Programme, weil das einen Wert darstellt, Abermilliarden stecken in altem Code. Schlimm genug, dass manche C++ Programme manche Konstrukte die sie ehemals übersetzen konnten (und sich meist für eine Interpretation des Standards entschieden) heute mit Fehler abweisen.
Timm R. schrieb: > Fertig. Dein Beispiel erfüllt diese Anforderung nicht. Das wars. Nichts > mit bösen C++11 Erfindungen. Und wie sollte der Compiler das ohne concepts merken können? Jedenfalls nicht anhand der Operationen, die wirklich ausgeführt wurden! Timm R. schrieb: > Jetzt im Ernst? Eine Zuweisung auf ein bestehendes Objekt, eine der > wesentlichen Operationen, mit dtor/ctor? Genial. Wieso denn "bestehendes Objekt"? Ich kann dir nicht folgen...
Beitrag #5137754 wurde von einem Moderator gelöscht.
Beitrag #5137790 wurde von einem Moderator gelöscht.
Beitrag #5137840 wurde von einem Moderator gelöscht.
Beitrag #5137844 wurde von einem Moderator gelöscht.
Beitrag #5137913 wurde von einem Moderator gelöscht.
Beitrag #5138086 wurde von einem Moderator gelöscht.
Beitrag #5139170 wurde von einem Moderator gelöscht.
Beitrag #5140107 wurde von einem Moderator gelöscht.
Beitrag #5140391 wurde von einem Moderator gelöscht.
Beitrag #5140395 wurde von einem Moderator gelöscht.
Beitrag #5140415 wurde von einem Moderator gelöscht.
Beitrag #5140438 wurde von einem Moderator gelöscht.
Beitrag #5140443 wurde von einem Moderator gelöscht.
Beitrag #5142604 wurde von einem Moderator gelöscht.
Beitrag #5143779 wurde von einem Moderator gelöscht.
Beitrag #5143786 wurde von einem Moderator gelöscht.
Beitrag #5144971 wurde von einem Moderator gelöscht.
Beitrag #5144972 wurde von einem Moderator gelöscht.
Beitrag #5144986 wurde von einem Moderator gelöscht.
Beitrag #5145006 wurde von einem Moderator gelöscht.
Beitrag #5145185 wurde von einem Moderator gelöscht.
Beitrag #5145219 wurde von einem Moderator gelöscht.
Beitrag #5145226 wurde von einem Moderator gelöscht.
Beitrag #5145796 wurde von einem Moderator gelöscht.
Beitrag #5145823 wurde von einem Moderator gelöscht.
Beitrag #5145933 wurde von einem Moderator gelöscht.
Beitrag #5145958 wurde von einem Moderator gelöscht.
Beitrag #5145980 wurde von einem Moderator gelöscht.
Beitrag #5146033 wurde von einem Moderator gelöscht.
Beitrag #5148053 wurde von einem Moderator gelöscht.
Beitrag #5148067 wurde von einem Moderator gelöscht.
Beitrag #5149250 wurde von einem Moderator gelöscht.
Beitrag #5149288 wurde von einem Moderator gelöscht.
Beitrag #5149353 wurde von einem Moderator gelöscht.
Beitrag #5149372 wurde von einem Moderator gelöscht.
Beitrag #5149389 wurde von einem Moderator gelöscht.
Beitrag #5149391 wurde von einem Moderator gelöscht.
Beitrag #5149392 wurde von einem Moderator gelöscht.
Beitrag #5149413 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.