C++ IDE

Vim med en väl vald samling plugins brukar vara poppis. Kolla upp vilka de mest populära tilläggen är och se om det är något du tycker verkar smidigt. Det finns också många guider/blogginlägg att hitta om att använda Vim som subsitut till en större IDE, med tips om tillägg och arbetsflöden.

Code::Blocks nämner inte specifikt C++11 men stöd för clang som kompilator finns (den jag använder för C++11).

Netbeans beskriver uttryckligen stöd för C++11 och liksom Code::Blocks finns den på flera plattformar.

Jag rekommenderar inte VIM och andra antika verktyg i dagens läge. Embarcadero har ett riktigt vasst RAD-verktyg för C++, vill du komma igång med windowsprogrammering snabbt så är det nog den bästa vägen.

Tror det är lite begreppsförvirring då överskriften till denna tråd säger "C++ IDE". Visual Studio 2013 har riktigt bra stöd för C++11, nästan lika bra som GCC och Clang (dessa två har i princip en helt komplett implementation och MSVC++ är inte långt efter).

MSVC++ har däremot uselt stöd för C efter C89 som är den sista version av C där C är en delmängd av C++. C99 divergerade från C++ och det har inte konvergerat på senare tid.

Själv föredrar jag gcc/clang (gcc producerar bättre kod, clang ger mycket bättre kompileringsfels-meddelande), gdb och Emacs.

Körde under många år VS både i hobbyprojekt och professionellt, men MS verkade helt tappa intresse för C++ efter VS7 plus att jag började köra Linux på skrivbordet. Sedan Herb Sutter kom till MS så har MSVC++ ryckt upp sig rejält, har väldigt stort förtroende för Sutter så tror han kommer fortsätta få MSVC++ att utvecklas i en bra riktning. Dock är det lite p.g.a. av Sutter som C-stödet är så uselt, han ansåg tidigare att stöd för C var meningslös då "ingen använder det idag". Tror han fått backat på detta och det ska eventuellt komma C99 stöd i MSVC++ (dock är C redan i version C11, tror alla vet detta men C99 = standard som som sattes 1999, C11 = standard som sattes 2011...).

Man ska inte sticka under stolen med att Emacs är svårt att lära sig, det är en nära nog vertikal inlärningskurva men när man lär sig denna editor så ter sig VS-editorn lite som Wordpad mot Word vad det gäller editera kod.

Ska man debugga "normala" så går det inte att säga annat än att VS debuggern är toppklass. Men ska jag ge mig på de riktigt kniviga problemen (race-conditions och andra Heisenbug's) så tar jag gdb+emacs integration+gdb-script+special-emacs-funktioner 10 gånger av 10.

Håller med de som säger att det är bättre att använda färdiga ramverk om målet är att göra något som ska användas under någorlunda normala förhållanden under drift. Språk som Go, ramverk som Node.js och program som Nginx innehåller alla ett "modernt" sätt att skriva nätverkskod som skala till långt större system än vad man kan bygga med blockande sockets + trådar.

Men det går definitivt att spöa dessa ramverk med en eller ett par heltalsfaktorer med egen C-kod + trådar låsta till specifika logiska kärnor (stöds av moderna Windows och Linux, men tyvärr inte av OSX) + egen schemaläggare + epoll (Linux) / I/O Completion Ports (Windows).

Man kan gå ännu längre och även lyfta ut nätverks drivers till applikationen (t.ex. via DPDK eller OpenDataPlane). Hade en presentation kring detta på Kista-mässan förra hösten där det kort beskrevs hur jag gått tillväga för att få prestanda som överstiger ramverk som Node.js med mer än en tiopotens på en normal 8-kärnors Xeon-server.

Vim är inte känt för att vara något större prestandamonster, så det går säkert också att köra på den maskinen om du fastnar för det (reserverar mig för att din maskin skulle vara låst mot extern mjukvara på något exotiskt sätt).

Plugins i Vim är möjligen speciellt, men det är (idag) inte så många steg som man behöver få kläm på för att det ska gå enkelt framöver. Jag skrev om det i detta inlägg för inte alls länge sedan här på forumet. YouCompleteMe utvecklas på GitHub, så efter att Vundle installerats korrekt så är det bara att lägga till raden

Plugin 'Valloric/YouCompleteMe'

i `~/.vimrc` och köra `:PluginInstall` så ska det vara klart, oberoende av plattform. Det gör också att om man delar sin `~/.vimrc` mellan flera plattformar så "bara fungerar det"™ (ändå tills det inte gör det av någon anledning, men jag har inte haft några problem; har dock inte testat på något annat än Linux, men så länge som Git är installerat så bör det gå smärtfritt) och är lätt att helt och hållet inifrån Vim hålla alla plugins uppdaterade.

EDIT: Ser dock att just YouCompleteMe kräver lite extra magi för att koppla in i andra program, och att det som du säger kan kräva extra balett på Windows. Jaja, plugins i Vim är generellt inga problem .

MSVS 2013 har OK stöd för C99 så länge man har update 2 installerat.

Vet inte om jag skulle kalla stödet för "OK" när det finns kända buggar i implementationen av C99 "designated initializer" samt stöd för C99 "variable length arrays" saknas.

Det första är syntaxen för att specificera vilka medlemmar i en struktur du vill initiera

struct my_struct {
    int a;
    int b;
};

...
struct my_struct s = {
    .b = 123; // Detta fungerar i.o.f.s.
};

det andra är att man inte behöver ha en konstant när man deklarerar en array på stacken

void foo(int x) 
{
    int arr_of_ints[x];
    ...
}

VLA:s anses väl vara "bad practice" dock, så det är inte hela världen. Anledningen är att de är olämpliga att använda för stora mängder data (stacken är ganska begränsad) och för små mängder data kan man lika gärna använda en fixed size för maxstorleken, vilket även ger marginellt bättre prestanda.

x264 går att kompilera med cl.exe från MSVS2013 update 2, och vi använder oss friskt av C99.

VLA har samma problem som användning av rekursiva funktioner, så det finns lägen när man ska undvika detta men tror få säger att rekursiva funktioner är "bad practice" rent generellt. Som förval har Windows 1MB stack medan Linux har 4MB för 32-bit och 8MB för 64-bit, så går att göra rätt mycket innan den tar slut. Vad det gäller hastighet mot att använda statisk array-storlek på stacken så skiljer det en add <sp>, <reg> i funktionsprologen, tvivlar på att du ens kan mäta skillnaden i prestanda...

En sak som varit trasigt med "designated initializer" är att initiera medlemmar som själva är strukturer.

Men detta är ändå bra specifika detaljer, det stora problemet med att använda C99 med MSVC++ just nu är att det är ett minfält då man aldrig vet vad som fungerar och vad som inte fungerar. Kan man t.ex. använda C99 nyckelordet restrict numera? Tidigare fungerade bara __restrict.

MSVC++ implementerar också många standard C-funktioner via C++-funktioner. Man förstår varför och i de flesta fall kanske det inte spelar så stor roll, men många gånger väljer man C därför man har extrema krav (väldigt hög prestanda eller väldigt klen enhet) och då är det inte så lämpligt om standardfunktioner drar in hela C++ världen då denna äter mer resurser.

Om man verkligen vill köra C så finns ju andra kompilatorer för Windows, t.ex. ICC, clang eller minGW som stödjer C99. ICC har ju fördelen att producera riktigt snabba binärer och är gratis i privat/utbildningssyfte.

För C++ är MSVC en riktigt bra kompilator.