Förslag på USB bibliotek för C++

1. Verkar stämma
2. https://github.com/libusb/libusb/tree/master/examples
3. Tror nog libusb är de-facto standard.

Om det bara är serieportar du vill hantera finns det säkert enklare bibliotek. libusb ligger på lägre nivå och hanterar även andra typer av enheter (de där siffrorna identifierar tillverkare och produkt).

libusb är i praktiken ett bibliotek som gör det möjligt att skriva drivrutiner för USB-enheter (i.e. för en specifik VENDOR_ID/PRODUCT_ID tuple) som ett user-land bibliotek.

boost::asio är ett bibliotek som t.ex. kan prata med serial-enheter där det redan finns en fungerande driver i kernel-space. Boost är vettigt om du vill läsa/skriva asynkront.

Vill du läsa synkront är det väl bara att använda vanliga IO-operation som finns i både standardbiblioteket hos C och hos C++?

Man bör absolut ha lite koll på Boost. Där finns ofta verktyg för komplicerade fall, men är det bara något enkelt man vill göra är det kanske overkill.
Här finns ett header-only-bibliotek för serieportar: https://github.com/wjwwood/serial

Nej, men det kanske inte behövs? Det är ju ett begränsat problem som man mycket väl kan bli klar med. (Nu har jag inte testat det där själv, det var bara något jag hittade)

Spelar det någon roll?
Gör koden vad den ska, och man inte hittar några buggar, så finns det väl inget behov av uppdateringar? (Säger inte att det är så - har ingen koll på projektet ifråga.)

Först en ordningsfråga: Det du är ute efter att göra är att skriva till serieport; inte usb (sedan råkar det kanske vara en virtuell serieport som är ansluten via usb, men jag tror inte att du vill kommunicera med den på den nivån. Om den dyker upp i operativsystemet med ett serieportsnamn finns det en drivrutin som sköter det åt dig).

Vilka behov är det? Jag skulle snarare tro att det finns många alternativ. Boost är inget dåligt val, men det finns kanske mer lättviktiga lösningar? Nu vet jag inte riktigt vad som gäller i ditt fall, men risken är man (utöver ha ha boost för att bygga applikationen) får beroenden på ett antal dynamiska bibliotek*.

*Det går förviso att komma runt med statisk länkning, men jämfört med att inkludera en h-fil är det omständligt.

APIet på *NIX-system har inte förändras m.a.p. serie-portar sedan 90-talet. Så är fullt möjligt att projektet är "klart".
Men har inte använt detta projekt så kan inte säga om så är fallet här.

Har dock använt detta rätt mycket (både i privata projekt och i arbete)
https://github.com/goburrow/serial

Senaste ändringen i Linux-specifika delen hände för 8 år sedan, det fungerar än

Rätt säker att boost själv inte har något Modbus-bibliotek. Det fanns då inget för ca 2 år sedan när jag var på jakt just efter ett sådant och C++ var ett potentiellt språk.

Valde initial sedan just libmodbus, men det hade (då i alla fall) en icke-färdig implementation. Rätt sker att libmodbus fungerar för många projekt, de som skrivit det initialt verkar ju ha löst just de problemet de råkade ha och har man själv samma/liknande problem fungerar det nog bra.

Inte relevant för dig då jag vet att du inte tänkte byta bort C++, men om det är någon som har möjlighet att fritt välja språk eller bara råkar använda Go redan nu kan jag tipsa om detta Modbus-bibliotek (för för Modbus RTU använder biblioteket ovan):

https://github.com/simonvetter/modbus

