QT Creator VS Visual Studio

Gäller det alltså bara vilken IDE man skall välja, eller menar du mer än så? Qt creator fungerar ju väldigt väl tillsammans med Qt (men man kan ju köra VS också om man vill) medan VS troligen är lämpligare om man kör MFC.
Annars är det ju till stor del en smakfråga. En fördel med Qt creator är att den fungerar lika bra (och likadant) på Mac och Linux som i Windows.

@heretic16 Är det snarare Qt mot .NET som är frågan alltså? Det senare är ju inte helt aktuellt om du vill köra c++ (c++/cli finns ju förvisso, men det känns alltid lite eftersatt och finns endast för Windows).
Jag vet inte om det är någon miss för Qt heller (som ju har funnits till alla möjliga plattformar sedan Hedenhös). Observera också att .NET inte har något grafiskt ramverk för Linux (ens på gång vad jag vet).

Måste ställa mig lite frågande till varför c++ väljs här?
För "vanliga" klientapplikationer är java/c#.net eller python väldigt mycket mer lättjobbat.
Qt och c++ skulle jag endast välja idag i klientapplikation om det finns hyfsat extrema prestandaflaskhalsar.

Gör du detta i syfte att lära dig eller skapa en kommersiell produkt?

Spännande, vore intressant om du kan/vill precisera vilken industri?
Jag själv har jobbat med allt från embedded till webb i Sverige och på många platser stämmer inte din bild tycker jag.
Ska man interfacea mot något exotiskt kan det såklart vara nödvändigt och till och med enklare ibland med c++.

Vill man jobba med klientapplikationer är i varje fall i Sverige .net/java de två glödheta plattformarna enligt mig.

För .Net hade jag valt VS och för java hade jag valt IntelliJ.

Sorry för lite halvt offtopic från mig men jag ville utmana valet litegrann.

För c++ hade jag valt VS eller CLion (JetBrains) om du kan få tag på en education license. Sen kanske Qt Creator för de Qt specifika bitarna.

Eftersom du verkar glömma det ungefär en gång i månaden och startar en ny tråd istället för att våga testa på saker kan jag erbjuda en påminnelse: du kommer aldrig bli en bra mjukis om du inte vågar testa och lära dig nya saker. Du måste lära dig om och testa på flera alternativ för att klara av att göra bedömning om vilket verktyg som är lämpligast för att lösa ett givet problem. Ingen mängd forumtrådar med vaga frågeställningar om vilket språk/ramverk/paradigm är bäst kommer ta dig framåt. Det största hindret för dina framsteg är dig själv och din ovilja att lära dig något som du inte tror att du får omedelbar nytta av i vad det nu är för "industriella tillämpningar" du sysslar med.

För att svara på vad jag tror att du egentligen frågar efter: Marknaden efterfrågar definitivt C#/.NET.

Håller med @LemonIllusion 's inlägg dock, du måste gräva ner dig i ett projekt och faktiskt göra saker, inte bara tänka på hur du kan göra saker.

Om ditt syfte är att lära dig något som är användbart för dig själv rent karriärsmässigt, använd Visual Studio som IDE, använd C# som språk, och använd .NET/WPF som ramverk.

Jag vet inte varifrån du har fått den uppfattningen riktigt. Kundföretag skiter fullständigt i vad man använder för språk så länge man når upp till kraven och det går så fort som möjligt att få en fungerande applikation. Därför är det c# .Net som dominerar inom industrin, och förstås för att extrem prestanda inte är så viktigt där. Industriella processer kräver sällan superprestanda eftersom hårdvaran ändå sätter begränsningarna, det spelar ingen roll om din applikation kan hantera hundratals eller tusentals beräkningar per sekund om hårdvaran ändå bara kan bygga en produkt i sekunden liksom.

Grafiska applikationer på det sättet är på väg bort, webbgränssnitt är i allmänhet vad som gäller i princip överallt. Du pratar om att molnet tränger ut webbappar men molnet innebär ju nästan alltid ett webbgränssnitt så det är precis tvärtom. Att köra en applikation lokalt (på klientmaskinen?) efterfrågas inte alls längre utan industrin vill precis som alla andra ha saker som fungerar på allt från telefoner till chefens laptop på hans hemmakontor liksom. Så responsiva webbapplikationer som gränssnitt mot services i backenden.

Har nog faktiskt inte sett en enda annons där specifikt C++ efterfrågas Men om det nu är så, så är det förmodligen för någon nisse valde att utveckla i C++ för ett antal år sedan och det nu handlar om vidareutveckling inom samma miljö istället för att blanda in nytt. C# är helt klart det ledande alternativet idag

En "webbapplikation" kan lika gärna köra lokalt inom intranätet genom JavaScript. Bara för att det är en webbapplikation så betyder inte det att det är öppet mot WWW

C#/.Net/WFP/VS är ett lysande val förutsatt att man är säker på att man kommer köra på Windows/x86. .Net core (framförallt .Net 5) har på senare tid fått väsentligt bättre stöd för ARM64, men man startade från en bedrövlig nivå och ligger fortfarande efter både Java och framförallt efter Node JS och C++.

Java verkar lite ha gett upp UI-delen, vilket känns vettigt då det aldrig varit speciellt bra för att utveckla desktop-applikationer i. Men det är extremt moget, finns bibliotek för allt man kan tänka sig på "back-end" och fungerar bra både under Windows, MacOS, Linux (och fungerar bra på x86, Arm och även Linux/PowerPC).

Electron (Node JS + Chromium) måste ju vara det självklara valet 2021 om man vill bygga desktop applikationer som ska kunna köras på Windows, MacOS och Linux. Node JS är även ett toppval för "molnet" då det fungerar bra både på x86 och ARM64. Startar man med "rent papper" är bra ARM64 stöd en rejäl fördel då perf/$ är klart bättre på sådana instanser för det man väljer att köra "i molnet".

