Forum Mjukvara Programmering och digitalt skapande Tråd

C++ och dess framtid att programmera minnessäkert - Hur går utvecklingen?

59 60 61 62 63 64 65 66
Skriv svar
Permalänk
Medlem ★
●
Skrivet av klk:

Ja men kompilatorn kan inte kontrollera data i runtime

Gå till inlägget

Nej, men den kan kontrollera en del saker vid compile time.

Och alldeles oavsett hur du packar och skickar data så kan man ju lägga in runtime kontroller av att data är rimligt och korrekt, i den mån det överhuvudtaget går att avgöra. Att packa ihop data i en stor fet array gör inte den saken enklare.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av jclr:

Men nu är tydligen DOD (inte för att det här har något som helst med DOD att göra) generellt mycket "jobbigare"? Jag trodde att det bara hade fördelar och gjorde allt enklare?

Gå till inlägget

Då trodde du fel för då hade nog de flesta utvecklare kunnat skriva det
Du ser ju bara genom att läsa tråden, det är inte lätt och förklara.
Även videon med Andrew Kellys som postades, tror du det tog några dagar och implementera det där?

DOD har i princip alltid en ganska hög startkostnad i form av tid, vinsterna kommer efter ett tag

exempel från egen kod

// 4. "file-linelist" table
ptable_ = std::make_unique<table>(table(uTableStyle, { 
    {"uint64", 0, "key"}, 
    {"uint64", 0, "file-key"}, 
    {"rstring", 0, "filename"},
    {"rstring", 0, "line"}, 
    {"uint64", 0, "row"}, 
    {"uint64", 0, "column"}, 
    {"string", 32, "pattern"}, 
    {"string", 10, "segment"} 
}, gd::table::tag_prepare{}));

// 5. "file-snippet" table
ptable_ = std::make_unique<table>(table(uTableStyle, { 
    {"uint64", 0, "key"}, 
    {"uint64", 0, "file-key"}, 
    {"rstring", 0, "filename"},
    {"string", 10, "format"}, 
    {"uint64", 0, "row"}, 
    {"rstring", 0, "snippet"} 
}, gd::table::tag_prepare{}));

// 6. "keyvalue" table (uses different construction method)
auto ptableKeys = std::make_unique<gd::table::arguments::table>( gd::table::tag_full_meta{} );
ptableKeys->column_prepare();
ptableKeys->column_add("uint64", 0, "key");
ptableKeys->column_add("uint64", 0, "file-key");
ptableKeys->column_add("uint64", 0, "file-linelist-key");
ptableKeys->column_add("rstring", 0, "filename");
ptableKeys->column_add("uint64", 0, "row");
ptableKeys->prepare();

// 7. "history" table
ptable_ = std::make_unique<table>(table(uTableStyle, { 
    {"uint64", 0, "key"}, 
    {"int32", 0, "index"}, 
    {"string", 30, "date"}, 
    {"string", 20, "name"}, 
    {"rstring", 0, "line"}, 
    {"rstring", 0, "alias"} 
}, gd::table::tag_prepare{}));
Dold text
Senast redigerat
Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

"In computing, data-oriented design is a program optimization approach motivated by efficient usage of the CPU cache, often used in video game development."
https://en.wikipedia.org/wiki/Data-oriented_design

Gå till inlägget

Det står så mycket smörja på Wiki så text därifrån ger jag inte speciellt mycket för när det handlar om djupare teknisk kunskap. Wiki är bäst för normal allmänbildning

Skrivet av Yoshman:

DOD är något som främst verkar praktiseras i spelvärlden. Var även där termen först myntades 2009.

Gå till inlägget

Möjligen men det kan också ha och göra med att när det skrivs kod publikt, då dominerar spelprogrammering stort. Går inte att få samma intresse för annan typ av mjukvaruutveckling

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av klk:

Det står så mycket smörja på Wiki så text därifrån ger jag inte speciellt mycket för när det handlar om djupare teknisk kunskap. Wiki är bäst för normal allmänbildning

Gå till inlägget

Wikipedia brukar vara trovärdig - i synnerhet när det gäller tekniska och naturvetenskapliga ämnen.
Wikipedia är definitivt, utan något som helst tvivel, mycket pålitligare och trovärdigare än valfri LLM-baserad AI. Och för det mesta pålitligare än youtube-kanaler.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Erik_T:

Wikipedia brukar vara trovärdig - i synnerhet när det gäller tekniska och naturvetenskapliga ämnen.
Wikipedia är definitivt, utan något som helst tvivel, mycket pålitligare och trovärdigare än valfri LLM-baserad AI. Och för det mesta pålitligare än youtube-kanaler.