Var just att detta bibliotek fungerade så mycket bättre för Modbus (och Modbus var en kritisk komponent) som jag i större skala började använda Go. Visade sig vara ett väldigt trevligt språk för att hantera fältbussar (https://periph.io/), SBC, och annan low-level tech med väldigt mogna/stabila bibliotek

Om man gillar något ska man självklart fortsätta använda det. C++ är så pass viktigt än att det kommer utvecklas och finnas kvar under mycket långt tid framåt.

Tror i.o.f.s. en den av det där som bäst åsikter framförda av enskilda personer. Som det sista, givet att organisationer som Microsoft, Google och administrationen runt vita huset säger att Rust i nuläget är det som gäller i fall där en GC inte fungerar lär det språket ha en rätt säkrad framtid.

Ska bli riktigt spännande att följa det totala rewrite som DARPA ska göra av all deras C och C++ kod i Rust. Det är åtskilliga tiotals miljoner rader kod som man ska skriva om, det just för att de mest vanliga buggarna i C och C++ program inte ens kompilerar i Rust (en siffra som ofta nämns är att Rust tar 2/3 av alla C och C++ buggar vid kompilering, så blir inte buggfritt...).

Och tar man Java så slog självklart inte det ut C++ från allt. Men när jag började mitt arbetsliv i mitten av 90-talet var det väldigt mycket där det var självklart att använda C++, men som "ingen" idag ens skulle fundera använda C++ till utan det är främst Java, C# och eventuellt JS eller Python.

Så år den aspekten "dödade" Java/C# C++ inom rätt många områden.

Språket D är ju ett exempel på en lång rad språk som aldrig fått någon större popularitet. Har aldrig skrivit D, läst lite om det men aldrig riktigt förstått vad som skulle göra det värt att gå dit jämfört med alla andra alternativ som finns.

Go har nog aldrig ställts direkt mot C++, sett endel säga att man lite kan se det som ett modernt C men undrar om inte det är mest bara för Ken Thompson skapade C ihop med Dennis Ritchie samt att Rob Pike likt Ken Thompson jobbat mycket med UNIX (där C är "huvudspråk" för de flesta kärnor och grundbibliotek).
Finns ett par "killer features" i Go, en är att språket är väldigt enkelt att lära sig något man inte kan beskylla C++ för. Om lära sig Go är som att lära sig cykla är lära sig C++ som att lära sig flyga attackhelikopter i storm...

Zig har inte ens nått någon version 1.0, så det kan mycket väl bli ett av många språk som aldrig blir något. Och om något ska kallas "en modern version av C" skulle jag utnämna Zig till det, både till hur svårt det verkar vara att lära sig och till vad dess designers ser som Zigs huvudområden. Så ingen direkt konkurrent med C++.

Carbon är om något allt annat än en C++ killer. Dess huvudsyfte är ju att försöka fortsätta göra C++ relevant, frågan är om det är rätt sätt eller om andra idéer som t.ex. det förslag till "safe C++" är bättre. Verkar i.of.s. som Bjarne och en del andra inte riktigt gillar "safe C++" (som kommer pushas som ett ISO C++ förslag). Inte helt med på varför, men helt klart ser "safe C++" mer ut som Rust än som "vanlig" C++, och då kan man väl lika gärna använda Rust...

Det närmaste vi idag har en "C++ dödare" är väl just Rust. Är som sagt flera stora organisationer som i praktiken säger att nya projekt inte får använda C++, använd Rust om GC inte är OK annars finns flertalet språk att välja på.

Men gissar att det blir rätt likt som för Java/C# runt millennieskiftet. Vissa saker som idag primärt görs i C++ kommer framåt primärt göras i Rust, men C++ kommer ändå leva kvar på många områden. Givet vad du jobbar med verkar ändå Rust snabbt bli populärt för mikrokontrollers, då en variant som kallas "no-std Rust" (som väldigt mycket känns som en direkt konkurrent mot Zig, vilket ger Zig rätt stor uppförsbacke).

Men Rust lär inte nå någon värdsdominas. Det är inte lika komplext att lära sig som C++, men det är tyvärr en av de mer komplexa språken och förstår varför många känner frustration och "ger upp" med det språket. Kan mycket väl tänka mig använda Rust framåt om behoven kräver icke-GC-språk, men föredrar Go eller C# (och vilket av dessa beror på use-case) om möjligt.

Såg en del Modbus-bibliotek baserade på boost::asio, t.ex.
https://github.com/fizyr/modbus
https://github.com/ChrisBFX/mothbus

Men de verkar inte sett någon aktivitet på rätt länge och Modbus är ett rätt smalt use-case, så man får nog räkna med att projekt likt de ovan kanske löser mycket mer än det omedelbara problem deras skapare hade.

Rent krasst har faktiskt inte Rust någon konkurrent i det som är dess huvudsakliga "killer-feature". C++ kan bli en möjlig konkurrent längre fram om förslaget till "safe-C++" accepteras av ISO C++ och man skriver om all sin C++ kod från scratch inom ramen för "safe-C++" (som väldigt mycket ser ut som Rust, fast med lite mer svårläst syntax i.m.h.o).

Han som verkar styra Carbon, Chandler Carruth, är riktigt skarp. Så det bådar ju gått.
Men vet inte om du är medveten om vad de själva anser status för Carbon är ju nu, man befinner sig i förstudiefas där man i första hand vill ha svar på: finns det ens ett tillräckligt stort värde i något som Carbon för att gå till en v1.0?

Man hoppas kunna ha det svaret inom kanske 2 år.

Det DARPA kommer göra i vad de kallar project tractor är att börja med att maskinöversatta all C och C++ kod m.h.a. av en LLM.

Tänkte först att "det låter helt galet", men efter att testat att översätta ett relativt litet och avgränsat C++ projekt så tror jag det faktiskt kan fungera riktigt bra.

Projektet i fråga i mitt fall var lösningarna på alla 25 dagar av Advent of Code 2018, som jag passade på att skriva och köra på ett RTOS där jag varit med också utvecklat C++11/14/17 standardbiblioteket till. Blev rejält överraskad (osäker om man ska vara positiv för det fantastiska resultatet, eller skrämd över hur bra det var...) hur läsbar och trevlig resultatet var.

C, C++ och Rust har en särställningen bland alla någorlunda populära språk: endast dessa 3 är kompilerade språk, utan GC där "zero-cost abstractions" är en av grundfinesserna.

För många use-case finns självklart även fler alternativ. Och i de lägena andra alternativ faktiskt fungerar ska man nog ställa sig frågan varför man skulle välja något av dessa 3 (ett fullt rationellt svar är: vi kan detta språk redan och är bra på det).

Flera av tech-jättarna, t.ex. Microsoft och Google, använder idag Rust. Faktum är att de har en policy att föredra Rust över C++ där möjligt.

Även om jag använt Rust mer "privat" än i jobbet har jag jobbat (i att: fått betalt för det jag skriver) med Rust hos två olika företag. Rust är på snabb uppgång inom bl.a. embedded.

Både C++ och Rust är väldigt komplexa språk med rätt höga trösklar. Gissar att det är en personlig preferens vilket man tycker är lättast. Har själv ändå långt mer C++ erfarenhet, men skulle ändå hävda att Rust är enklare om man menar "tillräcklig delmängd för att kunna skriva vettig kod".

Och kolla slutkämmen i denna intervju. På frågan "För någon som precis börjar lära sig systemprogrammering, vilket språk skulle du rekommendera som första språk".

Båda svarar Rust. Tänkt då på att Herb Sutter inte är "vem som helst" inom C++ världen, han är ordförande i C++ ISO-kommitté.
Om man bryr sig om säkerhet (eng. safety) överhuvudtaget så är Rust objektivt ett långt bättre val.

Safe-C++ är ett försöka att minska det gapet rejält, men "problemet" med Safe-C++ är att det ser mer ut som Rust med C++ syntax är modern C++. Gissar att just det är vad som får t.ex. Bjarne att vara lite skeptisk mot Safe-C++.

Det är tyvärr den erfarenhet jag också fick av att leta Modbus-bibliotek. Många har bara implementerat en delmängd och det nästan alla startar med är client-TCP, sedan server-TCP och många stannade där.

Det känns som vi haft denna konversationen(att du ogillar Rust) 5 gånger förut...

Det spelar ju inte jättestor roll för en saklig diskussion vad du tycker. Nu vet jag inte om ditt antagande(gällande minnessäkerhet) ens är korrekt eftersom jag själv inte kan C++ men en av de stora fördelarna med C++ är ju mängden färdigskriven kod. Du kommer troligen inkludera kod(exempelvis boost) som inte följer dina guidelines och som troligen kommer introducera sektioner som inte är minnessäkra.

Vad jag har förstått så har Carbon ett syfte av att korrigera vissa problem med C++(inte alla), modernisera syntaxen och att vara välintegrerad med C++. Det känns därför snarare som ett plåster än något nytänkande.

Jag förstår inte heller varför du hela tiden fokuserar så mycket på vikten av att ersätta Rust? Du vet om att flera språk kan samexistera?

Detta har absolut noll relevans för språkdominans. Google brukar pusha hårt för sina saker och är snabba på att överge dem när dem ser att det inte fick följarskaran som de förväntade sig.

Personligen tycker jag att det ser ganska likt ut. Vilken del av Rusts syntax är det som du ogillar?

Din åsikt känns ganska tydlig för min del efter ca 5 trådar med Rust-gnäll.

Det låter inte som något positivt...

Jag iaf tänker på frigöring av minne framförallt efter att jag beslutat om att allokera minne. Tänker du inte i heller på när och vart du allokerar minne då?

Du har väldigt mycket förutfattade meningar om du dömer ut ett projekt baserat på dess projektnamn. Vad jag förstått så är det väldigt amerikanskt att ha akronym för allt möjligt, antagligen för att det lättare ska fastna i samband med presentationer osv.

Min uppfattning är att Rust är populärt framförallt bland yngre utvecklare. Vad är det för gamla saker du syftar på? Vad är det för nya teknologier som involverar svart skärm och tjocka tangentbord?! :S

Visst, alla har rätt till sina egna åsikter men vad baserar du tillfälligheten på? Vet inte om du känner till att Rust är inne på sitt 9:e år och är ett av de mest uppskattade programmeringsspråken enl. Stackoverflows mätning?

Jag jobbar också inom embedded och jag har sett Rust-initiativ inom exempelvis ZephyrOS, safety-relaterade industrier som tåg- och bilindustrin men även kameraövervakning och ARM. Jag har däremot enbart stött på C++ vid enstaka tillfällen och aldrig Java.

Nu kommer du behöva ge exempel. Det går ju att hävda att många språk är inspirerade av C-syntax och därför "hämtade" dom sin syntax från 70-talet, vilket enligt dig, är horribelt.

Så säger en nybörjare. Visst du kan skriva mindre program snabbt och enkelt i Python men det är ju inte snällt för folk som inte känner till indentering och olika typer av whitespace. Det blir också snabbt komplext i Python när ens program växer.

Varför har dom fel?

Personligen skulle varken rekommendera Rust, Python till någon som började programmera utan istället Go. GC-språk som påminner om många andra språk med lekande lätt syntax, bra verktyg, bra dokumentation och mängder med exempelkod som är designat för att vara lätt och lära sig.