A Microsoft Visual Studio 2012 a harmadik fordító, amely teljesen támogatja a C++11 szabványt...

... nem. Még most sem.
Ezt képesek produkálni: http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx
Rendesen el vannak maradva. Gondolom nem fűződik hozzá túl nagy piaci érdekük. Amit azért sajnálok.

(Ez most egy bosszankodós blogbejegyzés)

Ld. lentebb, vsnprintf és társai.
Az is meglepő, hogy egy ilyet nem fordít le: 


#include <stdio.h>

int main(int argc,char* argv[]){
int a=5;; // két pontosvessző!
int b=1;
printf("%d\n",a+b);
return 0;
}

Mégpedig a következőképpen nem teszi ezt meg, így reprodukálható:
Létrehozol egy új projektet (empty console application).
Létrehozol egy üres text file-t, hozzáadod a fentebbi kódot, elmented valami.c néven (.c kiterjesztés), majd hozzáadod a projekthez (add existing). (szerk: ha létrehozol egy új .cpp forrásfilet .c kiterjesztéssel, akkor is ok. A lényeg, hogy üres projektből indulj).

Az általam kapott hibaüzenet:

1>------ Build started: Project: ConsoleApplication3, Configuration: Debug Win32 ------
1> main.c
1>c:\users\wachag\documents\visual studio 2012\projects\consoleapplication3\consoleapplication3\main.c(5): error C2143: syntax error : missing ';' before 'type'
1>c:\users\wachag\documents\visual studio 2012\projects\consoleapplication3\consoleapplication3\main.c(6): error C2065: 'b' : undeclared identifier
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Eltávolítva a ;-t az int a=5;; legvégéről rögtön fordul.
A kód, amit írtam valid C++, viszont - ha jól láttam, C-ben csak a C99 szabvány támogatja.

A kérdésem: ha a Visual C++ C++ fordító, miért hibás a fenti kód? Mert nem C++ fordítóval fordította, hanem a régebbi C szabvány szerint.

Szerk: tegnap erre is ráfutottam, onnan tudok róla.

Ez mind rendben van, de vannak sajnos más problémák is. Egy példa:
vsnprintf - MSDN
vsnprintf - cplusplus.com

Ha megnézed, teljesen máshogy van specifikálva a függvény visszatérési értéke a két helyen:

vsnprintf, _vsnprintf, and _vsnwprintf return the number of characters written if the number of characters to write is less than or equal to count; if the number of characters to write is greater than count, these functions return -1 indicating that output has been truncated. The return value does not include the terminating null, if one is written.

vs.

The number of characters that would have been written if n had been sufficiently large, not counting the terminating null character.

Amit linkeltel: Visual Studio 2005-hoz tartozo leiras.
A masik leiras meg a C++11 szabvany resze.

Nehogymar egy 8 eves fordito es runtime tudja a 2 eves szabvanyt. Az idoutazas meg a Microsofttol sem elvarhato.

Ez egy tipikus nevutkozesi hiba. Az MS implementalt valamit X eve, a szabvany kesobb meg ugyanilyen neven valami mast definialt. Az MS hibaja, hogy nem tudott sok-sok evre elore gondolkodni? Na ne mar!

A 2012-es dokumentációja is pontosan ugyan úgy definiálja a visszatérési értéket. A vsnprintf függvény pedig a standard C99 könyvtár része, tehát nem a két évvel ezelőtti C++11 szabvány specifikálta először. Arra pedig lehetett számítani, hogy a C99 újdonságai bekerülnek majd a következő C++ szabványba, bármikor legyen is az elfogadva. Azt nem tudom, hogy lehetne kideríteni, hogy a Microsoft verziója mikor lett definiálva, de 2000-ben már elfogadták a C99 szabványt.