Gå till inlägget

Men alla de media du räknar upp där har inga krav på att vara korrekta.

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av klk:

Ja men kompilatorn kan inte kontrollera data i runtime

Gå till inlägget

Sant.

Men om man jobbar i språk som har inbyggt stöd för "tagged unions", t.ex. Rust:s enum, kan kompilator göra en hel del statiskt analys som minskar risken att man gör ett misstag oavsett vilken av de möjliga runtime-typerna en viss datapost råkar ha.

Om man sen inte primärt är ute efter prestandafördelarna med DOD finns andra sätt att uppnå liknade effekt. Moderna versioner av C# kan göra pattern-matching på typer, kompilatorn kan även här göra en del statisk analys via "is-a" relation. Detta borde gå att få till även i C++

För att ta @jclr utmärka exempel ovan kan det skrivas så här i C#. Det har dock absolut inget med DOD att göra givet hur minnet kommer allokeras under huven...

// Algebraic Data Type (sum type): Foo = Bar | Baz
public abstract record Foo;

public sealed record Bar(bool X) : Foo;            // Product: one bool
public sealed record Baz(byte Y, bool Z) : Foo;    // Product: byte AND bool

static string Describe(Foo foo) => foo switch
{
    Bar(var x)           => $"Bar with X={x}",
    Baz(var y, var z)    => $"Baz with Y={y}, Z={z}",
    _                    => throw new ArgumentOutOfRangeException(nameof(foo))
};

var a = new Bar(true);
var b = new Baz(123, false);
Console.WriteLine(Describe(a)); // Bar with X=True
Console.WriteLine(Describe(b)); // Baz with Y=123, Z=False

Går att få till något som påminner om det i C++, men är inte heller DOD. Kompilator kan även här göra en hel del statisk analys.

struct Bar { bool x; };
struct Baz { std::uint8_t y; bool z; };

using Foo = std::variant<Bar, Baz>;

template<class... Ts> struct overloaded : Ts... { using Ts::operator()...; };
template<class... Ts> overloaded(Ts...) -> overloaded<Ts...>;

std::string describe(const Foo& foo) {
    return std::visit(overloaded{
        [](const Bar& b) {
            return std::string{"Bar x="} + (b.x ? "true" : "false");
        },
        [](const Baz& b) {
            auto [y, z] = b;
            return "Baz y=" + std::to_string(y) + ", z=" + (z ? std::string{"true"} : "false");
        }
    }, foo);
}

int main() {
    Foo a = Bar{true};
    Foo b = Baz{123, false};
    std::cout << describe(a) << "\n";
    std::cout << describe(b) << "\n";
}
Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av klk:

Men alla de media du räknar upp där har inga krav på att vara korrekta.

Gå till inlägget

Jag vet inte vad din poäng är. De flesta media har inga krav på sig att vara korrekta - och inga media är alltid 100% korrekta.
En del media är pålitligare än andra dock, och Wikipedia hör till de pålitligare.
AI, som du gillar att hänvisa till, hör till de mindre pålitliga, och ingen vettig människa litar på svar från en AI utan att kontrollera svaret först.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Erik_T:

Jag vet inte vad din poäng är. De flesta media har inga krav på sig att vara korrekta - och inga media är alltid 100% korrekta.
En del media är pålitligare än andra dock, och Wikipedia hör till de pålitligare.
AI, som du gillar att hänvisa till, hör till de mindre pålitliga, och ingen vettig människa litar på svar från en AI utan att kontrollera svaret först.

Gå till inlägget

Jag hänvisar inte för att det skulle vara korrekt men jag vet att det jag skriver här inte uppfattas som trovärdigt ;), så det var bara ett litet försök att styrka något.

Personligen har jag praktiserat tekniken med mycket stor framgång och vet hur effektiv den är. Det förlitar jag mig på
Om det faktiskt kallas för DOD eller något annat är inte det viktiga men principen jag försöker följa är att skriva kod kring mönster i minnet. Första programmet jag skrev tog 7 månader, samma program hade ett större företag försök skriva två gånger och spenderat nästan 3 år för att skriva med rätt mycket folk. De klarade det inte så detta företag köpte in en mjukvara som fungerade någorlunda skriven för apple. Vart anställd och skrev om den för windows och applikationen säljs än idag.

Påstår inte att det var min förtjänst för han som skrivit programmet lärde mig mycket och var/är mycket duktig.

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av klk:

Det står så mycket smörja på Wiki så text därifrån ger jag inte speciellt mycket för när det handlar om djupare teknisk kunskap. Wiki är bäst för normal allmänbildning

Gå till inlägget

Inledningen av Wikipedia artikeln är rätt mycket ett abstrakt för den artikel Stoyan Nikolov skrev 2009 och som anses vara där DOD först nämndes.

Om du istället vill ha LLM sammanfattningen är Geminis denna

Data-Oriented Design (DOD) emerged from low-level game development to optimize software performance by focusing on hardware-aware data layout and efficient CPU cache usage, a departure from object-oriented design. Key figures like Stoyan Nikolov and Casey Muratori promoted the approach, emphasizing data transformations and data-driven design to minimize cache misses and maximize CPU throughput, especially for resource-intensive applications.

Där nämns ju din favorit, Casey Muratori (som också är spelutvecklare). Och även där trycker man på att målet är att öka prestanda.

Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

Där nämns ju din favorit, Casey Muratori (som också är spelutvecklare). Och även där trycker man på att målet är att öka prestanda.

Gå till inlägget

Ja alltså det är ju självklart att man tänker på prestanda men det jag nämnt är att prestandan kan användas olika

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av klk:

Det står så mycket smörja på Wiki så text därifrån ger jag inte speciellt mycket för när det handlar om djupare teknisk kunskap. Wiki är bäst för normal allmänbildning

Gå till inlägget

Fast nu verkar du leva på gammal info. Jag tror att de flesta uppdateringarna på Wikipedia idag genomgår någon form av granskning och diskussion vid dispyt.

Jag tror att du uppfattar det som smörja eftersom du har dina alldeles egna bild av världen.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av klk:

Jag hänvisar inte för att det skulle vara korrekt men jag vet att det jag skriver här inte uppfattas som trovärdigt

Gå till inlägget

Korrekt, jag anser dig inte som trovärdig.

Hur tror du att vi andra är så synkade?

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av orp:

Korrekt, jag anser dig inte som trovärdig.

Hur tror du att vi andra är så synkade?

Gå till inlägget

Vet ej och jag är van. Du vet nog hur folk reagerar om någon beskriver HN som effektivt

Tyvärr tar det en del tid innan företagsledningar och annat förstår att mjukvaruprojekt håller på att krascha så svårt att prata teknik, oftast vinner de som låter bäst även om den inte förstår vad de pratar om

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av klk:

Vet ej och jag är van. Du vet nog hur folk reagerar om någon beskriver HN som effektivt

Tyvärr tar det en del tid innan företagsledningar och annat förstår att mjukvaruprojekt håller på att krascha så svårt att prata teknik, oftast vinner de som låter bäst även om den inte förstår vad de pratar om

Gå till inlägget

Det hade nog hjälpt om du presenterat logiskt sammanhängande resonemang ihop med lite belägg, då tror jag att du hade fått gehör

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●

En sektion i "Data-Orienten Design" texten kan jag inte riktigt hålla med om

"Data-oriented design takes a different approach to the problem, instead of assuming we know nothing about the hardware, it assumes we know little about the true nature of our problem, and makes the schema of the data a second-class citizen. Anyone who has written a sizeable piece of software may recognise that the technical structure and the design for a project often changes so much that there is barely any section from the first draft remaining unchanged in the final implementation."

Har skrivit rätt mycket kod för embedded och RTOS-system. Majoriteten av all kod som initialt skrevs var den som i slutändan också hamnade i produkterna. Där finns en hel del som sitter i enheter som idag varit i drift i 20-25 år.

Vad har ni andra för erfarenhet här? Det har ändå en del bäring på vad tråden faktiskt handlar om då det ger en vink om hur mycket av all C++ kod som används idag kan tänkas komma bli let mer modern och säker via "refactoring".

Det skrivet: har också jobbat i projekt där den första draft:en/prototypen rätt mycket helt hamnade i runda arkivet. Den verkliga produkten var en total rewrite. Har även ett par fall där det också inkluderat ett språkbyte mellan prototyp och produkt (senast det hände blev det en prototyp i Rust och verklig produkt i Go, väldigt lyckat men nog en lite ovanlig sekvens av språkval).

Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av orp:

Det hade nog hjälpt om du presenterat logiskt sammanhängande resonemang ihop med lite belägg, då tror jag att du hade fått gehör

Gå till inlägget

Det tror faktiskt inte jag. Gamla hundar kan inte lära sig sitta.
Har lärt upp en del och det fungerar bra om de är nya, men om någon har något år i branschen blir det fasligt svårt och lära om

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av klk:

