C# vs QML om man ska bygga enkla applikationer?

Permalänk

C# vs QML om man ska bygga enkla applikationer?

Igenom åren har jag testat på följande:

- Visual Basic.NET: Detta tycker jag var helt OK. Lite konstigt sätt att deklarera variabler osv. Klammer fanns dock inte. Men annars bra! Synd att Microsoft inte lade så mycket effekt på språket på den tiden då man körde Visual Basic.NET Express Edition 2.0. Idag är väll Visual Basic.NET på uppgång...?
- Visual C#.NET: Detta tycker jag var exakt samma sak som Visual Basic.NET. Men det var mer likt Java. Bra språk. Jag gillar den gröna nyansen.
- Visual C++.NET: Detta gillade jag inte, för det var svårt och dessutom inte riktiga C++, utan det var C++/CLI. Typ någon egen version av C++.
- Vaadin + Springboot + Java: Detta gillar jag absolut starkt. Jag har gjort detta i Java och det var superenkelt att spotta upp en webbapplikation på nolltid. Det var snabbt, stabilt och enkelt. Nackdelen var att man blir låst till just Vaadins ramverk. Man har lite möjligheter att påverka och göra lite som man vill. Men det gick snabbt och smidigt om man använde deras standardverktyg, vilket jag var bara intresserad utav.
- QT C++: Jag gillar detta, men ändå inte. Jag tycker att utvecklingsverktyget är fantastiskt. Robust, stabilt och snabbt. Men nackdelen var att göra en applikation i C++....kräver många timmar. Man måste ta hänsyn till allt och helt plötsligt så fanns det ett mystiskt fel som kompilatorn ej kände utav. Jag fick skriva mycket kod. Jag känner att jag slet mer och gruvar mig att gå tillbaka till gamla QT C++ projekt
- JavaFX: Detta gillar jag också då det var enkelt att bygga en applikation med Java + SceneBuilder. Tyvärr så är JavaFX mer för hobby-folk, så det är inte värt att lägga ned sin tid på JavaFX. Dessutom dödade Oracle just Java GUI av någon mystisk anledning. Java var mitt första språk av just anledningen Java Swing. Fantastiskt fint. Bästa som har hänt. Älskar retro. En nackdel med Java är att Java är mycket "öppen källkod", vilket låter utvecklarna förlita sig på "gratis programmerare" ute på GitHub. Ibland kan det vara bra, men det kan skapa mycket buggar också.

Den enda gången jag har programmerat utan att klaga är programmering C. Jag har oftast gjort underbibliotek av just snabbhetens skull. C har alltid fungerat och med detta språk gör man egentligen inte så mycket fel, då det inte finns så många alternativ att lösa problemet på, vilket jag tycker är bra.

Jag söker ett liknande verktyg, som är industriellt och kommer vara kvar hos mig i flera år, utan att jag känner att jag måste lära mig något nytt hela tiden. Jag tänker först och främst på språk så som Python som alltid ska vara modernt och alltid ligga i framkanten. Sådan är inte jag. Jag älskar just C-syntaxen. Enkelt och ren.

Så mitt intresse nu är om man ska testa C# eller QML. För med C# så kan man anropa C kod och jämfört med C# VS C++ så skriver man mindre kod med C#. Men samtidigt gillar jag just QTs produkter för att dom är stabila och verkligen industriella.

Mina krav är följande:
- Man ska skriva lite kod för att få något gjort
- Man ska kunna anropa C kod från externa filer
- Utvecklingsverktyget ska vara industriellt
- Trådar ska vara enkla att hantera utan att man måste skapa massa onödig kod
- Utvecklingsverktyget bör ha en grafisk designer, något som Visual Studio och QT Designer har. Starkt uppskattat
- Man ska ha stöd för hårdvara t.ex. USB port och HTTP
- Viktigt med API:er t.ex. Yahoo Stocks.
- Grafer & GUI är ett måste för mig

Jag bryr mig inte om snabbheten här.

Så jag har funderat att om man ska använda C# eller om man ska använda QML.
Men jag vet inte vilken .NET jag ska använda. Om jag ska använda .NET 6, .NET Core eller Maui. QML känner jag mig också intresserad på, men jag är lite skeptisk där också...QML är väll JavaScript?

Permalänk
Medlem
Skrivet av heretic16:

Men jag vet inte vilken .NET jag ska använda. Om jag ska använda .NET 6, .NET Core eller Maui.