A visszafele kompatibilitás meg le van szarva, mi? Az is elvárható, hogy az a kód, ami a visual studio 2005-tel fordult, az a visual studio 2012-vel is ugyanúgy forduljon és ugyanazt csinálja. Az egyetlen megoldás, hogy valahogy (pl. #define, vagy fordító opció) lehessen befolyásolni a viselkedését, és akkor már csak azt kell eldönteni, hogy melyik legyen a default.

Ezt én megértem. Csak az a baj, hogy utánanéztem, és a Visual Studio 6.0 még csak a _vsnprintf függvényt támogatta, tehát az aláhúzásjel-mentesített verzió vélhetően a C99 elfogadása után került be. És ha ez így van, akkor teljességgel érthetetlen, hogy miért implementáltak a specifikációval ütköző módon egy olyan függvényt, amelyről tudták, hogy gyakorlatilag biztosan a következő C++ szabvány része lesz.

"Microsoft Visual C++ (often abbreviated as MSVC or VC++) is a commercial (free version available), integrated development environment (IDE) product from Microsoft for the C, C++, and C++/CLI programming languages."

Szerintem nem. Es a VC++ -hoz csak egy darab compilert adnak, tehat nincs olyan, mint a gcc-nel, hogy a gcc C compiler, a g++ meg C++ compiler. Elvben kutyakotelessege lenne mind a C mind a C++ szabvanyoknak megfelelni. Az, hogy nem felel meg, az nem a szabvanyok hibaja. IMHO.

Azt mar csak halkan emlitem meg, hogy a vsnprintf az a POSIX API layernek is resze, tehat ahhoz mindenkepp konformnak kellene lennie. Szerintem lenyegtelen, hogy melyik C++ szabvany definialja, mert a POSIX API definialja, es a nyelvi kulonbseg nem okozhat mukodesbeli elterest.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

"Szerintem nem. Es a VC++ -hoz csak egy darab compilert adnak, tehat nincs olyan, mint a gcc-nel, hogy a gcc C compiler, a g++ meg C++ compiler. Elvben kutyakotelessege lenne mind a C mind a C++ szabvanyoknak megfelelni. Az, hogy nem felel meg, az nem a szabvanyok hibaja. IMHO."

Az előbb már elmagyarázták, hogy névütközés miatt van a gond. Melyik részét nem érted?

"Azt mar csak halkan emlitem meg, hogy a vsnprintf az a POSIX API layernek is resze, tehat ahhoz mindenkepp konformnak kellene lennie. Szerintem lenyegtelen, hogy melyik C++ szabvany definialja, mert a POSIX API definialja, es a nyelvi kulonbseg nem okozhat mukodesbeli elterest."

Nettó hülyeség. Már miért kéne a win32 C-nek implementálnia a POSIX-et? Semmi köze hozzá. C fordító, nem POSIX fordító. Ennyi erővel a gecicének is implementálnia kéne a win32-t.

( bviktor | 2013. 07. 05., p – 02:57 )

Ez egyébként téged hogyan akadályoz téged érdemben a fejlesztésben?

( wachag | 2013. 07. 05., p – 09:09 )

Ez csak a trey-bviktor újrabootolásos vitához jutott eszembe, most rakom fel az Update 3-at, ezt írta ki:

Please close Visual Studio now to reduce the chance that a computer restart will be required later.

"reduce the chance"... ilyet leírni szerintem kicsit igénytelen :-).

Szerk: reduced chance ellenére is újra kellett indítani sajna, hiába, mint tudjuk, a reduced nem jelenti, hogy nem fog bekövetkezni :-(.

Újraboolásos vitához annyit, hogy mi a fasznak kell Windowson egy felhasználói program telepítése után reboot? Minek kell egy Hyper-V role telepítése után reboot egy _szerveren_? Mi ez, a középkor? Továbbá, Windows Update-et miért kell 123 szakaszban megcsinálni?

"Találtam 123 frissítést."
<reboot>
"Megint találtam 12 frissítést"
<reboot>
"Már megint találtam 3 frissítést"
<reboot>
Fogadjunk, hogy megint találtál frissítést, a k. anyádat.
<egy ideig semmi>
<öt perc múlva>
"Megint találtam 4 frissítést"
<reboot>

--
trey @ gépház

Pl. mivel teljesen máshogy kezelik a futtathatókat/dinamikus library-kat, azért. Tölts be egy exét, aztán próbáld meg kitörölni. Aztán tölts be egy bint Linuxon, és próbáld meg ugyanezt. Ezek után talán rájössz a kurva nagy rejtély megoldására.

Ha egy program betölt egy rendszer DLL-t, akkor azt hogy a picsába frissíted, hm? Bármelyik program ráülhet, bármelyik a több millió közül, amit valaha írtak Windows-ra. A Windows hogyan garantálja neked, hogy nem lesz ilyen? Vajon miért írja ki sok telepítő, hogy léccine használj más programot a telepítés alatt? :)

Amikor pedig mondjuk IE frissítés emiatt csak újraindítás után tudja a helyére tenni a DLL-t, nyilván csak az újraindítás után fog tudni ehhez a DLL-hez további frissítéseket telepíteni. Bizonyára meg lehetne ezeket a problémákat kerülni, de triviálisnak semmiképp nem nevezném.

posix rendszereken voluntary file locking van, windowson mandatory, mindegyiknek van elonye hatranya
hozzajon meg az, hogy a klasszikus unix rendszeren a kitorolt fajl inodeja megmarad amig nyitva van

viszont ha van egy linux programod, legyen 'server', ami linkelve van libserver.so.1-hez es frissited libserver.so.2-re,
de nem inditod ujra 'server', akkor a regit fogja hasznalni, mi akkor eleg gaz, ha eppen egy vulnerability miatt
volt a frissites

--
NetBSD - Simplicity is prerequisite for reliability

Jah megbízhatóság, biztonság és a Windows Update. Persze.. Ha valami miatt - mondjuk áramszünet - beragad a WU folyamatba egy frissítés akkor jöhet a szívás, a registry túrás és a görcsölés. Pont így jártam, de mást se tud mondani ez a szar mint 0x800ffff, amire az MS in-place-upgrade -et javasol. Ráadásul a Vista óta ismert a probléma, de mégis csak előjött 2008R2-es szerverben.

Hihetetlen, hogy mennyivel korszerűbb mint egy apt-get install -f vagy dpkg-reconfigure -a

( wachag | 2013. 07. 05., p – 09:36 )

Hozzáfűzném, hogy maga az IDE az tényleg nagyon jó (bár elsősorban Eclipse-t használok). Csak ez kicsit szépséghiba számomra.