Move-Semantik std::vector
-
Ich tippe mal darauf, dass die Container std::move_if_noexcept verwenden.
-
Sone schrieb:
VS ist nicht nur C++ compiler
Ja, VS! Nicht VC++! VS kompensiert das ganze mehr als genug mit einer super IDE.
Bitte lerne doch erst einmal, was Visual C++ überhaupt ist, bevor du dagegen stänkerst.
-
Ihr scheint ein anderes Visual C++ zu haben als ich. Der Editor und Intellinonsense sind furchtbar. Der Debugger ist furchtbar. Die Einstellungsdialoge sind furchtbar. Die Performance ist furchtbar. Die Optik ist seit 2012 furchtbar. Die Fehlermeldungen des Compilers sind furchtbar. Die Anzeige dieser Fehlermeldungen in der IDE ist furchtbar. Die Unterstützung von C++ ist furchtbar, auch in 2013 noch. Die Unterstützung von C ist furchtbar.
Also unterm Strich eine "super IDE".
-
TyRoXx schrieb:
furchtbar furchtbar furchtbar
mimimi
VS ist immer noch die beste IDE für C++, besonders mit VAX. Klar, der neue Look ist nicht so toll, aber den kann man ja ändern. Wo ansonsten hast du so gute semantische Codeanalyse, Debugger oder Profiler? Arbeite mal mit Code::Blocks, dann lernst du die Bedeutung von "furchtbar" wirklich kennen
-
mi schrieb:
VS ist immer noch die beste IDE für C++, besonders mit VAX.
Das wichtigste Feature, den C++ Editor, muss man von einer anderen Firma dazu kaufen. Das bestätigt natürlich die enorme Qualität von Visual C++ an sich.
-
TyRoXx schrieb:
Das wichtigste Feature, den C++ Editor, muss man von einer anderen Firma dazu kaufen. Das bestätigt natürlich die enorme Qualität von Visual C++ an sich.
Ich brauche den Editor von VS schon seit Jahren und bin absolut zufrieden damit. Und damit bin ich ganz sicher nicht der einzige. Linux-Fanboys bleiben vielleicht besser bei ihrem Emacs und Vim. Man kann zwar damit alle möglichen Textverarbeitungsoperationen durchführen, aber etwas tatsächlich Nützliches wie Autovervollständigung oder semantische Analyse in Echtzeit muss man sich, wenn überhaupt, durch separate Tools einbauen. Von grafischem Debugger will ich gar nicht anfangen.
Was Leute immer vergessen, ist dass das tatsächliche Code-Schreiben nur einen Teil der Entwicklungszeit ausmacht. Dinge wie Dokumentation lesen und schreiben, Debuggen, Profilen oder Testen gehört auch dazu. Und hier unterstützt VS zumindest mich gewaltig. Aber als Boilerplatecoder braucht man diese Tools vielleicht nicht...
-
TyRoXx schrieb:
Der Editor und Intellinonsense sind furchtbar.
Der Editor ist sicher nicht der beste, aber sicher auch nicht der schlechteste...
TyRoXx schrieb:
Der Debugger ist furchtbar.
Zeig mir einen besseren C++ Debugger.
TyRoXx schrieb:
Die Performance ist furchtbar.
aha
TyRoXx schrieb:
Die Optik ist seit 2012 furchtbar.
subjektiv
TyRoXx schrieb:
Die Fehlermeldungen des Compilers sind furchtbar.
Der einzige mir bekannte Compiler, der wirklich bessere Fehlermeldungen liefert, ist clang...
TyRoXx schrieb:
Die Anzeige dieser Fehlermeldungen in der IDE ist furchtbar.
inwiefern?
TyRoXx schrieb:
Die Unterstützung von C++ ist furchtbar, auch in 2013 noch.
Gibt echt schlimmeres.
TyRoXx schrieb:
Die Unterstützung von C ist furchtbar.
Nenn mir bitte einen vernünftigen Grund, C99 zu benutzen statt C++, generell, insbesondere auf dem PC und insbesondere unter Windows...
-
Also bei mir Arbeit mit Eclipse (und dem GCC) kennt der nichtmals assert im Editor, das wird immer rot angestrichen und autovervollständigt wirds auch nicht. (Obwohl es legitimer C++ Code ist, der auch vom Compiler geschluckt wird).
Und wenn die Performance bei dir schlecht ist, dann solltest du vielleicht mal über einen neuen Rechner nachdenken. Auf meinem Quadcore mit mehr als 4 GB Ram läuft das super. (Wobei wenn ich die Klassenansicht expandiert habe und schreibe, dann arbeitet der schon sehr hart und ist langsam. Aber sobald die zu ist, alles n1)
Ok, die Intellisense und die Autovervollständigung hakt manchmal. Mit einer kompletten templatebasierten Library und überall auto und decltype Keywords. Alles andere geht super (und wenn nicht, wartet man ne Sekunde bis der alles geprüft hat, dann gehts).
Und die C++11 unterstützung muss man wenigstens nicht mit Special-Parametern wie -pthread nach zum laufen überreden.
-
Sone schrieb:
Nun habe ich gelesen, dass man den move-Konstruktor explizit als noexcept angeben muss, damit vector Move-Semantik benutzen darf.
Nein, das ist falsch:
So falsch ist das nicht.
Sone schrieb:
Weder MoveAssignable noch MoveConstructible (die Konzepte die
vectorbspw. voraussetzt) fordernnoexcept.Das stimmt, tut hier aber nichts zur Sache.
Kellerautomat schrieb:
Ich tippe mal darauf, dass die Container std::move_if_noexcept verwenden.
Richtig, std::vector<> verwendet std::move_if_noexcept statt std::move an einigen Stellen. Das tut es, damit z.B. vector<>::resize in den Fällen, wo es möglich ist, die "strong exception guarantee" geben kann. Wenn also T einen Movekonstruktor hat, der nicht noexcept ist, T dafür aber auch kopierbar ist, dann wird beim Vergrößern des Vektors doch kopiert; denn sonst könnten Daten verloren gehen, wenn ein Move-Konstruktor dabei eine Ausnahme schmeißt. Ist T nicht kopierbar, geht es ja nicht anders. Dann hat man bei resize aber auch keine starke Ausnahmesicherheit mehr.
-
krümelkacker schrieb:
Sone schrieb:
Nun habe ich gelesen, dass man den move-Konstruktor explizit als noexcept angeben muss, damit vector Move-Semantik benutzen darf.
Nein, das ist falsch:
So falsch ist das nicht.
Doch, denn es ging - wie du vielleicht bemerkt haben könntest - darum, ob des kompiliert. Nicht darum, ob es moved oder nicht.