Det tror faktiskt inte jag. Gamla hundar kan inte lära sig sitta.
Har lärt upp en del och det fungerar bra om de är nya, men om någon har något år i branschen blir det fasligt svårt och lära om

Gå till inlägget

Det är lustigt att du inte ser ironin i dina inlägg ihop med ditt agerande.

Bara för att du har problem med att hålla dig uppdaterade betyder inte att alla har det. Exempelvis @Yoshman och @serafim verkar ha varit med ett tag men de verkar ha hållit sig uppdaterade så jag misstänker att du har fel.

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av orp:

Det är lustigt att du inte ser ironin i dina inlägg ihop med ditt agerande.

Bara för att du har problem med att hålla dig uppdaterade betyder inte att alla har det. Exempelvis @Yoshman och @serafim verkar ha varit med ett tag men de verkar ha hållit sig uppdaterade så jag misstänker att du har fel.

Gå till inlägget

Men då får jag väl ha fel då, det är ok

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av orp:

Det är lustigt att du inte ser ironin i dina inlägg ihop med ditt agerande.

Bara för att du har problem med att hålla dig uppdaterade betyder inte att alla har det. Exempelvis @Yoshman och @serafim verkar ha varit med ett tag men de verkar ha hållit sig uppdaterade så jag misstänker att du har fel.

Gå till inlägget

Nåja, hyfsat med men en del av diskussionerna (från de jag av er jag anser verka kunna ...) visar att jag har en del att läsa på och testa. Sen 2019 har jag inte programmerat på professionell nivå utan bara hobbyprogrammerat och en hel del har hänt sen dess även om det mesta inom programmeringstekniken är i stort sett detsamma så har programmeringsspråken utvecklats, andra kommit till, teknikområden kommit till, AI förbättrats (även om mycket av det som idag kallas AI borde ha andra namn och särskiljas från "riktig" AI).
Det här kallas självinsikt, något som jag tycker alla programmerare borde ha ... hint, hint ...

Visa signatur

Debian, bara Debian, Debian överallt

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Yoshman:

En sektion i "Data-Orienten Design" texten kan jag inte riktigt hålla med om

"Data-oriented design takes a different approach to the problem, instead of assuming we know nothing about the hardware, it assumes we know little about the true nature of our problem, and makes the schema of the data a second-class citizen. Anyone who has written a sizeable piece of software may recognise that the technical structure and the design for a project often changes so much that there is barely any section from the first draft remaining unchanged in the final implementation."

Har skrivit rätt mycket kod för embedded och RTOS-system. Majoriteten av all kod som initialt skrevs var den som i slutändan också hamnade i produkterna. Där finns en hel del som sitter i enheter som idag varit i drift i 20-25 år.

Vad har ni andra för erfarenhet här? Det har ändå en del bäring på vad tråden faktiskt handlar om då det ger en vink om hur mycket av all C++ kod som används idag kan tänkas komma bli let mer modern och säker via "refactoring".

Det skrivet: har också jobbat i projekt där den första draft:en/prototypen rätt mycket helt hamnade i runda arkivet. Den verkliga produkten var en total rewrite. Har även ett par fall där det också inkluderat ett språkbyte mellan prototyp och produkt (senast det hände blev det en prototyp i Rust och verklig produkt i Go, väldigt lyckat men nog en lite ovanlig sekvens av språkval).

Gå till inlägget

Tycker också det markerade stycket verkar konstigt. Om de som använder DOD har en sådan erfarenhet borde det kanske stämma till eftertanke.
Har man verkligen rätt infallsvinkel till programdesign eller designmässig erfarenhet om man inte kan känna igen det man initialt skrev i det slutliga resultatet?
Min erfarenhet är tvärtom, i stort sett all kod i den färdiga applikationen är den ursprungliga, det är mest detaljer som skiljer. Någon gång kan man ha haft idéer där vi i utvecklingsgruppen varit osäkra på hur det ska implementeras men det blev allt mindre med åren. I ett projekt upptäckte vi att det mesta av indata till systemet fanns att hitta på internet så jag skrev i Groovy, utan tidigare erfarenhet av sånt, "web-krälare" som samlade ihop sådana data och automatiskt matade in dem i systemet. Den koden blev naturligtvis föremål för refactoring, men det var ganska lätt jobb eftersom jag modulariserat koden. Delar kunde slås samman och mycket i implementationen blev ändrat men det brodde ju på att området var nytt för mig då och under arbetets gång fick jag nya insikter (och andra utvecklare kom med goda idéer om hur man borde göra). Faktiskt en ganska kul tid under ett annars tidspressat jobb.

