Hur komplierar jag ett Microsoft Visual Studio Community projekt med Clang?

Nu kan jag inte Windows men känns som det saknas en del info här. Vad är det som gjorde att du inte kunde bygga med Vcpkg påslaget? Vad förhindrar dig från att använda Vcpkg nu?

Är det du gör ovan "rätt" sätt för att installera clang?

LLVM-biblioteket må bygga hela kompilator-delen, men normalt är LLVM-biblioteket något man använder om man vill bygga sin egen kompilator.

Går ju att installera färdiga binärer direkt i VS
<Uppladdad bildlänk>

Sen finns den flera goda anledningar varför VLA inte finns i C++. Det anses vara ett misstag att det alls lades in i C99 då det finns en rad problem med finessen.

Den i praktiken onödig, de flesta OS hade redan någon variant av alloca() som kan användas för samma funktion (fast man kan även lägga in verfiering av storlek så det går att ge bättre felmeddelande om/när stacken "sprängs"). I Windows finns detta
https://learn.microsoft.com/en-us/cpp/c-runtime-library/refer...
som fungerar med alla kompilatorer.

VLA är med 100 % säkerhet en bugg om man inte vet största storleken på utrymmet. Vet man största storleken kan man (och bör man) använda statiska arrayer (vilket både C och C++ stödjer).

VLA gör också att sizeof kan få oväntande effekter, den kan ha icke-noll runtime-kostnad!

Men vill du absolut använda VLA ihop med vcpkg, clang, cmake och Windows verkar detta fungera

"C:\Program Files\CMake\bin\cmake.EXE" --no-warn-unused-cli -DCMAKE_TOOLCHAIN_FILE:STRING=C:/Users/kenne/tools/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE "-DCMAKE_C_COMPILER:FILEPATH=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\Llvm\x64\bin\clang-cl.exe" "-DCMAKE_CXX_COMPILER:FILEPATH=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\Llvm\x64\bin\clang-cl.exe" -SC:/Users/kenne/source/repos/cmake_hello -Bc:/Users/kenne/source/repos/cmake_hello/build -G "Visual Studio 16 2019" -T ClangCL,host=x64 -A x64

Där jag då har vcpkg installerad här "C:/Users/kenne/tools/vcpkg" och har installerat clang som visas ovan.

Fungerar "sådär" i Visual Studio... Men fungerar felfritt med VS Code.

Clang är väl inte nödvändigtvis helt kompatibel med cl? Måste du verkligen köra vcpkg (eller går det kanske att specificera att man vill ha för clang)?

Hela situationen låter märkligt. Nu kör jag inte Windows och kan inte verifiera något av detta men jag misstänker att vcpkg utöver att vara en pakethanterare även ger användaren kompilator- och länkarflaggorna för enskilda paket. Om det skulle finnas en inkompatibilitet mellan clang och vcpkg så är det väl för att vcpkg inte tillhandahåller samma flaggformat som clang förväntar sig. Detta borde @heretic16 kunna verifiera. Resterande arbete är ju hur man väljer att sy ihop vcpkg med ditt val av byggsystem.

Har jag missat något uppenbart?

Du skriver inte vilken projekt-typ du använder i Visual Studio. Testade lite och givet felet du får verkar du ha en projekt-typ där VS använder sin egna propretära format (vilket är fullt rimligt om man bara tänker använda det hela på Windows).

Verkar som den metoden i praktiken bara fungerar ihop med MSVC++ om man använder VCPKG

Kanske blev lite otydligt vad som är de viktiga delarna i CMake exemplet jag visade ovan... Den viktiga delen för att få VCPKG att lira ihop med LLVM/Clang är detta argument till cmake.exe

-DCMAKE_TOOLCHAIN_FILE:STRING=C:/Users/kenne/tools/vcpkg/scripts/buildsystems/vcpkg.cmake

Utan den får man liknade problem som i Visual Studios egna format. Denna fil hanterar "toolchain" specifika delar, d.v.s. den hanterar de delar som skiljer sig mellan Clang och MSVC++. Verkar som Visual Studio saknar motsvarande justeringar när man använder det inbyggda projektformatet.

CMake är inte ett byggsystem, det är ett system för att skapa byggsystem. Så om man går via CMake kan man ju låta utdata vara ett Visual Studio projekt där man satt LLVM/Clang som kompilator -> går att använda VCPKG ihop med Clang.

Fördelen med denna metod är att saker fungerar. Nackdelen är att man tappar en hel del av integrationen som Visual Studio användare nog förväntar sig. Testade inte allt för mycket, men verkar som man i praktiken behöver köra all förändringar av projektet via CMake CLI-verktyg. I det läget ger Visual Studio Code en betydligt bättre upplevelse då den är bättre anpassade för att jobba med CMake projekt.

Huvudfrågan här är ändå kanske: varför vill du använda VLA? Om det "bara" handlar om att allokera minne på stacken där mängden bara är tillgänglig "runtime", vad är det för fel på att använda alloca()/_alloca() (heter _alloca() i Windows, funktionen finns även i Linux och MacOS och heter då alloca())?

Värt att notera är att manualen för alloca() säger detta

alloca() is machine and compiler dependent; its use is discouraged.

det gäller även VLA i kompilatorer som stödjer funktionen, är ännu en i raden av anledningar varför t.ex. standard C++ inte har VLA.

alloca() fungerar både i C och i C++.

Om man bara bryr sig om en plattform och en miljö komplicerar CMake bara saker och är därför inte vettigt att använda.

CMake har sina egna komplexiteter, man får i praktiken leva med dessa om man vill bygga moderna C/C++ projekt som ska gå att bygga för många OS, med många olika kompilatorer (även om vi rätt mycket bara har kvar 3 st för "vanliga" datorer, GCC, Clang och MSVC++) etc.

MSVC++ har alltid haft fokus på C++, det är en rätt kass C-kompilatorer. I alla fall om man vill ha något som håller sig till ANSI-C standarden.

Svaret är med 99,9 % sannolikhet att du inte bör använda VLA.

Vet du största möjliga storlek som någonsin behövs allokeras?

Är svaret "nej" har du garanterat en bug i ditt program om du använder VLA/alloca(). I det läget måste man använda malloc()/free() i C eller std::vector<> i C++

Är svaret "ja" och prestanda är kritiskt blir det minst lika snabbt att alltid allokera maxstorlek via "vanlig" C-array alt. C++ std::array<>. Det förutsatt att maximal storlek är relativt liten, inte större än enstaka kB. Större än så kommer overhead att allokera från heap:en ändå vara irrelevant i förhållande att läsa/skriva i det allokerade minnet.

Edit: vill du ändå använda VLA så kan du lika gärna köra med alloca(), kommer i praktiken bli samma sak som görs där som om man löser det med C99/VLA.