Verbreitung von C++11/C++14

Columbo

hustbaer schrieb:

Da mir seit Jahren nicht die Zeit gegeben wird unsere Projekte auf eine neuere Visual Studio Version zu bringen hänge ich z.B. noch auf Visual Studio 2005 fest.

Du armer. Hoffentlich befördern sie dich bald, das kann ja so wohl nicht weitergehen!

hustbaer

[OT]
Ich will eigentlich gar nicht befördert werden, Projektmanagement ist nicht so meins. Speziell nicht in meiner Firma (Chefetage ist etwas ... eigen. Damit muss man umgehen können. Kann ich nicht *g*).
Ich will bloss ordentlich arbeiten "dürfen".
Und etwas mehr $$$ wäre natürlich nicht verkehrt.
[/OT]

Columbo

hustbaer schrieb:

[OT]
Ich will bloss ordentlich arbeiten "dürfen".
Und etwas mehr $$$ wäre natürlich nicht verkehrt.
[/OT]

[OT]Aber Job wechseln ist nix? Noch auszuhalten?[/OT]

Mr X

Da mir seit Jahren nicht die Zeit gegeben wird unsere Projekte auf eine neuere Visual Studio Version zu bringen hänge ich z.B. noch auf Visual Studio 2005 fest.

Naja, das ist bei weitem nicht so gruselig, wie die Erkenntnis, dass VC6 noch im Einsatz ist. Z.B. bei 7-zip, wie sich herausgestellt hat. Da ist dann ja nichtmal C++03 drin...

rapso

SeppJ schrieb:

rapso schrieb:

vielleicht wuerde es helfen durch zufaellige c++ github projekte zu gehen und die zu klassifizieren, bis du eine menge has die das ergebnis nicht mehr grossartig variiert.

Das habe ich übrigens bewusst nicht vorgeschlagen, weil es ungefähr so seriös klingt wie die Tiobe-Statistik./quote]

ich sah bisher keinen besseren vorschlag, deswegen hatte ich das bewust vorgeschlagen.

hustbaer

Mr X schrieb:

Da mir seit Jahren nicht die Zeit gegeben wird unsere Projekte auf eine neuere Visual Studio Version zu bringen hänge ich z.B. noch auf Visual Studio 2005 fest.

Naja, das ist bei weitem nicht so gruselig, wie die Erkenntnis, dass VC6 noch im Einsatz ist. Z.B. bei 7-zip, wie sich herausgestellt hat. Da ist dann ja nichtmal C++03 drin...

VC6 hatten wir noch bis vor ~3 Jahren im Einsatz.
Geändert hat sich das nicht durch einen Umstieg, sondern dadurch dass das Produkt eingestellt wurde.

rapso

hustbaer schrieb:

... dass VC6 noch im Einsatz ist. Z.B. bei 7-zip, wie sich herausgestellt hat. Da ist dann ja nichtmal C++03 drin...

VC6 hatten wir noch bis vor ~3 Jahren im Einsatz....

war da nicht sogar noch der for-schleifen bug dass die loop-variablen ausserhalb der loop-scopes sichtbar waren bzw kollidierten?

hustbaer

rapso schrieb:

hustbaer schrieb:

... dass VC6 noch im Einsatz ist. Z.B. bei 7-zip, wie sich herausgestellt hat. Da ist dann ja nichtmal C++03 drin...

VC6 hatten wir noch bis vor ~3 Jahren im Einsatz....

war da nicht sogar noch der for-schleifen bug dass die loop-variablen ausserhalb der loop-scopes sichtbar waren bzw kollidierten?

Korrekt.
Wir hatten da einige Konstrukte ala

{for (...)
{
    // body
}}

in Code von dem es einen vc6 und einen vc8 Build gab.

Hacks wie
#define for if (false) {} else for
haben wir uns immer verkniffen. Obwohl ich diese Lösung eigentlich ziemlich geil finde

Irgendwie was das schon lästig, aber in Wirklichkeit kein grosses Ding.
Viel schlimmer waren die ganzen Bugs in der Template-Implementierung.

Columbo

hustbaer schrieb:

Hacks wie
#define for if (false) {} else for
haben wir uns immer verkniffen. Obwohl ich diese Lösung eigentlich ziemlich geil finde

Sie ist clever, führt aber auch undefiniertes Verhalten herbei ([macro.names]/2). Darauf wird mit VC6 sicherlich noch geschissen, kann aber doch zu Schwierigkeiten bei der Überführung auf andere Versionen führen?

hustbaer

Naja, sowas packt man, wenn man es schon verwendet, natürlich in ein

#if defined(_MSC_VER) && _MSC_VER <= 1200
#define for if (false) {} else for
#endif

Damit umgeht man einen Compiler-Bug indem man nicht-garantiertes (aber AFAIK auch nicht verbotenes) non-Standard Verhalten des selben Compilers ausnutzt. Nämlich dass es halt mit MSVC <= 6.0 nicht zu UB führt. Bzw. wenn man will kann man auch sagen dass das "U" im "UB" von MSVC hier halt immer zufällig das ist was der Standard ohne "U" vorschreiben würde. Und nachdem "U" eben alles sein kann/darf, ist es mMn. auch OK wenn ein bestimmter Compiler bestimmte "UBs" klar definiert.

Wobei mir bei UB gerade wieder der wunderschöne Term "catch fire semantics" einfällt. Tut nix zur Sache, wollte es nur erwähnen weil ich den Ausdruck so cool finde

hustbaer

Achja...

Mr X schrieb:

VC6 (...) Da ist dann ja nichtmal C++03 drin...

Da ist nichtmal C++98 drin

rapso

hustbaer, du wuerdest von mir den eisernen c++ orden bekommen dass du noch bis 2012 den VC6 compiler die treue geschworen hast. ich hatte VS6 als entwicklungsumgebung gemocht (nutzbarer als viele .net versionen danach), aber der compiler war ein wenig hardcore (man musste sogar prozessor packs und patches in der richtigen reihenfolge aufspielen damit da nichts boeses passiert ).

wieso seit ihr nicht kontinuierlich migriert?

Nathan

Jetbrains hat da mal Daten erhoben: http://blog.jetbrains.com/clion/2015/07/infographics-cpp-facts-before-clion/
Laut ihnen verwenden 34% C++11.

MatzeHHC

Nathan schrieb:

Jetbrains hat da mal Daten erhoben: http://blog.jetbrains.com/clion/2015/07/infographics-cpp-facts-before-clion/
Laut ihnen verwenden 34% C++11.

Vielen Dank Nathan, genau das habe ich gesucht!

nachtfeuer

MatzeHHC schrieb:

Nathan schrieb:

Jetbrains hat da mal Daten erhoben: http://blog.jetbrains.com/clion/2015/07/infographics-cpp-facts-before-clion/
Laut ihnen verwenden 34% C++11.

Vielen Dank Nathan, genau das habe ich gesucht!

Eine Werbeanzeige?

trotzdem auch: Danke Nathan!

[OT]
hustbaer sollte froh sein, das ich nicht sein Chef bin. Dann gäbe es nur Watcom-Tools. Größere Bitbreiten würden notfalls per Hexeditor eingeflogen - zumindest beim Hexeditor gäbe es freie Auswahl.
[/OT]

hustbaer

Der Watcom war damals schon cool.
Bisschen verbuggt, aber cool.
Is aber auch schon bald 20 Jahre her.