Det var väldigt många frågor där. Men detta kan jag svara på i alla fall.

.NET (och .Net Core) är en runtime samt bibliotek för I/O, Http, LINQ och mycket annat. .NET 6 är det som gäller då .Net Core inte utvecklas längre, sista versionen är 3.1. Du ska absolut köra .NET 6 eller senare, det finns stora prestandavinster och .NET utecklas numera tilsammans med C# där nya versioner av båda släpps i November varje år. I November i år släpps .NET 7 och C# 11. Du kommer inte kunna utnyttja vissa features i nyare C# om du inte också har motsvarande eller senare .NET.

.NET Maui är ett komponentbibliotek för utveckling av GUI applikaitoner på Windows, Android, iOS och MacOS. Det är efterföljaren till Xamarin med stöd även för desktop. Precis som Xamarin och WPF så används XAML, ett XML-baserat språk, för att beskriva komponenter, styling och animationer. Det finns bra tooling till detta inklusive hot reload. .NET Maui kräver .NET, det går inte att köra på andra plattformar.

Tycker du målar upp dig själv som ganska konservativ som gillar enkelhet och stabilitet. Inget fel med det. Men jag skulle säga att .NET/C# har blivit en väldigt rörlig plattform där man jobbar väldigt hårt med att förnya språket med saker såsom t.ex. pattern matching och shorthands för en massa saker. Man tar inspiration från F#, Node.js och andra. Det går knappt att känna igen sig om man jämför kod jag skrivit för 5+ år sen, mot kod som skrivs idag. Bara ett heads up, det kan vara kul, men det kräver att man är villig att hänga med.

Visa signatur

Louqe Ghost S1 MK3 | Asus ROG Strix B660-I Gaming WiFi | Intel Core i7 12700K | nVidia RTX 2070 Super FE | Corsair 64GB (2x32GB) DDR5 5600MHz CL40 Vengeance | Samsung 980 PRO M.2 NVMe SSD 2TB | Corsair SF750 750W 80+ Platinum | Noctua NH-L12 Ghost S1 edition | Kablar från pslate customs | 2 stk Dell Ultrasharp 3014 | Logitech MX Keys | Logitech MX Anywhere

Permalänk
Skrivet av sunefred:

Det var väldigt många frågor där. Men detta kan jag svara på i alla fall.

.NET (och .Net Core) är en runtime samt bibliotek för I/O, Http, LINQ och mycket annat. .NET 6 är det som gäller då .Net Core inte utvecklas längre, sista versionen är 3.1. Du ska absolut köra .NET 6 eller senare, det finns stora prestandavinster och .NET utecklas numera tilsammans med C# där nya versioner av båda släpps i November varje år. I November i år släpps .NET 7 och C# 11. Du kommer inte kunna utnyttja vissa features i nyare C# om du inte också har motsvarande eller senare .NET.

.NET Maui är ett komponentbibliotek för utveckling av GUI applikaitoner på Windows, Android, iOS och MacOS. Det är efterföljaren till Xamarin och med stöd även för desktop. Precis som Xamarin och WPF så använder det XAML, ett XML-baserat språk för att beskriva komponenter, styling och animationer. Det finns bra tooling till detta inklusive hot reload.

Tycker du målar upp dig själv som ganska konservativ som gillar enkelhet och stabilitet. Inget fel med det. Men jag skulle säga att .NET/C# har blivit en väldigt rörlig plattform där man jobbar väldigt hårt med att förnya språket med saker såsom t.ex. pattern matching och shorthands för en massa saker. Man tar inspiration från F#, Node.js och andra. Det går knappt att känna igen sig om man jämför kod jag skrivit för 5+ år sen, mot kod som skrivs idag. Bara ett heads up, det kan vara kul, men det kräver att man är villig att hänga med.

Ja. Jag har också lutat mig mot C#.
C# känns som att vara ett konkurrerande språk mot Java och C# känns vara ett språk som kommer hänga med väldigt länge då den stöds av Microsoft.

Följer det med så man kan använda grafisk designer när man använder Visual Studio? Sådant tycker jag är smidigt.

Ja, jag är riktigt konservativ när det kommer till språk. Ibland tycker jag framtiden krånglar till det lite, istället för att hålla det minimalt.

Permalänk
Medlem
Skrivet av heretic16:

Följer det med så man kan använda grafisk designer när man använder Visual Studio? Sådant tycker jag är smidigt.

Ja det finns. Jag tycker att det går snabbare i kod dock än att navigera och klicka på saker, men det är en smaksak och spelar ingen roll, du kan växla mellan båda fritt. Viktigare än en editor är det att det finns tooling för felsökning såsom att kunna se det visuell trädet live och se effektiv styling (styling ärvs precis som i CSS). Och det finns det! Toolingen i det avseendet liknar det som finns i Chrome/Edge/Firefox när det gäller web-utveckling.

Visa signatur

Louqe Ghost S1 MK3 | Asus ROG Strix B660-I Gaming WiFi | Intel Core i7 12700K | nVidia RTX 2070 Super FE | Corsair 64GB (2x32GB) DDR5 5600MHz CL40 Vengeance | Samsung 980 PRO M.2 NVMe SSD 2TB | Corsair SF750 750W 80+ Platinum | Noctua NH-L12 Ghost S1 edition | Kablar från pslate customs | 2 stk Dell Ultrasharp 3014 | Logitech MX Keys | Logitech MX Anywhere

Permalänk
Skrivet av sunefred:

Ja det finns. Jag tycker att det går snabbare i kod dock än att navigera och klicka på saker, men det är en smaksak och spelar ingen roll, du kan växla mellan båda fritt. Viktigare än en editor är det att det finns tooling för felsökning såsom att kunna se det visuell trädet live och se effektiv styling (styling ärvs precis som i CSS). Och det finns det! Toolingen i det avseendet liknar det som finns i Chrome/Edge/Firefox när det gäller web-utveckling.

Hur ser du på QML då?
Är det någon framtid?

Permalänk
Medlem
Skrivet av heretic16:

Hur ser du på QML då?
Är det någon framtid?

Jag vet inte nog om det. Får passa vidare den bollen till nästa SWEC-are

Visa signatur

Louqe Ghost S1 MK3 | Asus ROG Strix B660-I Gaming WiFi | Intel Core i7 12700K | nVidia RTX 2070 Super FE | Corsair 64GB (2x32GB) DDR5 5600MHz CL40 Vengeance | Samsung 980 PRO M.2 NVMe SSD 2TB | Corsair SF750 750W 80+ Platinum | Noctua NH-L12 Ghost S1 edition | Kablar från pslate customs | 2 stk Dell Ultrasharp 3014 | Logitech MX Keys | Logitech MX Anywhere

Permalänk
Skrivet av sunefred:

Jag vet inte nog om det. Får passa vidare den bollen till nästa SWEC-are

Visst är det Visual Studio man ska ha. Eller är det Visual Studio Code man ska använda sig utav?
Jag är en sådan som föredrar stora IDE verktyg så som Eclipse.

Permalänk
Medlem
Skrivet av sunefred:

Ja det finns.

Om det finns grafiskt UI-verktyg eller inte för Visual Studio beror väl på? Jag orkar inte testa just nu, men såvitt jag vet finns det för Windows Forms och WPF men inte för MAUI/WinUI3. Microsoft hänvisar till hot reload, vilket de får välförtjänt skit för.

Permalänk
Medlem
Skrivet av KAD:

Om det finns grafiskt UI-verktyg eller inte för Visual Studio beror väl på? Jag orkar inte testa just nu, men såvitt jag vet finns det för Windows Forms och WPF men inte för MAUI/WinUI3. Microsoft hänvisar till hot reload, vilket de får välförtjänt skit för.

Ok! I stand corrected! Jag lutade mig på mitt WPF kunnande där och med att båda är XAML-dialekter. Då kanske toolingen saknas också?

Visa signatur

Louqe Ghost S1 MK3 | Asus ROG Strix B660-I Gaming WiFi | Intel Core i7 12700K | nVidia RTX 2070 Super FE | Corsair 64GB (2x32GB) DDR5 5600MHz CL40 Vengeance | Samsung 980 PRO M.2 NVMe SSD 2TB | Corsair SF750 750W 80+ Platinum | Noctua NH-L12 Ghost S1 edition | Kablar från pslate customs | 2 stk Dell Ultrasharp 3014 | Logitech MX Keys | Logitech MX Anywhere

Permalänk
Skrivet av sunefred:

Ok! I stand corrected! Jag lutade mig på mitt WPF kunnande där och med att båda är XAML-dialekter. Då kanske toolingen saknas också?