Node har också ett väldigt effekt gränssnitt mot C++ (och mot native Rust, även via WASM om man föredrar det). Så går att både får fördelarna med snabba cykler i Node med rå-kraften från systemspråk som C++ och Rust.

Vilket IDE som är bäst lär ju vara en rätt meningslös fråga: använd den du känner dig mest bekväm med. Personligen skulle jag säga att "modern C++" väldigt ofta betyder CMake. Även om CMake går att tråckla in i Visual Studio är det betydligt enklare och smidigare att jobb med Visual Studio Code (eller Vim eller Emacs för den delen).

Fördelen med VS Code är att man då inte är fast på Windows, det fungerar då lika under Windows, MacOS och Linux. Faktum är att man enkelt kan sitta på sin Windows dator, köra VS Code där och i realtid utveckla, debugga etc mot en Linux-server, inbyggt system eller liknande över SSH.

Antar att du med "industrin" menar IT-industrin?

För mig har ordet "industri" en smalare betydelse, tänker på "industritillämpningar" och där är C#/.NET allt annat än dominant.

Inom bilindustrin är C++ väldigt vanligt, bl.a. p.g.a. AUTOSAR.
Inom flygindustrin är C, följt av Ada följt av C++ vanligt p.g.a. kraven från DO178 (lycka till att få igenom ens något form icke-trivialt C# eller Java program genom den standarden...).
Inom robotics är C++ väldigt vanligt, men här har jag i alla fall sett Java eller C#/.NET användas.

Givet vem TS är här misstänker jag att kontext för "industri" är just "industritillämpningar / inbyggda-system". Där är fortfarande C och C++ klart dominerade.

Det är korrekt att alla de där (med flera) blir .Net till slut, men visual studio står på egna ben. Man kan använda den till annat också (till exempel Qt som ett alternativ till Qt creator). Qt creator är ett ganska nytt verktyg (medan Qt har flera decennier på nacken) som först på senare år har blivit riktigt kompetent. Dessförinnan fick man använda andra utvecklingsverktyg, och det fungerar naturligtvis fortfarade.

Den vettigaste definitionen jag sett på vad som är kännetecknet för ett "inbyggt system" är "ser du enheten primärt som en traditionell dator eller ej"?

Det gör en modern bil till "inbyggt system", trots att det idag sitter rätt bra med CPU-kraft och GPU-kraft där. Mobiltelefon är en gråson, den finns definitivt delar som är "inbyggda system" och skulle själv kalla även Iphone/Android för "inbyggda system" då deras primära uppgift inte är att agera dator (men är definitivt allt mer en gråzon här).

Ett tillägg man kan göra för att göra gråzonen lite mer svart/vit är: när man utvecklar programvara, kör man då utvecklingsmiljön "native" eller är "host" och "device" separerade? I den förra fallet är det ett uppenbart fall av "dator" medan det senare fallet helt klart även gör en moder mobil till ett "inbyggt system".

.NET är väl vad man använder det till, precis som allt annat?

Inte så att QT är något som man i någon större utsträckning kör på inbyggda system, även om det förkommer (och finns fall där man kör Windows/.NET på inbyggda system).

???????

Microsoft använder det till VS Code och Skype (eller vad nu Skype heter i nuläget). Det används av Slack, Discord, Wordpress desktop m.fl. Så företag investerad definitivt sin tid i detta!

Däremot är, som redan påpekats i tråden ett par gånger, trenden att man lägger allt "på webben" (i praktiken, man kör en back-end i "molnet" med en JS-baserad front-end som fungerar oavsett klient). D.v.s. det som kanske är på väg ut är den traditionella desktop-applikationen. Electron har ju de stora fördelen att det är en webbsida, så trivialt att köra resultatet både som desktop-app och via webbläsaren (går att köra VS Code i webbläsaren om man vill).

Så komplicerat är det knappast. Du har ju uppenbarligen lurat ut att det ibland är en funktion som heter main(), i andra fall en statisk metod som heter Main(String[] args), hur svårt kan det då vara att anpassa sig till JS, Python m.fl. att startpunkten är en specifik fil (är ju en specifik fil där main() ligger i) där programmet börjar köra uppifrån filen?

Så du gjorde ett misstag första gången du använde VS Code och då blir slutsatsen: det fungerar inte?
VS Code är för närvarande den mest populära textredigeraren i githubs senaste omröstningar. Det är för övrigt också nya "standardmiljön" för världens största RTOS, VxWorks. Där det tack och lov ersätter vraket Eclipse+CDT (Eclipse är en bra Java IDE, det har alltid varit en rätt kass IDE för C och C++ i min mening men vet att det finns folk som lyckas utföra arbete med den miljön...).

Om det känns C++ 98 kan det inte finns något bra med den miljön! Tror ingen som fortfarande jobbar med C++ ser något positivt med att klänga sig fast vid C++98. C++ var nära att dö sotdöden under perioden 2000-2010, det räddades mycket av det fantastiska jobb som Herb Sutter (Microsoft anställd som också är ordförande för C++ ISO-kommittén) lett.

Finns noll anledningen att köra mindre än C++14 idag. Finns också en poäng att stanna just vid C++14, det är idag en "mogen" standard och C++14 är i praktiken rätt mycket bara en bug-fix av C++11. C++17 har en del bra saker och GCC, LLVM/Clang och MSVC++ har alla lysande C++17 stöd. C++20 ska man nog bara ge sig på om man startar ett projekt från scratch idag, och man bör nog hålla sig till LLVM/Clang närmaste tiden (möjligen fungerar också senaste GCC).