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

Ja och de fokuserar på språket C++, de är språknördar och det skiljer mot utvecklare.
För utvecklare är endast C/C++ ett verktyg för att ta sig från A till B. Dyker det upp ett bättre verktyg så hade jag bytt på fem minuter.
Bjarne och Herb (och en hel del till) har fokus på språket vilket är något annat. De måste tänka på saker som jag som utvecklare inte bryr mig om

Inget bra sätt nej. Men för mig och när jag varit med och lärt upp eller kanske blivit upplärd så har det alltid varit viktigt att skriva kod. Också viktigt att designa kod så nya utvecklare får skriva även om de kanske inte gör något vettigt i början.

Och för mig är också kodmängd en teknik för att se om arkitekturen är ok. Fungerar arkitekturen bra skall det gå lika snabbt att skriva kod oavsett hur stort projektet är. Om det är 1 000, 10 000 eller 100 000 000 rader kod skall inte spela någon roll.

Förutom det så använder jag hungarian notation
*exempel*

| Postfix | Description | Sample |
| ------------ | ----------- | ------ |
| `b`* | **boolean** | `bool bOk, bIsOk, bIsEof, bResult;` |
| `i`* | **signed integer** (all sizes) | `int iCount;` `int64_t iBigValue;` `int16_t iPosition; char iCharacter;` |
| `u`* | **unsigned integer** (all sizes) | `unsigned uCount;` `uint64_t uBigValue;` `uint8_t uCharacter;` `size_t uLength;` |
| `d`* | **decimal values** (double, float) | `double dSalary;` `float dXAxis;` `double dMaxValue;` |
| `p`* | **pointer** (all, including smart pointers) | `int* piNumber;` `int piNumber[20];` `void* pUnknown;` `std::unique_ptr<std::atomic<uint64_t>[]> pThreadResult;` |
| `e`* | **enum values** | `enum enumBodyType { eUnknown, eXml, eJson };`  `enumBodyType eType = eJson;` |
| `it`* | **iterator** | `for( auto it : vectorValue ) {...}` `for( auto it = std::begin( m_vectorOption ), itEnd = std::end( m_vectorOption ); it != itEnd; it++ ) {...}` |
| `m_`* | **member variables** | `uint64_t m_uRowCount;`  `std::vector<column> m_vectorColumn;` `uint8_t* m_puTableData = nullptr;` |
| `string`* | **all string objects** | `std::string_view stringName;`  `std::string stringName;` `std::wstring stringName;` |
| *`_` | **view declaration** | `boost::beast::http::file_body::value_type body_;` |

Med hungarian blir utvecklare snabba

Produktion av kodrader har alltid varit något jag kontrollerat, kanske udda.
Självklart så en majoritet av alla rader kod man gjort, det är ju skitkod och slängts

Jag har inte testat att skriva rust kod och kommer inte göra det har skrivit en del C# och för många år sedan en del java. De här språken fungerar inte alls för mig. Som tur är finns det gott om andra programmerare som delar mina åsikter och har därför kunnat arbeta med intresset.

Rust förstod jag inte, bara att rust utvecklare är så löjligt aktiva så svårt att undvika.
Nu vet jag mer om språket och jag tror faktiskt inte språket har en framtid. Eller så får de ta till en del ny funktionalitet. Problemet där är att språket försöker vara för mycket och designen är anpassad efter det.

Andra språk med GC försvinner direkt.

Det jag nyligen lärt mig om rust
Att inte kunna överlagra, och Drop och new logiken, ingen hitt i min bok och får därför också bättre förståelse för varför rust utvecklare så ofta förkortar namn för det är inget jag gillar. Förkortningar är enligt mig ett tecken på fel i arkitekturen.

Det går inte, finns inget språk som klarar allt. Datorer skiljer sig så starkt ifrån hur människor tänker så man måste stegvis koppla ihop funktionalitet för människor med datorer.

Smartpointers är "kladdigt".
Att C++ har konstruktor och destruerar räcker. Inte svårt att lägga in en delete i destructorn.
Och arkitektur är så mycket viktigare, slarv med minne tvingar utvecklare att tänka på arkitekturen. Du måste lära dig det
Jämför med GC språk, du kan göra som du vill och behöver därför inte lära dig

vNumber och vEvenNumber

Numbers och EvenNumbers

Är sökbar kod viktig för dig?

Låt säga att det skall vara viktigt och hitta det mesta med att söka i koden, använda ett regex uttryck

Om sökbarhet är viktigt, hur skriver du kod så den är lätt att hitta

Det duger rätt bra det som finns. Man kan göra det mest i C till och med men det blir en hel del kod.
C++ har väldigt bra sätt att skriva smart kod, så var det redan på 1990 talet. Är man duktig på pekare och minnet kan du göra massor med lite. Backar du än mer gick det att skriva "självmodiferande kod", alltså kod som skrev om assemblerinstruktioner och det är otroligt hur mycket de fick in med lite kod om den tekniken används.

I C++ så det mesta nytt som kommer nu är för att trolla bort minneshantering och en del vill ha det, för mig är det mindre viktigt.
Förbättringarna i kompilatorer är viktigare och den utvecklingen har ju förbättrat för alla. Att kompilatorn vet så mycket mer och man kan ta hjälp av av den.

C++11 var den största uppdateringen och det beror framförallt på move konstruktorn. Annars är det mest syntaktiskt socker.
För C++ 26 ser jag fram emot reflection och att assert blir en del av språket. De två sakerna är riktigt stora.
Med reflection tror jag en hel ny typ av bibliotek bli vanliga eftersom det går att utöka funktionalitet.

Så här:
Visar någon utvecklare mig kod så vill jag veta hur jag skall förstå koden utan att läsa koden. Jag vill att programmeraren förklarar för mig vilka principer som används, hur den designat så andra inte skall behöva gå in där.

Är det konstigt?

Låt säga att en utvecklare producerar i genomsnitt 100 rader kod per dag för att göra det enkelt och räkna. 2000 rader i månaden eller drygt 20 000 rader på ett år. Inte något extremt alls men skall man behöva läsa den koden för att förstå hur den fungerar, då går det inte. Trots relativt medioker hastighet kommer en enda utvecklare orsaka onödig tid för andra.

Om utvecklaren inte klarar förklara hur jag snabbt skall hitta saker och förstå hur jag arbetar med koden så visar jag gärna exempel på hur man kan göra. 200 rader per dag klarar de flesta med bra teknik.

Stänga av gör jag inte men exception är ett nybörjarfel. Aldrig använda det. Enda gången exception används är om det ligger i extern kod och man inte har något val eller om det skiter sig totalt, finns ingen återvändo. Kanske att minnet är slut

Absolut är det så och givetvis måste jag vara öppen för att det finns andra sätt och skriva kod även om man lärt sig en del under alla år. Att det finns motstånd i att skriva kod på olika sätt är givetvis något som alla utvecklare råkat på, även jag. Kan inte räkna antalet diskussioner man haft i ämnet.
Den lösningen jag försöker få till är att ge någon en svårare uppgift och be den lösa det. Klaras inte lösningen kan jag ge tips för oftast handlar det om teknik, inte skicklighet.
Saknar man "mönster" i hur kod skrivs så har alla en gräns, det går inte att minnas hur mycket som helst även om någon har riktigt hästminne. Klarar de själva inte att minnas eller trasslar till det, hur skall då andra klara det?

Om de testar en annan teknik, kanske med tips och klarar uppgiften. Då brukar det släppa men inte säkert. Att skriva kod som man "själv vill" är ibland svårt att släppa

Hungarian Notation som jag förordar är inte för att det är något jag gillar eller tycker är snyggt. Det är en objektiv observation över hur effektiv stilen är. Tror till och med att man lätt skulle kunna mäta hjärnans syreförbrukning och få svart på vitt.

Minnesläckor använder nog alla C++ utvecklare verktyg för, vi kör valgrind i molnet men lokalt så AddressSanitizer och LeakSanitizer på linux, de har bråkat en del i Windows så varit lite egenutvecklat där.

Kan säga orsaken till varför det var så "stort" för mig.
STL gick inte och använda innan move kom eftersom det var för segt.
Har faktiskt utvecklat ett helt eget stl (med tankar) från det riktiga stl, i början på 2000 talet. Andra bibliotek hade alltid med sträng klasser med referensräknare istället för att kopiera och det fanns annat som vart problematiskt med stl.

Koden var för osmidig om man hade krav på prestanda

Efter C++11 gick det att använda stl och fördelen med det är att man själv inte behövde underhålla lika mycket kod

om någon förklarar hur man kan skriva lika smidig kod som det går med språk där metoder kan överlagras så skall jag fundera på det igen.

Självklart är det funktionalitet som är bra, gör koden mer lättarbetad med det är mest godis
constexpr är super, auto används sparsamt i produktionskod, men smidigt i lek-kod

objekten i stl, säkert bra för många men för egen del är det mindre viktigt.

Det här skulle jag gärna testa. Skulle säkert kunna lära mig mycket av det. Vad pratar vi om för slags problem?

Hungarian notation ser extremt fult ut men jag kan tänka mig att det har sina fördelar. Jag tycker att

m_

är väldigt bra även fast det också är fult. I Rust så skriver man alltid

self

innan member variabeln så det skulle inte göra någon skillnad där men i C++ blir det mycker mer lättläst.

Bra det. Min personliga åsikt är att minne inte är så stort problem som många säger. Därmed inte sagt att jag vill skriva kod med råa pekare överallt, men jag tror att med rätt verktyg så kan man undvika de flesta problemen. Det ska dock sägas att det kräver arbete för att sätta upp dessa verktyg också och så ska man tolka resultaten och hitta lösningar. Rust är lite mer plug-and-play i det att kompilatorn helt enkelt inte kompilerar koden. Minnessäkerhet i Rust är för mig en bonus och inte främsta anledningen till att jag använder språket.

Macron klarar av att ta okänt antal argument lite liknande variadic macros i C. Som redan nämnts så kan du använda builder pattern också. Du har pratat mycket om lättläst kod. Tycker du att kod som överlagrar är lättläst? Jag tycker personligen att sån kod är svårare att läsa. Som jag nämnt några gånger så är Rust mer explicit och försöker vara lättare att läsa på bekostnad av mer verbos kod. Överlagring av funktioner kommer nog aldrig komma till Rust pga. det tankesättet.

Känner du till begreppet data orienterad design?

Att det är lättare att läsa kod utan att överlagring tror jag beror på ddd (Domain driven design) och det stämmer för dör styr domänen kodens namngivning.

DDD är enklare att läsa men producerar mängder av kod.
DOD genererar inte alls lika mycket kod och återanvändning av kod är mycket bättre. Också en orsak till att unittester inte behövs. Samma kod
körs hela tiden

Massor
Återkommer i ämnet

DOD är inte lätt men när det klickar kommer du aldrig gå tillbaka till DDD (som är det vanliga). Klickar det inte så fundera en del, sök och så. Det brukar ta ett tag för de flesta. Samma för mig. Man behöver ha saker och relatera till, kanske jämföra två olika lösningar.

Data orienterad design

Här är de primitiva typer som en modern processor har och orsaken till varför jag listar dem är för att det är de här typerna programmerare har att arbeta med. Skall processorn klara av att göra vettiga saker åt användare måste användarnas önskemål konverteras till de primitiva typer som processorn förstår.

1 - bool: 1 byte (true/false)
2 - char: 1 byte (signed, -128 to 127)
3 - unsigned char: 1 byte (0 to 255)
4 - short: 2 bytes (signed, -32,768 to 32,767)
5 - unsigned short: 2 bytes (0 to 65,535)
6 - int: 4 bytes (signed, -2,147,483,648 to 2,147,483,647)
7 - unsigned int: 4 bytes (0 to 4,294,967,295)
8 - long: 4 or 8 bytes (typically 8 on 64-bit, signed, -2^63 to 2^63-1)
9 - unsigned long: 4 or 8 bytes (typically 8 on 64-bit, 0 to 2^64-1)
10 - long long: 8 bytes (signed, -2^63 to 2^63-1)
11 - unsigned long long: 8 bytes (0 to 2^64-1)
12 - float: 4 bytes (IEEE 754 single precision)
13 - double: 8 bytes (IEEE 754 double precision)

Vad vi programmerare gör är att flytta data från och till användare i olika steg och det måste till programmerare för det är svårt att konvertera en användares verklighet till något som fungerar på datorn.

De allra flesta utvecklare skriver DDD kod och det är enklare att förstå sådan kod eftersom den koden anpassar sig efter användarens domän, alltså en mänsklig värld. DOD är svårare då det där handlar om processorns värld, programmeraren måste tänka som processorn gör.

DOD brukar först användas när programmerare tvingas till det. Det kan handla om prestanda, exempelvis är det vanligt i Spel eftersom man där måste anpassa sig efter processorn för att ha max hastighet. DOD är också viktigt för att klara av och skriva MYCKET kod, hantera komplex kod. Där handlar det framförallt att klara av och isolera delar och använda DOD för att transportera data mellan delarna. DOD är också effektivt för att skriva återanvändbar kod.

Nedan följer ett så enklast möjliga exempel för att visa hur en struct konverteras till DOD. I början är structen DDD (ett POD = Plain Old Data) som ofta används för att skicka information mellan metoder.

Steg 1

struct data {
   int iId;
   bool bActive;
   double dValue;
};

//Serialisera data
iId >> bActive >> dValue

Skall data skickas mellan olika metoder eller delar i koden måste kod hårdkodas. Det går inte att lista ut vad det är för data som kommer annat än att kompilatorn instrueras hur structen ser ut. Alternativt att programmerare beskriver för annan programmerare.

Structen görs om för att få lite mer metadata (beskrivande data)

Steg 2

struct data {
   int iIdType 
   int iId;
   int iActiveType
   bool bActive;
   int iValueType
   double dValue;
};

//Serialisera data
iIdType >> iId >> iActiveType >> bActive >> iValueType >> dValue

Nu har ett värde lagts till för varje _riktigt_ värde och syftet med det är att de extra värde som finns för varje variabel skall hålla information om vad det _riktiga_ värdet är. Varje värde börjar med typen och då kan det vara ett nummer för varje primitiv typ, nästa värde är det riktiga värdet.

Skall den här datan skickas mellan olika delar går det nu att skriva lite mer generell kod, det är fortfarande problem med vad varje värde skall användas till men det är tillräckligt för att en utvecklare och kunna "läsa" koden, samla in den alltså utan att kompilatorn vet eller man behöver prata med annan programmerare. Det krävs fortfarande domänkunskap. Structen är bökigare däremot så i steg tre kommer en större omskrivning. Tog hjälp av AI för att generera kod så därav lite annan syntax

Steg 3

// Enum to represent the supported primitive types
typedef enum {
    TYPE_INT,
    TYPE_BOOL,
    TYPE_DOUBLE,
    TYPE_CHAR,
    TYPE_SHORT,
    TYPE_UNSIGNED_INT,
    TYPE_LONG,
    TYPE_UNSIGNED_LONG,
    TYPE_LONG_LONG,
    TYPE_UNSIGNED_LONG_LONG,
    TYPE_FLOAT,
    TYPE_LONG_DOUBLE
} TypeTag;

// Union to hold the value of any primitive type
typedef union {
    int i;
    bool b;
    double d;
    char c;
    short s;
    unsigned int ui;
    long l;
    unsigned long ul;
    long long ll;
    unsigned long long ull;
    float f;
    long double ld;
} PrimitiveValue;

// Struct to represent a variant (value + type)
typedef struct {
    TypeTag type;
    PrimitiveValue value;
} Variant;

// Updated struct using the custom variant
typedef struct {
    Variant id;
    Variant active;
    Variant value;
} CustomVariantData;

// Helper function to initialize a Variant
Variant CreateVariant(TypeTag type, PrimitiveValue value) {
    Variant var;
    var.type = type;
    var.value = value;
    return var;
}

// Helper function to get type name as a string (for debugging)
const char* GetTypeName(TypeTag type) {
    switch (type) {
        case TYPE_INT: return "int";
        case TYPE_BOOL: return "bool";
        case TYPE_DOUBLE: return "double";
        case TYPE_CHAR: return "char";
        case TYPE_SHORT: return "short";
        case TYPE_UNSIGNED_INT: return "unsigned int";
        case TYPE_LONG: return "long";
        case TYPE_UNSIGNED_LONG: return "unsigned long";
        case TYPE_LONG_LONG: return "long long";
        case TYPE_UNSIGNED_LONG_LONG: return "unsigned long long";
        case TYPE_FLOAT: return "float";
        case TYPE_LONG_DOUBLE: return "long double";
        default: return "unknown";
    }
}

Här har en eget variant objekt skapats, det håller en typ och ett värde. Nu kan man börja bygga kod kring detta typsystemet och därmed öka återanvändningen. Investerad tid i kod behöver inte kastas bort. Programmerare behöver inte diskuera med varandra eller skriva dokumentation om hur olika data ser ut och skickas.

Lösningen kräver fortfarande domänkunskap, det enda vi trollat bort är vi kan ersätta POD (plain old data) objekt med ett enda (en lista med varianter). Men principen handlar om det ovanstående. Det går att öka på i flera steg men då blir det lite mer komplext här och mycket mer kod.

Poängen med DOD är annars att anpassa lösningar så att de är anpassade efter hur datorer tänker. Så länge kod är anpassad efter det så exploderar den inte i storlek. Med en del träning kan utvecklare göra otroligt dynamiska lösnignar med relativt lite kod. Och eftersom återanvändningen är så hög blir koden snabbt säker. Det här är också orsaken till varför DOD kod inte behöver unittestas.

Ett till om DOD eller rättare sagt en video som om man ser den första gången så bli inte förvånad om man inte fattar något alls.

Videon bör ses flera gånger

Mike Acton är svår i videon och orsaken är att han inte är någon talare, han är ingenjör. Det är stor skillnad på att vara verbalt begåvad och talangfull programmerare.
För varje duktig talare inom programmering går det minst 10, kanske 100 introverta programmerare som är verbala katastrofer men bättre på att programmera.
Viktigt att förstå det när man läser på eller tittar på tutorials och annat för att lära sig.

Mike Acton förstår inte att det som är lätt för honom är supersvårt för andra och han vräker ut tips i videon utan att det följer något mönster. Så för att hänga med så titta flera gånger.

Videon är 10 år gammal med, det han säger är inte samma idag för mycket har blivit bättre sett till kod.

Inte säker på att jag förstår din text så ursäktar för att jag misstolkat.

En dator (processorn) vet inte vad text är. Skriver du siffran "10" har en dator ingen aning om att det är siffran 10. Man måste konvertera till något som kan användas av processorn och då har de flesta operativsystem ett system där varje tecken har en kod (ASCII systemet). Brukar också följa med generell kod i de flesta språken, exempelvis "atoi" för C. Den metoden läser av varje byte i texten "10" och gör om det till ett tal dagorn förstår. Eller tvärtom "itoa" så gör det om till något användaren förstår.

Står det då "EhundraTrettionTre" i en datapost så förstår vi det för de flesta kan läsa text, de flesta har lärt sig det i skolan. Text för människor är en teknik för att transportera information så vi förstår varandra. Vi måste ha ett transportformat för vi kan inte läsa varandras tankar.

Går säkert att söka fram hur det växt fram men ordet "domän" som det bygger på, synonym för domän är
kronogods, jordagods, större lantegendom; jordområde, skogsområde, egendom, mark, område; verksamhetsfält, fack, specialitet, genre, gebit, revir, fögderi;

Domän är brett och som du skrev i någon tidigare post, "flummigt" tror jag. DDD är ofta hårdkodade lösningar för att snabbt lösa någon specifik funktionalitet, ofta företag som anlitar konsulter och de har begränsad tid att lösa företagets problem (något i det företagets "domän").
DDD används då eftersom det gör att företag och utvecklare kan prata med varandra. Utvecklaren är inte bara utvecklare utan behöver också sätta sig in i hur företaget arbetar. När utvecklaren vet det kan utvecklaren skapa en lösning som förhoppningsvis förenklar.

Det finns gott om personer på nätet som försöker producera content, detta gör de för att locka läsare/tittare. Har då någon spelprogrammerare visat hur de optimerar koden så tror andra som bara vill producera content att "jaha det är så det är",
Det du visar är typiskt, exempel på hur de konverterar data för att datan skall bli cachevänlig i spel och då man har väldigt många objekt som de ofta har när de ritar upp nätverket för en bild.

DOD är också flummigt, finns vad jag vet inget "det här är DOD"

Annars så det jag försökte visa var hur man kan plocka bort POD structs och skriva generell kod

det går att utöka

enum enumType
{
   eTypeUnknown      = eTypeNumberUnknown,
   eTypeBool         = eTypeNumberBool       | eTypeGroupBoolean  | eTypeGroupSize08,
   eTypeInt8         = eTypeNumberInt8       | eTypeGroupInteger  | eTypeGroupSize08   | eTypeGroupSigned,
   eTypeInt16        = eTypeNumberInt16      | eTypeGroupInteger  | eTypeGroupSize16   | eTypeGroupSigned,
   eTypeInt32        = eTypeNumberInt32      | eTypeGroupInteger  | eTypeGroupSize32   | eTypeGroupSigned,
   eTypeInt64        = eTypeNumberInt64      | eTypeGroupInteger  | eTypeGroupSize64   | eTypeGroupSigned,

   eTypeInt128       = eTypeNumberInt128     | eTypeGroupInteger  | eTypeGroupSize128,
   eTypeInt256       = eTypeNumberInt256     | eTypeGroupInteger  | eTypeGroupSize256,
   eTypeInt512       = eTypeNumberInt512     | eTypeGroupInteger  | eTypeGroupSize512,

   eTypeUInt8        = eTypeNumberUInt8      | eTypeGroupInteger  | eTypeGroupSize08,
   eTypeUInt16       = eTypeNumberUInt16     | eTypeGroupInteger  | eTypeGroupSize16,
   eTypeUInt32       = eTypeNumberUInt32     | eTypeGroupInteger  | eTypeGroupSize32,
   eTypeUInt64       = eTypeNumberUInt64     | eTypeGroupInteger  | eTypeGroupSize64,

   eTypeUInt128      = eTypeNumberUInt128    | eTypeGroupInteger  | eTypeGroupSize128,
   eTypeUInt256      = eTypeNumberUInt256    | eTypeGroupInteger  | eTypeGroupSize256,
   eTypeUInt512      = eTypeNumberUInt512    | eTypeGroupInteger  | eTypeGroupSize512,

   eTypeCFloat       = eTypeNumberFloat      | eTypeGroupDecimal  | eTypeGroupSize32,
   eTypeCDouble      = eTypeNumberDouble     | eTypeGroupDecimal  | eTypeGroupSize64,
   eTypePointer      = eTypeNumberPointer,
   eTypeGuid         = eTypeNumberGuid       | eTypeGroupBinary   | eTypeGroupSize128,
   eTypeBinary       = eTypeNumberBinary     | eTypeGroupBinary,
   eTypeString       = eTypeNumberString     | eTypeGroupString,
   eTypeUtf8String   = eTypeNumberUtf8String | eTypeGroupString,
   eTypeWString      = eTypeNumberWString    | eTypeGroupString,
   eTypeUtf32String  = eTypeNumberUtf32String | eTypeGroupString,
   eTypeJson         = eTypeNumberJson       | eTypeGroupString,
   eTypeXml          = eTypeNumberXml        | eTypeGroupString,
   eTypeVoid         = eTypeNumberVoid,
   eTypeBit          = eTypeNumberBit        | eTypeGroupBoolean,

   eTypeRBinary      = eTypeNumberBinary     | eTypeGroupBinary  | eTypeDetailReference,
   eTypeRString      = eTypeNumberString     | eTypeGroupString  | eTypeDetailReference,
   eTypeRUtf8String  = eTypeNumberUtf8String | eTypeGroupString  | eTypeDetailReference,
   eTypeRWString     = eTypeNumberUtf8String | eTypeGroupString  | eTypeDetailReference

};