Men är inte WPF rätt omodernt och utgående?

Permalänk
Medlem
Skrivet av heretic16:

Visst är det Visual Studio man ska ha. Eller är det Visual Studio Code man ska använda sig utav?
Jag är en sådan som föredrar stora IDE verktyg så som Eclipse.

Visual Studio är ett IDE (Itegrated Development Environment) och är en riktig Juggernaut. Vissa svär vid VS och skulle aldrig använda något annat.

Raider är ett annat IDE, som jag tycker du ska testa. Vissa svär vid Raider och skulle aldrig använda något annat.

VSCode är en editor, men med alla extensions som finns så kommer du väldigt nära upplevelsen av ett IDE. Vissa svär vid VSCode och skulle aldrig använda något annat.

Lärdomen här är, när det gäller editors ska du inte lyssna på någon annan än dig själv. VSCode är gratis, det finns community edition av VS och trial av Raider. Testa! När du testar VSCode dock, hitta en Youtube video med rekommenderade extensions för C# (eller QML) innan du dömer.

Personligen använder jag både VS och VSCode på daglig basis.

Visa signatur

Louqe Ghost S1 MK3 | Asus ROG Strix B660-I Gaming WiFi | Intel Core i7 12700K | nVidia RTX 2070 Super FE | Corsair 64GB (2x32GB) DDR5 5600MHz CL40 Vengeance | Samsung 980 PRO M.2 NVMe SSD 2TB | Corsair SF750 750W 80+ Platinum | Noctua NH-L12 Ghost S1 edition | Kablar från pslate customs | 2 stk Dell Ultrasharp 3014 | Logitech MX Keys | Logitech MX Anywhere

Permalänk
Medlem
Skrivet av heretic16:

Men är inte WPF rätt omodernt och utgående?

Det kommer leva kvar i och med att det finns så mycket byggt med det och WPF fortsätter uppdateras för att hänga med och kunna köras på nyare .NET versioner. Men fokus är nog på Maui.

Man kan ju spekulera varför det inte finns tooling för Maui/WinUI än och om det ens kommer finnas. Jag brukar joina deras "standups" på dotNET YouTube kanal och ställa dumma frågor. Det här är kanske en fråga, som inte ens är så dum, som är värt att ställa där när de har Maui-tema. Nästa gång är 9 Augusti.

Visa signatur

Louqe Ghost S1 MK3 | Asus ROG Strix B660-I Gaming WiFi | Intel Core i7 12700K | nVidia RTX 2070 Super FE | Corsair 64GB (2x32GB) DDR5 5600MHz CL40 Vengeance | Samsung 980 PRO M.2 NVMe SSD 2TB | Corsair SF750 750W 80+ Platinum | Noctua NH-L12 Ghost S1 edition | Kablar från pslate customs | 2 stk Dell Ultrasharp 3014 | Logitech MX Keys | Logitech MX Anywhere

Permalänk

Jag låter dom som är QML frälst få svara i tråden också
Vad finns det för fördelar med QML jämfört med C# för Visual Studio?

Edit:
Jag skulle vilja beskriva vad jag har tyckt är underbart.

- Spring Boot
- C

Spring Boot har dependency injection. Jag klarar mig inte utan detta. I Spring Boot använder man @AutoWire och allt bara fungerar.
Inge mer manuellt konfigurera massa klasser mot varandra för att få den önskade hierarkin.

Men..jag väntar på QML-gurun...

Permalänk

Hej!

Nu har jag bestämt mig. Jag väljer QML av just anledningen att den har QT Designer för QML.

Kan någon hjälpa mig?
Jag har installerat QT och valt Desktop.
Jag kan välja QT Quick. Men sedan då?

Edit:

Varför fungera inte SwipeView?

import QtQuick import QtQuick.Controls 6.3 import QtQuick.Layouts 6.3 import QtQuick.Controls.Windows 6.0 Window { id: window visible: true title: qsTr("Hello World") SwipeView { id: swipeView Rectangle { id: rectangle color: "#276f35" } Rectangle { id: rectangle1 color: "#221b97" } Rectangle { id: rectangle2 color: "#a91654" } } }

Edit 2:

Ok! Nu har jag fått igång det. Det var storlekarna som jag hade missat.
Blir inte storlekarna automatiska om man ej sätter dom? QML är ju JavaScript, så det lär ju finnas många hippsters på detta forum som kan svara på denna fråga?