Visa signatur

Debian, bara Debian, Debian överallt

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Yoshman:

"...Anyone who has written a sizeable piece of software may recognise that the technical structure and the design for a project often changes so much that there is barely any section from the first draft remaining unchanged in the final implementation."

Vad har ni andra för erfarenhet här?

Gå till inlägget

Nu är det svårt att förstå exakt vad dom menar eftersom "first draft" kan se väldigt olika ut beroende på vad man klassar som "first draft".

Är det ett omfattande projekt och flera teammedlemmar är inblandade så tycker jag att det är vanligare att man spenderar mer tid i designfasen och sedan itererar småbitar inom kodbasen men att mycket är kvar från "first draft" i "final implementation".

Är det ett mindre projekt eller hobbyprojekt så brukar jag och några vänner skriva en eller två implementationer som kastas för att förstå problemet bättre och klassar man dessa som "first draft" så finns inget kvar i "final implementation".

Jag måste få en mer specifik förklaring till "sizeable piece of software" och "first draft" för att säga hur jag skulle agerat men hoppas min förklaring gav lite perspektiv.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av jclr:

Om nån läser det här och inte bara tänker wtf hieroglyfer så kan man testa att lösa 10 enkla utmaningar i APL challenge. Allt man behöver kunna om APL beskrivs i varje utmaning.

Gå till inlägget

(Nu är vi way off topic, men det är vi väl vana vid i den här tråden.)

"Allt man behöver" kanske var en liten overstatement. Mina lösningar innehöll inget som inte hade presenterats för de tidigare uppgifterna, men som total APL-n00b var det många frågor som snurrade i huvudet (operatorprecedens? hur sköts iteration?). UI:t på challenge-sidan som oftast bara sade "fel svar" var inte särskilt hjälpsamt. Det krävdes en hel del experimenterande på tryapl för att få till sista lösningen. Min bild av APL baserad på denna sida: funktionell programmering i kubik, klart annorlunda och kul att pröva.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av orp:

Nu är det svårt att förstå exakt vad dom menar eftersom "first draft" kan se väldigt olika ut beroende på vad man klassar som "first draft".

Är det ett omfattande projekt och flera teammedlemmar är inblandade så tycker jag att det är vanligare att man spenderar mer tid i designfasen och sedan itererar småbitar inom kodbasen men att mycket är kvar från "first draft" i "final implementation".

Är det ett mindre projekt eller hobbyprojekt så brukar jag och några vänner skriva en eller två implementationer som kastas för att förstå problemet bättre och klassar man dessa som "first draft" så finns inget kvar i "final implementation".

Jag måste få en mer specifik förklaring till "sizeable piece of software" och "first draft" för att säga hur jag skulle agerat men hoppas min förklaring gav lite perspektiv.

Gå till inlägget

Jag ror inte de menar hobbyprojekt, där gör jag ungefär som du, testar lite, slänger i hop lite kod som jag sedan kastar eftersom jag inser att jag inte tänkt igenom ordentligt, testar igen och får jag någotsånär fungerande resultat kanske jag bygger vidare annars släng igen.

I övrigt håller jag med med ett litet undantag vad gäller "first draft". I större projekt tenderar design vara en väsentlig bit i början men sen går man, i alla fall i de flesta projekt jag varit med om, top-down, och då finns ingen urskiljningsbar "first draft". Går man top-down bryter man ju ner projektet i delar som i sin tur delas ner så koden "växer" fram organiskt efter hand. Det finns naturligtvis en "final implementation" men ingen "first draft" och det mesta av koden som framställs blir kvar.

Visa signatur

Debian, bara Debian, Debian överallt

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av orp:

Nu är det svårt att förstå exakt vad dom menar eftersom "first draft" kan se väldigt olika ut beroende på vad man klassar som "first draft".

Är det ett omfattande projekt och flera teammedlemmar är inblandade så tycker jag att det är vanligare att man spenderar mer tid i designfasen och sedan itererar småbitar inom kodbasen men att mycket är kvar från "first draft" i "final implementation".

Är det ett mindre projekt eller hobbyprojekt så brukar jag och några vänner skriva en eller två implementationer som kastas för att förstå problemet bättre och klassar man dessa som "first draft" så finns inget kvar i "final implementation".

Jag måste få en mer specifik förklaring till "sizeable piece of software" och "first draft" för att säga hur jag skulle agerat men hoppas min förklaring gav lite perspektiv.

Gå till inlägget

Sant, man kan tolka det lite olika. Själv tänkte jag på fallet där man kommit till punkten där det finns en plan vad man vill bygga och sätter igång med kodandet. Från den punkten till att man har en v1.0 har det i mitt fall sedan typiskt varit ett gäng månader till något års arbete.

Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●

För att återgå lite till trådens huvudsakliga ämne, Microsofts Windows följer i Linux spår och tillåter nu att man skriver drivers i Rust

"Microsoft is turning Rust into a first-class language for developing secure Windows drivers"
https://www.techspot.com/news/109351-microsoft-turning-rust-f...

Orsaken är samma som för andra Windows-system där man börjat använda Rust, minska antalet fel som kommer från out-of-bounds read/write, use-after free och andra fel som tyvärr är vanliga i C och C++, men omöjliga i "safe Rust".

Men just delen "safe Rust" är där Microsoft säger man har mer att göra m.a.p. Rust WDF ramverket. I nuläget går det skriva drivers, men de kräver mer användande av "unsafe" än önskat. Detta kommer förbättras i framtida versioner.

C och C++ kommer knappast att försvinna inom överskådlig tid, men saker som OS-drivers och OS-systemtjänster kan komma att följa i samma spår som mycket back-end och LOB-programvara som för länge sedan ofta utvecklades i C++ men har sedan länge nästan helt gått över till Java, C# och annat.

Vi lär se samma sak med Rust. Det lär knappast helt ersätta C och C++, men de kan mycket väl ersätta dessa språk i områden där undvikande av säkerhetsbuggar är extra kritiskt. Drivers är ett väldigt bra exempel, tror även MCU-ramverk också tar den vägen.

Finns en del språk som i praktiken helt dött ut. Tror att en viktig orsak att det hände var hur tool-chains såg ut i datorvärldens tidiga år: det var mycket mer en komplett lösning för en eller ett par CPU ISA för ett specifikt språk.

Idag är det långt vanligare med en hyfsat separerad "front-end" som tar flertalet programspråk till någon form av intermediate representation (IR). Sedan finns en "back-end" som tar denna IR till specifika CPU ISA. LLMV, GCC, .NET och JVM:er är ju alla exempel på detta.

Med en sådan design är det dels mycket lättare att lägga till nya ISA/programspråk, men också betydligt lättare att behålla stödet för ett existerande programspråk (som då också får stöd för de nya ISA man lägger in). Så i någon mening lär de språk som stöds på det sätter nog "aldrig" försvinna.

Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av orp:

Nu är det svårt att förstå exakt vad dom menar eftersom "first draft" kan se väldigt olika ut beroende på vad man klassar som "first draft".

Gå till inlägget

Eller så bara låt bli att tolka texten, försök förstå problemet som man försöker lösa och hur tekniken fungerar. Förstår man inte poängen med DOD blir det virrigt.

Det här med att lösa problem är intressant och tror också trådens ämne (minnesproblematik) relaterar starkt till det.

När jag började programmera gick det i princip inte att utbilda sig till programmerare, några högskolor hade vissa utbildningar men yrket var nördigt och de som valde kurserna var ändå datanördar.

Var svårt att läsa sig till kunskaperna utan man fick tänka själv. Något jag brukar kalla för ingenjörsskallar. Med tiden vart yrket mer och mer populärt och det var bra betalt, massa nya dyker upp som kanske inte är lika nördiga... alltså intresset är svagare. Det är mer ett jobb. Den här kategorin läser sig till kunskaperna, de tränar sig inte att själva lösa problem. Har man inte läst det så kan man inte.
Jag tror det här också är orsaken till varför det är svårt för teoretiker/akademiker och ingenjörer att diskutera för de tänker olika. Den ena kategorin är van att läsa sig till information medan den andra direkt går in i problemlösnings-mode. Funderar på hur en teknik kan användas för att lösa problem.

Det blir lätt kaos när så olika personlighetstyper försöker förstå varandra eftersom de är så annorlunda i sättet de tänker.

Teoretiker förstår inte hur man kan lösa minne på annat sätt än de läst, ingenjörer som är vana att lösa problem vet hur de kan använda andra tekniker för att göra det.

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av klk:

Eller så bara låt bli att tolka texten, försök förstå problemet som man försöker lösa och hur tekniken fungerar. Förstår man inte poängen med DOD blir det virrigt.

Det här med att lösa problem är intressant och tror också trådens ämne (minnesproblematik) relaterar starkt till det.

När jag började programmera gick det i princip inte att utbilda sig till programmerare, några högskolor hade vissa utbildningar men yrket var nördigt och de som valde kurserna var ändå datanördar.

Var svårt att läsa sig till kunskaperna utan man fick tänka själv. Något jag brukar kalla för ingenjörsskallar. Med tiden vart yrket mer och mer populärt och det var bra betalt, massa nya dyker upp som kanske inte är lika nördiga... alltså intresset är svagare. Det är mer ett jobb. Den här kategorin läser sig till kunskaperna, de tränar sig inte att själva lösa problem. Har man inte läst det så kan man inte.
Jag tror det här också är orsaken till varför det är svårt för teoretiker/akademiker och ingenjörer att diskutera för de tänker olika. Den ena kategorin är van att läsa sig till information medan den andra direkt går in i problemlösnings-mode. Funderar på hur en teknik kan användas för att lösa problem.

Det blir lätt kaos när så olika personlighetstyper försöker förstå varandra eftersom de är så annorlunda i sättet de tänker.

Teoretiker förstår inte hur man kan lösa minne på annat sätt än de läst, ingenjörer som är vana att lösa problem vet hur de kan använda andra tekniker för att göra det.

Gå till inlägget

Fast lever man inte en egen rätt poänglös verklighet om man hela tiden säger: "Xyz hade fungerat bara alla vara genier och aldrig gjorde misstag"?

Det pragmatiska är väl ändå att ta de observationer som gjorts kring vilka problem som ofta återkommer i vissa lägen men som är långt ovanligare i andra och dra slutsatsen: om detta är viktigt bör vi göra som de fall där man verkar fått bukt med problemet.

Är ju exakt den analysen Microsoft, Apple, Meta, Google, m.fl. gjort och de har p.g.a. det numera en policy där man absolut inte förbjuder C++ (alla dessa företag har ju massor med C++ i deras produkter) men där man säger att "minnessäkra" allternativ ska alltid vara förstahandsvalet, för att välja C++ (och C) måste det finns en motivering till varför alternativen inte fungerar (och där lär det nästan alltid handla om "vi utökar/bygger något som idag är C++, vårt gränssnitt ligger på biblioteks/funktionsanropsnivå").

Vad det gäller min invändning kring påståendet i DOD dokumentet så använde man det för att lyfta varför DOD är så mycket bättre. Men känns som just det påståendet gjorts baserat på "vad man hört", inte vad man själv faktiskt upplevt för man jobbat i den typen av projekt.

Min erfarenhet är att man inte skriver om stora delar under ett projekts gång. Majoriteten av koden skrivs, testas och sedan förblir den rätt orörd under resten av sitt liv. Ska då i.o.f.s. tillägga att jag så här långt mest jobbat med systemprogramvara, har jobbat relativt lite med LOB-lösningar, UI-kodning och väldigt lite med web-frontend lösningar. Så kanske ser annorlunda ut där.

Helt klart ÄR det så att är de tekniker och lösningar som praktiseras inom DOD generellt applicerbara då oavsett vad man bygger kommer det finnas delar där man transformerar data from ett format till ett annat (något som DOD försöker göra så billig som möjligt).

Men det långt ifrån säkert att transformering av data är en signifikant flaskhals, att då praktisera DOD (till och med de som är mest positiva till DOD är med på att det är en viss kognitiv last att jobba så) är väl ändå att praktisera "Premature optimization is the root of all evil"?

Senast redigerat
Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av klk:

Eller så bara låt bli att tolka texten, försök förstå problemet som man försöker lösa och hur tekniken fungerar.

Gå till inlägget

Jag vet att det är din strategi att inte tolka text och svamla vidare om vad du än känner för.

Nu frågade @Yoshman hur vår erfarenhet ser ut och jag beskrev mitt perspektiv. Det är dumt att inte tolka texten, när någon explicit ber en att tolka texten för att se om det stämmer överens med ens verklighetsbild...

Skrivet av klk:

Det här med att lösa problem är intressant och tror också trådens ämne (minnesproblematik) relaterar starkt till det.

Gå till inlägget

Nej, DOD vs OOP hör inte till trådens ämne. Varken DOD eller OOP säger något om minnessäkerheten.

Skrivet av klk:

När jag började programmera gick det i princip inte att utbilda sig till programmerare, några högskolor hade vissa utbildningar men yrket var nördigt och de som valde kurserna var ändå datanördar.

Var svårt att läsa sig till kunskaperna utan man fick tänka själv. Något jag brukar kalla för ingenjörsskallar. Med tiden vart yrket mer och mer populärt och det var bra betalt, massa nya dyker upp som kanske inte är lika nördiga... alltså intresset är svagare. Det är mer ett jobb. Den här kategorin läser sig till kunskaperna, de tränar sig inte att själva lösa problem. Har man inte läst det så kan man inte.
Jag tror det här också är orsaken till varför det är svårt för teoretiker/akademiker och ingenjörer att diskutera för de tänker olika. Den ena kategorin är van att läsa sig till information medan den andra direkt går in i problemlösnings-mode. Funderar på hur en teknik kan användas för att lösa problem.

Det blir lätt kaos när så olika personlighetstyper försöker förstå varandra eftersom de är så annorlunda i sättet de tänker.

Gå till inlägget
Dold text

Svammel och fördomar...

Skrivet av klk:

Teoretiker förstår inte hur man kan lösa minne på annat sätt än de läst, ingenjörer som är vana att lösa problem vet hur de kan använda andra tekniker för att göra det.

Gå till inlägget

Du vet om att ingenjör är en akademisk utbildning?

Jag tror att du trollar igen... Vad har du för bevis för att "teoretiker" skulle tappa sin kognitiva förmåga?

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av orp:

Du vet om att ingenjör är en akademisk utbildning?

Gå till inlägget

Exakt det här är "problemet", akademiker trasslar in sig i ord istället för att förstå problematiken. Fattar de inte orden de är vana vid blir det jobbigt

Bara den diskussion vi har om DOD, det är en teknik som kan användas på olika sätt.
Istället blir det "DOD" är bla bla bla bla. Ok, då får det vara det men förstå tekniken istället

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av klk:

Exakt det här är "problemet", akademiker trasslar in sig i ord istället för att förstå problematiken. Fattar de inte orden de är vana vid blir det jobbigt

Gå till inlägget

Nej det gör akademiker inte. Alla läskunniga människor använder ord för att kommunicera betydelse. Om man får en skriftlig problembeskrivning så måste man tolka orden för att förstå problemet. Det gäller ju oavsett yrkeskategori eller utbildningsgrad.

Skrivet av klk:

Fattar de inte orden de är vana vid blir det jobbigt

Gå till inlägget

Nu säger du dumheter igen. Det är när personer som du använder etablerade termer med en helt annan betydelse som det blir problem och det är än en gång inte isolerat till yrkeskategori eller utbildningsgrad. Om du hyr in en snickare och säger att du vill lägga om taket men med tak menar du egentligen fasaden, tror du att snickaren kommer att utföra det du förväntar dig?
Varför kallar du inte vänster för höger systematiskt? Varför är det just programmeringstermer som du inte kan innebörden av?

Skrivet av klk:

Bara den diskussion vi har om DOD, det är en teknik som kan användas på olika sätt.
Istället blir det "DOD" är bla bla bla bla. Ok, då får det vara det men förstå tekniken istället

Gå till inlägget

Nu var det du som började bryta ner innebörden av DOD(följande citat) istället för att diskutera tekniken efter att du än en gång haft mängder av feluppfattningar om DOD.

Du gnäller om att vi diskuterar ord gällande DOD men det är enbart du som diskuterat orden i DOD...
Du gnäller om att man ska förstå tekniken DOD istället men du verkar ha sämst förståelse om DOD i tråden...

Ironin än en gång

Skrivet av klk:

Analys av de tre orden i data orienterad design
DATA - Data är troligen centralt, vanligen datorns minne
ORIENTERAD - inriktning, fokus, skräddarsydd, utformad (finns fler liknande ord)
DESIGN - (behöver jag förklara det här ordet ?)

Jämför med DDD (domain-driven design)
DOMAIN - Användardomän, territorium, användarens kunskap/område
DRIVEN - Driver
DESIGN - (behöver jag förklara det här ordet ?)

Gå till inlägget

Avslutningsvis, det har framförallt diskuterats vad DOD faktiskt innebär och bemötande av dina absurda påstående som
- Tagged unions är exempel på DOD.
- DOD handlar inte primärt om prestanda.
- DOD handlar inte primärt om prestanda men prestandavinsten skulle magiskt översättas till ökad säkerhet.
- DOD handlar inte primärt om prestanda men prestandavinsten skulle magiskt översättas till ökad flexibilitet.
- DOD resulterar i mer återanvändbar kod.
osv....

Senast redigerat
Redigera
Citera flera Citera
59 60 61 62 63 64 65 66
Skriv svar