För användaren spelar det knappt någon roll alls, fungerar applikationen som förväntat så är användare nöjd.
Men diskussionen här tar upp dumheterna USAs myndigheter gått ut med att skriva kod i "minnessäkra" språk. Det är nästan lika dumt som att säga att bilar inte får lov att köra med hjul så därför tror jag inte på orsakerna de nämner. Tror det är något annat som ligger bakom.
Skulle jämföra det mer med att vi tids nog inte kommer få köra ICE-bilar. Men precis som det lär det vara en bra bit bort till ett direkt förbud.
För i nuläget handlar det inte om något förbud. Däremot behöver man framåt ha en rimligen förklaring till "varför" om man tänker utveckla i C eller C++.
Sett en del kommenterar kring det om att affärsmässigt kan det medföra att man lättare kan bli stämd om man väljer C eller C++ och det sedan skiter sig i form av säkerhetshål. Men det är ju spekulation i nuläget.
Och är ju som sagt så att även ISO C++ gänget håller med att något bör göras. De är bara oense om exakt vad som behöver göras framåt och är väl egentligen vägen de i slutändan kommer följa som är frågeställningen i denna tråd.
Tycker Bjarne S har en rätt naiv inställning till just detta problem. Hans inställning verkar mest vara: men vi har ju skrivit fina guidelines och om folk bara följde dessa till 100 % skulle det inte finnas några problem. Vilket inte stämmer om man inte räknar med att folk skriver felfri kod.
Det Rust visat är att det till och med är möjligt att fånga race-condition, use-after-free och en lång rad problem vi historiskt haft gott om i C och C++, och att dessa kan hittas redan av kompilator!
Safe C++ förslaget vill ju ta ISO C++ ungefär dit Rust är idag. Problemen är nog primärt två där. Dels blir resultatet något som är rätt annorlunda från dagens C++, det ser väldigt mycket ut som Rust skrivet med C++ syntax. Dels hjälper det inte existerande kod och huvudanledningen att använda C++ (eller C) idag är för att man bygger vidare på existerande kodbas(er) i dessa språk.
Applikationsutvecklare har hårt tryck på sig att utveckla saker som fungerar för kunden, gör det inte det så blir det jobbigt.
Saker har ju ändrats med åren. En sak vi har idag är att multi-core är normen och det finns flera tekniska fördelar med att använda GC-språk när man jobbar med mulitrådade program. Dock finns ju också systemprogrammerings-fall där GC inte är lämpligt, så man kan inte släppa manuell minneshantering helt (men det är en allt smalare nisch).
Och skulle USA och Europa gå så långt som att förbjuda C++ kommer asien att slakta oss inom mjukvara också. Våra politiker verkar göra allt de kan för att förstöra förutsättningarna och flytta all tillverkning ill asien.
Ingen pratar ju om förbud. Samma gäller ju tech-jättarna som alla har en av världens största C++-kodbaser.
Det handlar om att man inte längre ska välja C eller C++ av slentrian. Om ett minnessäkert språk fungerar ska man välja det, om man måste välja C eller C++ får man förklara varför och sen köra på.
Senaste embedded-projektet jag jobbade med använde med fördel Go (var lite av en lyckträff, initialt stod valet mellan C++ och Rust men visade sig att just i detta fall fungerade Go faktiskt bättre).
För mig så är det framförallt problematiskt med att editorn är seg på att hänga med med markeringar. Typ som att om man rättar en sak som markerats som fel så dröjer det en stund innan editorn fattar att det är rättat. Det är speciell så när jag kör WSL.
Debuggern går heller inte att jämföra med Visual Studios, tänker då på C++
VSCode har obland svårt att hoppa till deklarationer/definitioner. Kör man CMake fattar den inte alls (i alla fall inte för mig), variabler och annat i CMake alltså
Ah, nu har jag faktiskt aldrig använt VS Code för C++ mer än väldigt simpla saker. Är något år sedan jag senaste jobbade med C++ och senast användes Rider (och om inget radikalt har hänt senaste 2-3 åren skulle jag välja Rider igen utan att blinka). Innan det använde jag primärt Emacs för C++.
Hur bra/dålig intellisense fungerar i VS Code beror ju helt på "language services" för det språk man använder. Tar man Go (där dessa saker är helt skrivna i Go BTW) så är det blixtsnabbt och otroligt stabilt. Bl.a. då VS Code rätt mycket är förhandsvalet från Go-gänget.
Rust fungerar också väldigt bra i VS Code, likaså Typescript och Python.
Edit: använder i.o.f.s. Platform I/O en hel del ihop med VS Code. Även om det rent tekniskt är C++ handlar det ju om extremt simpel C++ som mer är C med lite klasser... Platform I/O är ju ett ramverk för att jobba med mikrokontrollers.
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer
