Följ Black Week på SweClockers

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

Permalänk

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

Jag behöver ett förslag på ett USB bibliotek som fungerar med C++.
Den måste vara krossplattform och tillförlitlig.

Som jag har hittat just nu är:

  • Boost Asio: C++

  • Libusb: C

Dessa verkar vara populära, men det finns nackdelar med dom.
Boost Asio är svår att använda och har mycket konstig kod. Dokumentationen för Boost Asio är inte heller den bästa.
Boost Asio använder operativsystemets definition på USB portar så som COM3 eller ttyUSB0.

Libusb är enkel att använda, men använder inte operativsystemets definition på USB portar.
Istället använder den "vendor ID", vilket kan uttryckas som 0x324. Dokumentationen är dock väldigt bra på biblioteket.
Välbeprövat bibliotek.

Frågor:

  1. Har jag missuppfattat libusb?

  2. Kan ni ge några exempel?

  3. Finns det något annat bättre bibliotek?

Permalänk
Medlem

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

Permalänk
Skrivet av dlq84:

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

Så libusb kan lösa mitt problem?
Alltså, identifiera portar, ansluta, skriva, läsa?

Permalänk
Hedersmedlem
Skrivet av heretic16:

Så libusb kan lösa mitt problem?
Alltså, identifiera portar, ansluta, skriva, läsa?

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).

Permalänk
Medlem

Du får förklara djupare vad du vill göra, det verkar tyvärr som du har blandat ihop några grundläggande koncept.

Permalänk
Datavetare
Skrivet av heretic16:

Frågor:

  1. Har jag missuppfattat libusb?

  2. Kan ni ge några exempel?

  3. Finns det något annat bättre bibliotek?

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++?

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Skrivet av Elgot:

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).

Skrivet av Cray:

Du får förklara djupare vad du vill göra, det verkar tyvärr som du har blandat ihop några grundläggande koncept.

Jag vill bara hantera serieportar. Alltså kunna läsa och skriva. Inget mer.

Skrivet av Yoshman:

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++?

Jag implementerade boost:asio. Det fungerar utmärkt!
Jag tror att jag ska lära mig mera hur jag använder Boost bibioteken. Dom verkar väldigt påkostade.

Permalänk
Hedersmedlem
Skrivet av heretic16:

Jag tror att jag ska lära mig mera hur jag använder Boost bibioteken. Dom verkar väldigt påkostade.

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

Permalänk
Skrivet av Elgot:

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

Sista uppdateringen gjordes för 2 år sedan. Knappast aktivt projekt.

Permalänk
Hedersmedlem
Skrivet av heretic16:

Sista uppdateringen gjordes för 2 år sedan. Knappast aktivt projekt.

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)

Permalänk
Skrivet av Elgot:

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)

Testade Boost Asio med C++ för att skriva till USB. Det fungerar. Jag tror det inte finns några andra bibliotek helt enkelt som uppfyller samma behov som jag kräver.

Undra om det finns annat roligt i Boost? Typ Modbus, eller är man tvingen att använda C biblioteket libmodbus?

Permalänk
Medlem
Skrivet av heretic16:

Sista uppdateringen gjordes för 2 år sedan. Knappast aktivt projekt.

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.)

Permalänk
Hedersmedlem
Skrivet av heretic16:

Testade Boost Asio med C++ för att skriva till USB. Det fungerar. Jag tror det inte finns några andra bibliotek helt enkelt som uppfyller samma behov som jag kräver.

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.

Permalänk
Datavetare
Skrivet av heretic16:

Sista uppdateringen gjordes för 2 år sedan. Knappast aktivt projekt.

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

Skrivet av heretic16:

Testade Boost Asio med C++ för att skriva till USB. Det fungerar. Jag tror det inte finns några andra bibliotek helt enkelt som uppfyller samma behov som jag kräver.

Undra om det finns annat roligt i Boost? Typ Modbus, eller är man tvingen att använda C biblioteket libmodbus?

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

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Skrivet av Yoshman:

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

Jag känner att jag har stora anledningar att hålla mig kvar vid C++.
Orsaken har med att C++ utvecklas och ökar allt mer i popularitet med följd av Python. Troligtvis så är det spel och AI-trenden, som lyfter upp C++. Jag känner inte att jag har behov utav "super minnessäkerhet" i C++. Det enda jag vill ha är snabb kompileringstid och körtid.

Dessutom ogillar jag denna turnering kring vilket språk som "klår C++". Jag menar vi har alltid hört talas som "Java, the new C++ killer", "D, the new C++ killer", "Go, the new C++ killer", "Rust, the new C++ killer", "Zig, the new C++ killer", eller "Carbon, the new C++ killer". Är C++ så hemskt att folk vill verkligen utmana det? Hur många år har detta pågått? 30 som jag kan minnas.

Lite komiskt är att även Rust utmanas av Zig och Carbon nu Tror inte Rust överlever om man ska lyssna på hippsters

Något som jag skulle ha behov utav är ett modbus-bibliotek, som fungerar med Boost Asio. Alltså ett gränssnitt för Modbus som talar med Boost Asio. Detta vore inte helt fel. Annars måste jag ha Boost Asio + libmodbus. Blir krångligt. Modbus är ju ett jätte enkelt protokoll.

Permalänk
Datavetare
Skrivet av heretic16:

Jag känner att jag har stora anledningar att hålla mig kvar vid C++.
Orsaken har med att C++ utvecklas och ökar allt mer i popularitet med följd av Python. Troligtvis så är det spel och AI-trenden, som lyfter upp C++. Jag känner inte att jag har behov utav "super minnessäkerhet" i C++. Det enda jag vill ha är snabb kompileringstid och körtid.

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.

Skrivet av heretic16:

Dessutom ogillar jag denna turnering kring vilket språk som "klår C++". Jag menar vi har alltid hört talas som "Java, the new C++ killer", "D, the new C++ killer", "Go, the new C++ killer", "Rust, the new C++ killer", "Zig, the new C++ killer", eller "Carbon, the new C++ killer". Är C++ så hemskt att folk vill verkligen utmana det? Hur många år har detta pågått? 30 som jag kan minnas.

Lite komiskt är att även Rust utmanas av Zig och Carbon nu Tror inte Rust överlever om man ska lyssna på hippsters

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.

Skrivet av heretic16:

Något som jag skulle ha behov utav är ett modbus-bibliotek, som fungerar med Boost Asio. Alltså ett gränssnitt för Modbus som talar med Boost Asio. Detta vore inte helt fel. Annars måste jag ha Boost Asio + libmodbus. Blir krångligt. Modbus är ju ett jätte enkelt protokoll.

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.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Skrivet av Yoshman:

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.

Jag tror däremot Rust kommer inte vara lika populärt i framtiden som det är idag.
Orsaken har med att Rust har för många konkurrenter - Zig och Carbon. Kanske det kommer ett nytt hippespråk som lovar guld och gröna skogar?

Carbon tror jag faktiskt på. Språket stöds av Google! Nej, jag kommer inte lära mig Carbon. C++ är ett 10 års projekt.

Citat:

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.

Vänta bara tills Carbon lanseras. Då kommer Rust tolkas som "omodernt" och "krånglig" av ny generation av programmerare.
Jag har varit med svängarna och det finns alltid en skara utvecklare som ständigt jagar efter senaste och nyaste språket att lära sig. Sedan finns det gamla rävar som jag som kör C och C++ vid behov.

Citat:

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...).

Du menar att man kan enkelt skriva om C och C++ till Rust? Till vilken läsbar kvalité då? Vad händer om det blir fel så det måste bli manuell handpåläggning för att koden skall kunna kompileras i Rust?

Citat:

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.

Java är fint. Mysigt språk där allt bara fungerar. Synd att man måste ha JRE installerat.

Citat:

Språket D är ju ett exempel på en lång rad språk som aldrig fått någon större popularitet. Haraldrig 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.

D togs fram för att den skulle ersätta C++. Så gjorde man med Java också. Utvecklarna bakom Java skrev att målet var ett "bättre C++", utan massa krångel. Men man fick lägga språket på en väldigt hög nivå för att lyckas.

Citat:

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++.

Jag tror inte på Zig. Låter som ett hippiespråk från en ung generation i USA. Språket dör bort när Carbon lanseras.

Citat:

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...

Finns på deras GitHub så skriver Carbon att denna ska ersätta C++.

Citat:

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å.

Rust är inte bara den enda "C++ dödare". Det finns många språk som jag nämnde. Men problemet är att det är svårt att ersätta C++ om det är ett ständigt utvecklande språk och är idag, enligt min mening, väldigt säkert att programmera i.

Här är ett ytterligare nytt språk.....som ska konkurrera mot Rust. Men åter igen, det skapas massvis med språk som ska ersätta andra språk. Val är säkert ett dåligt språk dessutom. De flesta språk idag är dåliga.
https://www.youtube.com/watch?v=xLouek82-5g

Citat:

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).

Aldrig sett Rust på arbetsmarknaden. Det enda jag har sett Rust finnas är på hobbyprojekt på GitHub. Arbetsmarknaden är ofta C#, C++, Java, PHP, Python, JavaScript. Ja...sedan var listan slut.

Citat:

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.

Rust är svårare än C++. Tro mig.
Hade Rust varit smart så hade dom kopierat 100% av C++ syntaxen, men bara kallat den för Rust och implementera sin minnessäkerhet. Klart! Inga problem. Folk hade inte märkt någon skillnad.

Citat:

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.

Just ja. Dessa är Modbus TCP. Behöver RTU
Men skadar inte att man skriver eget Modbus. Finns ju något bibliotek man kan sno och skriva om.

Permalänk
Datavetare
Skrivet av heretic16:

Jag tror däremot Rust kommer inte vara lika populärt i framtiden som det är idag.
Orsaken har med att Rust har för många konkurrenter - Zig och Carbon. Kanske det kommer ett nytt hippespråk som lovar guld och gröna skogar?

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).

Skrivet av heretic16:

Carbon tror jag faktiskt på. Språket stöds av Google! Nej, jag kommer inte lära mig Carbon. C++ är ett 10 års projekt.

Vänta bara tills Carbon lanseras. Då kommer Rust tolkas som "omodernt" och "krånglig" av ny generation av programmerare.
Jag har varit med svängarna och det finns alltid en skara utvecklare som ständigt jagar efter senaste och nyaste språket att lära sig. Sedan finns det gamla rävar som jag som kör C och C++ vid behov.

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.

Skrivet av heretic16:

Du menar att man kan enkelt skriva om C och C++ till Rust? Till vilken läsbar kvalité då? Vad händer om det blir fel så det måste bli manuell handpåläggning för att koden skall kunna kompileras i Rust?

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.

Skrivet av heretic16:

Rust är inte bara den enda "C++ dödare". Det finns många språk som jag nämnde. Men problemet är att det är svårt att ersätta C++ om det är ett ständigt utvecklande språk och är idag, enligt min mening, väldigt säkert att programmera i.

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).

Skrivet av heretic16:

Aldrig sett Rust på arbetsmarknaden. Det enda jag har sett Rust finnas är på hobbyprojekt på GitHub. Arbetsmarknaden är ofta C#, C++, Java, PHP, Python, JavaScript. Ja...sedan var listan slut.

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.

Skrivet av heretic16:

Rust är svårare än C++. Tro mig.
Hade Rust varit smart så hade dom kopierat 100% av C++ syntaxen, men bara kallat den för Rust och implementera sin minnessäkerhet. Klart! Inga problem. Folk hade inte märkt någon skillnad.

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++.