import QtQuick import QtQuick.Controls 6.3 Window { id: window width: 640 height: 480 visible: true title: qsTr("Hello World") SwipeView { id: swipeView width: window.width height: window.height Item{ id: item1 width: window.width height: window.height Rectangle{ id: rec1 width: window.width height: window.height color: "red" } } Item{ id: item2 width: window.width height: window.height Rectangle{ id: rec2 width: window.width height: window.height color: "blue" } } Item{ id: item3 width: window.width height: window.height Rectangle{ id: rec3 width: window.width height: window.height color: "green" } } } }

Permalänk
Hedersmedlem
Skrivet av heretic16:

Jag låter dom som är QML frälst få svara i tråden också
Vad finns det för fördelar med QML jämfört med C# för Visual Studio?

Nu är jag långt från någon QML-guru, men fördelarna är väl ungefär de vanliga:

  • Qt fungerar på en lång rad plattformar medan C# fokuserar på windows. Från och med .Net core finns förvisso stöd även för linux och mac, men det gäller inte Windows Forms och WPF. Maui skall dock även fungera på mac. Sedan finns projekt som Blazor.

  • Att det är ett c++-ramverk gör det trivialt att interagera med c- och c++-bibliotek. Det går ju ofta att lösa i c# också, men det är omständligare.

  • Det är snabbt. Vanligtvis kanske inte en jätteviktig faktor, men för komplexa applikationer kan det vara märkbar skillnad.

Permalänk
Medlem
Skrivet av Elgot:

Nu är jag långt från någon QML-guru, men fördelarna är väl ungefär de vanliga:

  • Qt fungerar på en lång rad plattformar medan C# fokuserar på windows. Från och med .Net core finns förvisso stöd även för linux och mac, men det gäller inte Windows Forms och WPF. Maui skall dock även fungera på mac. Sedan finns projekt som Blazor.

  • Att det är ett c++-ramverk gör det trivialt att interagera med c- och c++-bibliotek. Det går ju ofta att lösa i c# också, men det är omständligare.

  • Det är snabbt. Vanligtvis kanske inte en jätteviktig faktor, men för komplexa applikationer kan det vara märkbar skillnad.

Kan tillägga att MAUI äntligen blev släppt efter över ett års försening nu i veckan, så nu ska det gå att starta upp ett projekt i senaste versionen av Visual Studio 2022.

Permalänk
Medlem
Skrivet av Xenofonus:

Kan tillägga att MAUI äntligen blev släppt efter över ett års försening nu i veckan, så nu ska det gå att starta upp ett projekt i senaste versionen av Visual Studio 2022.

Just nu med 1007 ärenden markerade med t/bug på Github. WinUI3 (microsoft-ui-xaml) som utgör Windows-implementationen har 402 ärenden märkta bug. Kan jämföras med WPF 277 och winforms 85.

MAUI släpptes 23:e Maj, men det är först nu Visual Studio-stödet släppts till GA.

Permalänk
Datavetare
Skrivet av Elgot:

Att det är ett c++-ramverk gör det trivialt att interagera med c- och c++-bibliotek. Det går ju ofta att lösa i c# också, men det är omständligare.

Håller helt med här. Även om det är relativt enkelt att göra anrop till C/C++ bilbiotek i C# tillkommer några extra möjligheter att få saker fel...

Men vill bara inflika att när Microsoft designade CIL (.NETs variant av t.ex. Javas byte-kod) var en av de specifika kraven att interaktion med C/C++ kod paketerad som .dll/.so skulle vara relativt enkelt och framförallt effektivt!

Nästan alla moderna programspråk har någon form av kompatibilitet med bibliotek skrivna i C, men i flera av fallen (t.ex. Java) är det en relativt hög runtime-kostnad i att anropa C-funktioner. CIL är designat så att det är nära nog noll runtime-kostnad att korsa C#/C-barriären.

Visa signatur

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

Permalänk
Hedersmedlem
Skrivet av Yoshman:

Håller helt med här. Även om det är relativt enkelt att göra anrop till C/C++ bilbiotek i C# tillkommer några extra möjligheter att få saker fel...

C++/cli kan ju också användas som en brygga, men det har ju alltid behandlats lite styvmoderligt och jag tror inte att det finns några planer på stöd för annat än Windows.

Permalänk
Medlem
Skrivet av KAD:

Just nu med 1007 ärenden markerade med t/bug på Github. WinUI3 (microsoft-ui-xaml) som utgör Windows-implementationen har 402 ärenden märkta bug. Kan jämföras med WPF 277 och winforms 85.

MAUI släpptes 23:e Maj, men det är först nu Visual Studio-stödet släppts till GA.

Sen finns Xamarin som ligger på 2400 märkta med bug Vissa är ett antal år gamla, så det är ju inte direkt första gången Microsoft gör något liknande. När tredjeparts plugin måste fixa buggar/gå runt buggar som Microsoft vägrar fixa, då är det inte så kul

Visa signatur

NZXT H510 Flow MSI B450 Tomahawk MAX
AMD Ryzen 5800X3D RX 7900XTX Kingston Fury 64GB

Permalänk
Hedersmedlem
Skrivet av Pamudas:

Sen finns Xamarin som ligger på 2400 märkta med bug Vissa är ett antal år gamla, så det är ju inte direkt första gången Microsoft gör något liknande. När tredjeparts plugin måste fixa buggar/gå runt buggar som Microsoft vägrar fixa, då är det inte så kul

MAUI är väl fortsättning på xamarin också, så de buggarna kanske ingår…

Permalänk
Medlem
Skrivet av Elgot:

MAUI är väl fortsättning på xamarin också, så de buggarna kanske ingår…

Ja de har pushat mot MAUI ett bra tag inom Xamarin Forms. Blir lite same-same när det fortfarande är XAML som används med fokus på MVVM. Inte för att jag har något emot det - föredrar nästan denna Model-View binding men samtidigt är det skapligt irriterande med XML-formatet. Förmodligen en hel del kvar i bakgrunden från Xamarin i MAUI

Visa signatur

NZXT H510 Flow MSI B450 Tomahawk MAX
AMD Ryzen 5800X3D RX 7900XTX Kingston Fury 64GB

Permalänk
Medlem
Skrivet av Pamudas:

Ja de har pushat mot MAUI ett bra tag inom Xamarin Forms. Blir lite same-same när det fortfarande är XAML som används med fokus på MVVM. Inte för att jag har något emot det - föredrar nästan denna Model-View binding men samtidigt är det skapligt irriterande med XML-formatet. Förmodligen en hel del kvar i bakgrunden från Xamarin i MAUI

Det är det utan tvekan, tycker man får byggfel på Xamarin.nånting.nånting ena och andra ofta när det går snett när man försöker bygga Android.

Permalänk
Medlem
Skrivet av Xenofonus:

Det är det utan tvekan, tycker man får byggfel på Xamarin.nånting.nånting ena och andra ofta när det går snett när man försöker bygga Android.

Sen kommer en uppdatering som ska fixat ditt problem som du såklart drar ner direkt, för att sedan upptäcka att femtioelva andra saker gick sönder istället 🎉 Och fixen ligger i nästa major release som kommer göra en stor del deprecated 👍

Visa signatur

NZXT H510 Flow MSI B450 Tomahawk MAX
AMD Ryzen 5800X3D RX 7900XTX Kingston Fury 64GB

Permalänk
Skrivet av Yoshman:

Håller helt med här. Även om det är relativt enkelt att göra anrop till C/C++ bilbiotek i C# tillkommer några extra möjligheter att få saker fel...

Men vill bara inflika att när Microsoft designade CIL (.NETs variant av t.ex. Javas byte-kod) var en av de specifika kraven att interaktion med C/C++ kod paketerad som .dll/.so skulle vara relativt enkelt och framförallt effektivt!

Nästan alla moderna programspråk har någon form av kompatibilitet med bibliotek skrivna i C, men i flera av fallen (t.ex. Java) är det en relativt hög runtime-kostnad i att anropa C-funktioner. CIL är designat så att det är nära nog noll runtime-kostnad att korsa C#/C-barriären.

Nu har ju Java 17 och uppåt nyare och modernare sätt att anropa C-filer. Det kan vara Java 18. Jag har inte testat det, men det verkar vara lovade.

Sedan skulle jag inte prata högt om att Java har en hög runtime-kostnad i övrigt. Java är nog det språk som jag har lyckats göra applikationer som körs snabbast, för man skriver något mindre kod med det.

Permalänk
Skrivet av Elgot:

Nu är jag långt från någon QML-guru, men fördelarna är väl ungefär de vanliga:

  • Qt fungerar på en lång rad plattformar medan C# fokuserar på windows. Från och med .Net core finns förvisso stöd även för linux och mac, men det gäller inte Windows Forms och WPF. Maui skall dock även fungera på mac. Sedan finns projekt som Blazor.

  • Att det är ett c++-ramverk gör det trivialt att interagera med c- och c++-bibliotek. Det går ju ofta att lösa i c# också, men det är omständligare.

  • Det är snabbt. Vanligtvis kanske inte en jätteviktig faktor, men för komplexa applikationer kan det vara märkbar skillnad.

Jag har valt QML, dels för följande:

  1. QT är industrianpassat för långtidsapplikationer.

  2. .NET uppdateras sig ofta och skrotar det gamla

  3. Portabilitet

  4. QT har stöd för inbyggda system. Finns många som använder dyr hårdvara som de applicerar QT på

Permalänk
Datavetare
Skrivet av heretic16:

Nu har ju Java 17 och uppåt nyare och modernare sätt att anropa C-filer. Det kan vara Java 18. Jag har inte testat det, men det verkar vara lovade.

Sedan skulle jag inte prata högt om att Java har en hög runtime-kostnad i övrigt. Java är nog det språk som jag har lyckats göra applikationer som körs snabbast, för man skriver något mindre kod med det.

Du får skilja på "hur enkelt är det att göra anropet" och "hur mycket overhead kostar det att gå mellan ditt-val-av-språk<->C"

Nu verkar det ändå som Java krympt sin kostnad för anrop in i "native-kod" om man kikar på t.ex. detta projekt (som enligt Google folk verkar nämna ihop med Java18)
https://github.com/deepu105/Java-FFI-benchmarks

Vad man gör här är anropar getpid() som på både Linux och MacOS gör väldigt lite (hoppar i stort sätt in/ut i kärnan och läser en integer).

Men gjorde en provskott i C (base-line med "noll" overhead), C#, Java och Go (förklarar varför nedan).

På min Mac tar det 1,27 ns/anrop från C, 1,33 ns/anrop från C#, 6,96 ns/anrop från Java och hela 35,6 ns/anrop från Go.

C# (.NET Core 6 i detta fall) har ur alla praktiska hänseende noll runtime-overhead, däremot skulle jag säga att Go har minst kod-overhead att göra anrop in i C då man specifikt designade in stöd för det. Men p.g.a. saker Go kan göra (och C, Java och C# inte kan göra) så blir det tyvärr relativt dyrt att göra anrop in i C-kod därifrån.

Men som du skriver: man verkar ha putsat på både hur lätt det är att göra anrop in i C från Java och fått ned overhead, fast i båda fallen är det ändå icke-försumbar overhead i båda fallen.

Visa signatur

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

Permalänk
Hedersmedlem
Skrivet av heretic16:

QML är väll JavaScript?

På tal om javascript har Qt även klassen QJSEngine, vilken erbjuder en interaktiv javascriptmiljö som bland annat kan användas för att manipulera Qt-objekt under körning. Detta kan till exempel användas för att skapa skriptbara applikationer.

Permalänk
Skrivet av Elgot:

På tal om javascript har Qt även klassen QJSEngine, vilken erbjuder en interaktiv javascriptmiljö som bland annat kan användas för att manipulera Qt-objekt under körning. Detta kan till exempel användas för att skapa skriptbara applikationer.

Vad skulle du ha valt?
QtWidgets eller QML?

Jag tycker QML med Qt Quick...är inte så...Quick...Det är så mycket att göra. Men jag kanske har fel där.

Såg att man kan göra WebAssembly med QtWidgets...nu börjar vi snacka saker här! Jag är betydligt mer intresserad utav webbapplikationer än mobila applikationer!

Permalänk
Hedersmedlem
Skrivet av heretic16:

Vad skulle du ha valt?
QtWidgets eller QML?

Jag tycker QML med Qt Quick...är inte så...Quick...Det är så mycket att göra. Men jag kanske har fel där.

Jag har nästan uteslutande valt widgets så länge man har kunnat välja, men då har jag också uteslutande utvecklat ”traditionella” applikationer och känner mig väldigt hemma i widgets.

Jag inser ju dock att Quick har fördelar på många områden, så om man vill bygga mobilapplikationer eller responsiva gränssnitt är det nog det bästa alternativet, och har man väl kommit över tröskeln fungerar det ju till traditionella applikationer också.