Hallo zusammen, ich habe ein kleines Testprogramm geschrieben und bekomme Warnmeldungen mit denen ich nicht viel anfangen kann. Was bedeuten diese Meldungen und wie kann ich den Code korrigieren um die Meldungen wegzubekommen?
Angehängte Dateien:
Super, hast mir sehr geholfen, ich muss Variablen und Konstanten im Konstruktor initialisieren, eigentlich logisch dafür gibts den ja.
Dein Kommentar passt schon mal nicht zum Code. Wenn das Konstanten sein sollen, wieso sind sie dann nicht als solche deklariert? Im Übrigen empfiehlt es sich Code als Text zu posten und nicht als Screenshot.
Mark B. schrieb: > Dein Kommentar passt schon mal nicht zum Code. Wenn das Konstanten sein > sollen, wieso sind sie dann nicht als solche deklariert? Danke für den Hinweis, das habe ich bereits korrigiert.
Warum benutzt du nicht einfach C++11, wie die Warnmeldung vorschlägt? Oder auch gleich C++14, falls der verwendete Compiler das unterstützt. Schließlich leben wir nicht mehr in den 90ern.
PS: Deine restlichen Variablen kannst du dann auch gleich an Ort und Stelle initialisieren und den Konstruktor komplett löschen.
Schon C++98 erlaubte innerhalb einer Klassendeklaration die Initialisierung von ganzzahligen Klassenkonstanten, also bspw. so:
1 | static const char comma = '.'; |
Eine solche Variable ist überall dort zur Compile-Zeit bekannt, wo auch die Klassendeklaration bekannt ist, was folgende Vorteile bringt: - Sie belegt keinen (Daten-)Speicherplatz. - Sie erzeugt keinen Rechenzeit-Overhead bei der Objektinstanziierung. - Zugriffe auf die Variable erfolgen i.Allg. schneller, da der Wert direkt als Operand der entsprechenden Maschineninstruktionen angegeben werden kann und nicht erst aus dem Datenspeicher gelesen werden muss. - Da der Compiler ihren Wert kennt, kann er Ausdrücke, in der sie auftaucht, stärker optimieren. - Sie zählt als eine so genannte "integral constant expression" und kann deswegen bspw. als Größenangabe in einer Array-Deklaration verwendet werden. Dies ist auch der Grund, warum diese direkte Initialisierungs- möglichkeit überhaupt eingeführt wurde. Andere Datentypen (wie bspw. double) können mit dieser Methode nicht initialisiert werden¹. Seit C++11 ist dies (und noch sehr viel mehr) mit constexpr möglich:
1 | static constexpr double x = 1.234; |
Man könnte deswegen die obige Codezeile also auch so schreiben:
1 | static constexpr char comma = '.'; |
——————————— ¹) Der GCC bietet dies allerdings als Spracherweiterung an.
up2date schrieb: > Warum benutzt du nicht einfach C++11, wie die Warnmeldung vorschlägt? > Oder auch gleich C++14, falls der verwendete Compiler das unterstützt. > Schließlich leben wir nicht mehr in den 90ern. Weil ich ein Buch durcharbeite welches auf C++98 basiert, ich es nicht professionell einsetzen muss und es ne Menge kostet ein aktuelles zu kaufen. Wenn ich das Buch durch habe, dann kann ich mir ein aktuelles "A Tour of C++" kaufen und bin wieder up to date, bitte korrigiert mich wenn ich falsch liege.
wulga schrieb: > Wenn ich das Buch durch habe, dann kann ich mir ein aktuelles "A > Tour of C++" kaufen und bin wieder up to date, bitte korrigiert mich > wenn ich falsch liege. So machst du dir halt eine Menge Extra Arbeit, weil du dann einiges an Wissen aus C++98 wieder vergessen (inkl. diverser Workarounds die heute nicht mehr nötig sind) und neue Dinge dazulernen musst. Einfacher wäre es direkt mit C++14 anzufangen.
wulga schrieb: > up2date schrieb: >> Warum benutzt du nicht einfach C++11, wie die Warnmeldung vorschlägt? > Weil ich ein Buch durcharbeite welches auf C++98 basiert Und warum werden dann in diesem Buch C++11-Features verwendet? Oder wie kommst du sonst auf die Idee, C++11-Code zu schreiben? Du solltest vielleicht mal hinterfragen, ob deine Vorgehensweise in der Form zielführend ist.
wulga schrieb: > up2date schrieb: >> Warum benutzt du nicht einfach C++11, wie die Warnmeldung vorschlägt? >> Oder auch gleich C++14, falls der verwendete Compiler das unterstützt. >> Schließlich leben wir nicht mehr in den 90ern. > > Weil ich ein Buch durcharbeite welches auf C++98 basiert, ich es nicht > professionell einsetzen muss und es ne Menge kostet ein aktuelles zu > kaufen. Wenn ich das Buch durch habe, dann kann ich mir ein aktuelles "A > Tour of C++" kaufen und bin wieder up to date, bitte korrigiert mich > wenn ich falsch liege. Ich denke, dass das das falsche Vorgehen ist: besser gleich mit C++14/C++17 anfangen. Dazu gibt es auch Online-Quellen.
Ich finde nichts Schlimmes an der Vorgehensweise des TE: C++ ist eine sehr umfangreiche Programmiersprache und ist mit den Neuerungen in C++11 noch ein ganzes Stück umfangreicher geworden. Der TE muss sich für eine der beiden folgenden Alternativen entscheiden: 1. Er kann sich ein C++14-Buch kaufen, das etwa 30% bis 50% dicker als sein jetziges ist, und damit sämtliche aktuellen C++-Features erlernen. 2. Er kann sein C++98-Buch erst einmal zu Ende durcharbeiten und sich dann im Web über die Neuerungen von C++11/14 informieren. Vom Lernumfang her unterscheiden sich die beiden Alternativen nicht arg, da C++98 vollständig in C++14 enthalten ist. Es gibt – im Gegensatz zum Übergang von K&R-C zu ANSI-C – in C++98 auch sehr wenig bis gar nichts, was durch die Einführung von C++11/14 obsolet wurde. Den Hauptvorteil von (1) sehe ich darin, das der komplette aktuelle Sprachumfang in einem einzigen Buch vereint ist, weswegen unter Berücksichtigung der neuen Sprachfeatures leichter etwas nachgeschlagen werden kann. Alternative (2) hat den Vorteil, dass eine deutliche Trennung zwischen der alten und der neuen Norm besteht. Der Sinn der neuen Sprachfeatures ist teilweise wesentlich leichter erfassbar, wenn man auch den Weg kennt, wie ein bestimmtes Problem mit C++98 gelöst wurde. Zudem hilft die Trennung, bestehenden C++-Code von anderen Entwicklern besser zu verstehen. Ohne die Kenntnis der Historie wundert man sich ständig über den scheinbar umständlichen Programmierstil in älterem Programmcode. Noch ein Aspekt: Bis der TE nach (1) das komplette Buch durchgearbeitet und verstanden hat, wird ohnehin die nächste Version der Norm (C++17) verabschiedet worden sein, so dass er wieder vor derselben Frage steht wie heute. Soll er beim Erscheinen der ersten C++17-Bücher sein noch nicht zu Ende gelesenes C++14-Buch wegschmeißen und im neuen Buch wieder von Seite 1 anfangen? Sicher nicht. Bei solch schnelllebigen Dingen wie der Softwareentwicklung ist inkrementelles Lernen angesagt, und es hilft wenig, ständig nach dem neuesten Stand der Technik schnappen zu wollen, solange man den alten noch nicht vollständig verdaut hat. Da der TE in seinem C++98-Buch offensichtlich schon recht weit vorangeschritten ist, würde ich seiner Stelle den eingeschlagenen Weg erst einmal weiterverfolgen. Evtl. lohnt es sich aber, vorab schon einmal diese Liste von C++11-Features durchzugehen, um zu sehen, welche davon vielleicht schon zum jetzigen Zeitpunkt von Interesse sein könnten: https://en.wikipedia.org/wiki/C%2B%2B11
Yalu X. schrieb: > Ich finde nichts Schlimmes an der Vorgehensweise des TE: Nein, schlimm ist da nichts dran ;-) Ich denke nur, dass er schneller zu besserem (modernem) Code kommen würde, wenn er sich mit den Altlasten (gerade C++98) nicht belasten würde. Läuft einem alter Code über den Weg, so kann man sich immer noch fragen, warum das so ist wie es da ist (und ggf. nach der Pfadfinder-Regel in einem besseren Zustand wieder einchecken).
Wilhelm M. schrieb: > Ich denke nur, dass er schneller zu besserem (modernem) Code kommen > würde, wenn er sich mit den Altlasten (gerade C++98) nicht belasten > würde. An welche Altlasten denkst du da bspw.? Mir fallen kaum Sprachfeatures von C++98 ein, die nicht auch in modernem Code Anwendung finden. Was den besseren und modernen Code betrifft: Dafür gibt es ja noch die hervorragenden Bücher von Scott Meyers, die weit über das hinausgehen, was in den einschlägigen C++ Lehrbüchern vermittelt wird. Sie stellen aber keinen Ersatz für ein Lehrbuch dar und sind eher für den schon etwas trittsichereren C++-Programmierer gedacht. Schade, dass es aus seiner Feder wahrscheinlich kein "[More] Effective [Modern] C++" mit C++17 geben wird.
Yalu X. schrieb: > Wilhelm M. schrieb: >> Ich denke nur, dass er schneller zu besserem (modernem) Code kommen >> würde, wenn er sich mit den Altlasten (gerade C++98) nicht belasten >> würde. > > An welche Altlasten denkst du da bspw.? Mir fallen kaum Sprachfeatures > von C++98 ein, die nicht auch in modernem Code Anwendung finden. Alle C++ Versionen sind/werden abwärtskompatibel sein. Insofern stellt sich diese Frage nicht. Andersherum wird ein Schuh draus: ich möchte heute nicht mehr auf z.B. - range-based loops - auto type-inference und decltype - smart-pointer std::unique_ptr<> und std::shared_ptr<> - move-semantics - move-enabled container in der std-lib - lambda-expressions - viele goodies in der stdlib (e.g. std::optional<>) verzichten (wenn ich länger drüber nachdenke, fällt mir bestimmt auch für den Beginner noch mehr ein). Für den versierten Entwickler kommen noch viele andere Sachen für bspw. die generische Programmierung dazu.
Wilhelm M. schrieb: > Andersherum wird ein Schuh draus: ich möchte heute nicht mehr auf z.B. > > - range-based loops > - auto type-inference und decltype > - smart-pointer std::unique_ptr<> und std::shared_ptr<> > - move-semantics > - move-enabled container in der std-lib > - lambda-expressions > - viele goodies in der stdlib (e.g. std::optional<>) > > verzichten Ich auch nicht, da sind wir völlig einer Meinung. Aber welche dieser Features (mal von den range-based Loops abgesehen) sind für den TE in seinem aktuellen Lernstadium so wichtig und gleichzeitig verständlich, dass er sie schon jetzt beherrschen sollte? Da gibt es noch hundert andere Dinge, die IMHO höhere Priorität haben und die auch schon in seinem C++98-Buch behandelt werden.
Yalu X. schrieb: > 2. Er kann sein C++98-Buch erst einmal zu Ende durcharbeiten und sich > dann im Web über die Neuerungen von C++11/14 informieren. naja, gerade bei der Deklaration und Initialisierung von Klassenvariablen ermöglicht C++14 aber sehr viel hübscheren Code zu schreiben, weil man sich nicht selten Konstruktoren sparen kann, bzw deren Umfang deutlich reduzieren und duplizierten Code durch die in jedem Konstruktor doppelten Initialisierungen sparen kann
Yalu X. schrieb: > Wilhelm M. schrieb: >> Andersherum wird ein Schuh draus: ich möchte heute nicht mehr auf z.B. >> >> - range-based loops >> - auto type-inference und decltype >> - smart-pointer std::unique_ptr<> und std::shared_ptr<> >> - move-semantics >> - move-enabled container in der std-lib >> - lambda-expressions >> - viele goodies in der stdlib (e.g. std::optional<>) >> >> verzichten > > Ich auch nicht, da sind wir völlig einer Meinung. Aber welche dieser > Features (mal von den range-based Loops abgesehen) sind für den TE in > seinem aktuellen Lernstadium so wichtig und gleichzeitig verständlich, > dass er sie schon jetzt beherrschen sollte? Da gibt es noch hundert > andere Dinge, die IMHO höhere Priorität haben und die auch schon in > seinem C++98-Buch behandelt werden. Nun, man kann sicher bei bits und bytes anfangen, eine Sprache zu lernen - einige werden sagen, man muss erst asm, dann C und .... dann könnte man mit C++ anfangen. Dieser auch durch D. Knuth mit MMIX geprägte Ansatz ist heute m.E. nicht mehr zielführend, weil oft auch einfache, schnelle Erfolgserlebnisse ausbleiben und viele Dinge zu kompliziert erscheinen. Deswegen sollte / kann man ruhig etwas mehr high-level anfangen, und dazu gehören m.E. die genannten Punkte. Zudem sind das vielfach Dinge, die Umsteiger eben schon aus anderen Sprachen kennen. - range-based loops * viel weniger Fehlermöglichkeiten (z.B. kein off-by-one) * Schulung des Denkens in Algorithmen statt in expl. Loops * warum einen Index verwenden, wenn keine gebraucht wird * zusätzlich würde ich noch rohe C-Arrays verbannen zugunsten von std::array - auto type-inference und decltype * geschachtelte template-typen sind auch heute noch Monster (z.B. Iteratoren), das kann man einem Umsteiger von einer anderen Sprache kaum vermitteln. - smart-pointer std::unique_ptr<> und std::shared_ptr<> * kein expl. new/delete mehr notwendig, was für den Einsteiger ein Riesenvorteil ist * Denken in Eigentümerschaften (ownership) statt in low-level details - move-semantics * weil es zu einer ganz zentralen Eigenschaft geworden ist (s.a. unique_ptr) und meine Erfahrung zeigt, dass es auch Anfängern leicht zu erklären ist. Genauso wie die Operationenhierarchie Vertauschen/Verschieben/Kopieren - move-enabled container in der std-lib * weil auch Anfänger (leider) sich schnell um Perfomance sorgen machen, obwohl sie es nicht müssen - lambda-expressions * viele C++-Neulinge kommen heute aus eine Skriptsprachen-Welt oder anderen Sprachen wie Java, wo es das gibt. Und Funktoren sind m.E. umständlicher zu erklären. * weil die Algorithmen der stdlib ganz wichtig sind (s.a. oben: möglichst wenige explizite loops odgl.) - viele goodies in der stdlib (e.g. std::optional<>) * z.B., es gibt immer noch Anfänger, die meinen, 9999 wäre ein ungültiger int-Wert ;-) Vergessen habe ich noch in-class-initializer, auf die man keinesfalls am Anfang verzichten sollte. Das ist für den Newcomer einfach natürlicher. Und uniform-initialization-syntax, damit die einengenden Typwandlungen Geschichte sind. Ein großes Problem mit Lehrbüchern ist leider, dass sie eigentlich immer fortgeschrieben werden, statt sie radikal zu ändern, denn das mach sehr viel Aufwand und ist für die Autoren völlig unlukrativ. Aber bei einer solch radikalen Spracherweiterung wie mit C++11/14 und dann C++17 wäre das eigentlich notwendig. Ja, leider hat Scotty sich verabschiedet. Aber vielleicht pringt Jason Turner irgendwann in die Bresche ...
Vielen Dank für eure Meinungen zu C++11/14. Ich werde vorerst mit meinem C++98 Buch weiterarbeiten, es wurde ja dafür sprechend erwähnt, dass C++98 vollständig in C++11/14 enthalten ist (bitte korrigiert mich wenn ich es falsch wiedergebe). Natürlich habe ich auch Interesse daran mich weiterzuentwickeln, parallel zu meinem C++98 Buch habe ich die Möglichkeit mich mit den C++11 Features zu beschäftigen, danke an dieser Stelle für den wiki-Artikel. Außerdem gibts ja auch noch das C++11-Tutorial auf www.cplusplus.com.
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.