Skrivet av heretic16:

Just ja. Dessa är Modbus TCP. Behöver RTU
Men skadar inte att man skriver eget Modbus. Finns ju något bibliotek man kan sno och skriva om.

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.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Skrivet av Yoshman:

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).

Idag tycker jag att om man använder vektorer och smarta pekare, så gör man språket minnessäkert.

Citat:

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.

Jag tror hellre Carbon kommer ersätta Rust. Google har betydligt större ekonomiska muskler än vad Mozilla har.
Jag tycker Carbon har renare syntax än Rust. Syntaxen från Rust är rent av hemsk. Hur tänkte utvecklare där? Kanske inte.
Men som sagt så kommer jag hålla mig kvar vid C++ för att jag litar på att utvecklarna av C++ kommer hitta på ett sätt som gör C++ helt oslagbart. Det är redan oslagbart idag också.

Idag tycker jag C++ är så enormt högnivå att det liknar Java. Jag tänker aldrig på frigöra minnet längre. Jag använder bara vektorer och smarta pekare. Sedan tänker jag inget mer på dom.

Citat:

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.

Detta låter galet. Litar inte på dom för 5 öre. Bara namnet "tractor" låter oseriöst. Vad är dom? 8 år i sinnet?

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.

Citat:

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.

Microsoft har sagt att dom ska använda Rust för varje nytt projekt som ej använder GC.
Men detta kommer dom få äta upp. Hela programmeringsvärlden bygger på en ung generation som leder utvecklingen. Denna typ av unga generation vill aldrig ens hålla på med gamla saker, utan bara nya teknologier med svart skärm och tjockt tangentbord.

Men som sagt, Rust är bara tillfälligt. Googles Carbon är nog framtiden. Om inte Microsoft hittar på något nytt och tvingar arbetsmarknaden att följa språket.

Citat:

Ä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.

Jobbar med embedded, aldrig sett Rust och kommer aldrig se det heller. Det är bara C som gäller, eller något mystiskt språk så som pascal. I vissa fall kan det vara C++, men då ska det vara dyra system också. En gång fick jag koda i Java SE. Det var skönt. Superenkelt. Det var för IoT.

Citat:

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".

Jag tycker inte C++ har höga trösklar. Faktiskt så kör jag C liknande C++, där jag använder klasser vid behov. Men vektorer använder jag alltid i C++. Men annars så är det vanlig C programmering. Problemet med Rust är att språket har hämtat sin syntax från döende språk från 60-70-talet. Helt horribelt hur man kunde tänka så.

Nybörjarspråk: Python, helt klart. Där behöver man aldrig tänka.

Citat:

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.

Dom har helt fel. Att Rust ska vara bästa språket för nybörjade att lära sig. Beror på om man vill ha det svårt från början.
Egentligen föredrar jag Python för nybörjare. Där efter kan man gå till C och bygga sin kunskap mot C++ och högre nivå så som Java och C#.

Citat:

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++.

Jag har inget emot att man tvingar C++ programmerare att använda senaste standarden som visar vägen till kod där...ja, vad det nu heter, tar över minneshanteringen. Smarta pekare är helt enkelt guld i C++.

Citat:

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.

Jag skriver eget bibliotek för Modbus i C++ som använder Boost Asio Enklast så.

Permalänk
Medlem

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

Skrivet av heretic16:

Idag tycker jag att om man använder vektorer och smarta pekare, så gör man språket minnessäkert.

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.

Skrivet av heretic16:

Jag tror hellre Carbon kommer ersätta Rust.

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?

Skrivet av heretic16:

Google har betydligt större ekonomiska muskler än vad Mozilla har.

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.

Skrivet av heretic16:

Jag tycker Carbon har renare syntax än Rust. Syntaxen från Rust är rent av hemsk. Hur tänkte utvecklare där?

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

Skrivet av heretic16:

Men som sagt så kommer jag hålla mig kvar vid C++ för att jag litar på att utvecklarna av C++ kommer hitta på ett sätt som gör C++ helt oslagbart. Det är redan oslagbart idag också.

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

Skrivet av heretic16:

Idag tycker jag C++ är så enormt högnivå att det liknar Java.

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

Skrivet av heretic16:

Jag tänker aldrig på frigöra minnet längre.

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å?

Skrivet av heretic16:

Detta låter galet. Litar inte på dom för 5 öre. Bara namnet "tractor" låter oseriöst. Vad är dom? 8 år i sinnet?

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.

Skrivet av heretic16:

Microsoft har sagt att dom ska använda Rust för varje nytt projekt som ej använder GC.
Men detta kommer dom få äta upp. Hela programmeringsvärlden bygger på en ung generation som leder utvecklingen. Denna typ av unga generation vill aldrig ens hålla på med gamla saker, utan bara nya teknologier med svart skärm och tjockt tangentbord.

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

Skrivet av heretic16:

Men som sagt, Rust är bara tillfälligt. Googles Carbon är nog framtiden. Om inte Microsoft hittar på något nytt och tvingar arbetsmarknaden att följa språket.

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?

Skrivet av heretic16:

Jobbar med embedded, aldrig sett Rust och kommer aldrig se det heller. Det är bara C som gäller, eller något mystiskt språk så som pascal. I vissa fall kan det vara C++, men då ska det vara dyra system också. En gång fick jag koda i Java SE. Det var skönt. Superenkelt. Det var för IoT.

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.

Skrivet av heretic16:

Problemet med Rust är att språket har hämtat sin syntax från döende språk från 60-70-talet. Helt horribelt hur man kunde tänka så.

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.

Skrivet av heretic16:

Nybörjarspråk: Python, helt klart. Där behöver man aldrig tänka.

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.

Skrivet av heretic16:

Dom har helt fel. Att Rust ska vara bästa språket för nybörjade att lära sig. Beror på om man vill ha det svårt från början.
Egentligen föredrar jag Python för nybörjare. Där efter kan man gå till C och bygga sin kunskap mot C++ och högre nivå så som Java och C#.

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.

Permalänk
Datavetare
Skrivet av heretic16:

Jobbar med embedded, aldrig sett Rust och kommer aldrig se det heller. Det är bara C som gäller, eller något mystiskt språk så som pascal. I vissa fall kan det vara C++, men då ska det vara dyra system också. En gång fick jag koda i Java SE. Det var skönt. Superenkelt. Det var för IoT.

Du jobbar väl en del med STM?

Det är sant att långt från alla MCU-tillverkare idag har Rust stöd, ser bl.a. att Renesas saknar det (folk frågar efter det på deras forum och svaret är "for now får ni göra wrappers mot våra C-bibliotek").

STM har idag stöd för de flesta av deras mest populära plattformar. Expressif (jättestora på IoT) har väldigt bra Rust-stöd för deras RISC-V baserade MCUer (d.v.s. alla nya modeller).

Skrivet av heretic16:

Jag tycker inte C++ har höga trösklar. Faktiskt så kör jag C liknande C++, där jag använder klasser vid behov. Men vektorer använder jag alltid i C++. Men annars så är det vanlig C programmering. Problemet med Rust är att språket har hämtat sin syntax från döende språk från 60-70-talet. Helt horribelt hur man kunde tänka så.

Jämför dessa två. Och vad jag gjort här var att leta efter ett exempel på idiomatisk användning av C++ ranges. Sa sedan åt ChatGPT att göra en Rust-version, idiomatisk så OK att ersätta for-loopar (betalar för tjänsten, så körde med o1-preview modellen)

Svårt att se hur någon kan tycka C++ är lättare att läsa här, det är "OK" medan Rust-versionen är "uppenbar". Och var ChatGPT som optimerade is_prime i Rust (den är snabbare än C++ varianten från exemplet jag hittade)

Klicka för mer information

#include <iostream> #include <ranges> bool isPrime(int i) { for (int j=2; j*j <= i; ++j){ if (i % j == 0) return false; } return true; } int main() { // (1) std::cout << "Numbers from 1000000 to 1001000 (dispayed each 100th): " << std::endl; for (int i: std::views::iota(1000000, 1001000)) { if (i % 100 == 0) std::cout << i << " "; } std::cout << "\n\n"; // (2) auto odd = [](int i){ return i % 2 == 1; }; std::cout << "Odd numbers from 1000000 to 1001000 (displayed each 100th): " << std::endl; for (int i: std::views::iota(1000000, 1001000) | std::views::filter(odd)) { if (i % 100 == 1) std::cout << i << " "; } std::cout << "\n\n"; // (3) std::cout << "Prime numbers from 1000000 to 1001000: " << std::endl; for (int i: std::views::iota(1000000, 1001000) | std::views::filter(odd) | std::views::filter(isPrime)) { std::cout << i << " "; } std::cout << "\n\n"; // (4) std::cout << "20 prime numbers starting with 1000000: " << std::endl; for (int i: std::views::iota(1000000) | std::views::filter(odd) | std::views::filter(isPrime) | std::views::take(20)) { std::cout << i << " "; } }

fn is_prime(n: &i32) -> bool { if *n < 2 { return false; } (2..=((*n as f64).sqrt() as i32)).all(|i| n % i != 0) } // Normal function to check if a number is odd fn is_odd(n: &i32) -> bool { n % 2 == 1 } fn main() { // (1) println!("Numbers from 1,000,000 to 1,001,000 (displayed every 100th):"); (1_000_000..1_001_000) .filter(|&n| n % 100 == 0) .for_each(|n| print!("{} ", n)); println!("\n"); // (2) println!("Odd numbers from 1,000,000 to 1,001,000 (displayed every 100th):"); (1_000_000..1_001_000) .filter(is_odd) .filter(|&n| n % 100 == 1) .for_each(|n| print!("{} ", n)); println!("\n"); // (3) println!("Prime numbers from 1,000,000 to 1,001,000:"); (1_000_000..1_001_000) .filter(is_odd) .filter(is_prime) .for_each(|n| print!("{} ", n)); println!("\n"); // (4) println!("20 prime numbers starting with 1,000,000:"); (1_000_000..) .filter(is_odd) .filter(is_prime) .take(20) .for_each(|n| print!("{} ", n)); println!(); }

Visa mer
Skrivet av orp:

Det känns som vi haft denna konversationen 5 gånger förut och jag hoppas polletten trillar ner snart.

Repetition är inlärningens moder

Skrivet av orp:

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.

Söker man på YT på "vanligaste buggen hos Facebook", de har väldigt mycket C++ i deras backend, så hittar man på plats 1. "out of bounds indexing of std::vector"... För även i "modern" C++ checkas inte sådant om man använder index-operatorn.

Rust, Go, C#, Java, etc gör alla en check där. Sättet Rust vector fungerar och typiskt används betyder att man kan göra check:en "up-front" och därför blir det ändå lika snabbt som i C++.

Skrivet av orp:

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.

I presentationen säger man just det: alla DARPA-projekt har ett namn.

Skrivet av orp:

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

Ajdå, jag är ju rätt gammal och gillar Rust (även om jag föredrar Go, men finns ställen där det inte fungerar...).

Skrivet av orp:

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.

För att ge lite mer kontext här. Inte så att de sa: Rust eller C++ är super för nybörjare.
De kom från "det är synd att datorvetenskap på universitetsnivå allt mer bara använder Python, Java etc. Man borde ha kommit i kontakt med ett "systems-programming language" i en sådan utbildning och för det är nog Rust idag ett bättre val".

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer