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

#include <string>

struct StructWithString {
    int int_val;
    double double_val;
    std::string string_val;
};

struct StructWithBuffer {
    int int_val;
    double double_val;
    char buffer[32];
};

Det där är inte kod - som i instruktioner till datorn.
Det där deklarationer av ett par structar. De gör kompilatorn ingenting med - deklarationer i sig översätts ju inte av kompilatorn till någonting alls.

Antalet klasser (om man nu envisas med objektorienterad programmering) skall inte vara baserat på hur man tror sig kunna optimera dem.
De klasser man har (och därmed antalet) skall baseras på vad som gör programstrukturen klar och redig och programmet begripligt.

De flesta optimeringar bör inte göras förrän efter att man konstaterat
a) Att optimeringar faktiskt behövs
b) Vad som tar tid, så man inte lägger tid på att optimera fel saker

Vad kompilatorer och processorer gör är ju baserat på den kod och data man matar in.
Det du presenterade var inte ens data - det var bara ett par deklarationer.

Utan kod så kan all data bara ignoreras av processorn. Är inget mer att göra eller förklara.

Nu pratar vi nybörjarnivå, men okej då.

Antag att vi har en funktion foo() som du tror skulle kunna göras snabbare om du lade ett par dagars jobb på det. Är det värt att göra?
Närmare undersökning visar att foo() tar 0.01 sekunder att köra, och körs endast en enda gång - nämligen under uppstarten av programmet.
Så är det värt att försöka minska tiden det tar för programmet att start med, i bästa fall, 0.01 sekunder. I de allra flesta fall är svaret nej.

Om man har obegränsat med tid så kan man ju försöka optimera varenda liten bit av den kod man skriver, men det har man vanligtvis inte.

Så man måste prioritera vad man använder sin tid till.

Man skall inte optimera saker som inte behöver optimeras - är koden redan tillräckligt snabb, och om den inte använder för mycket minne eller andra resurser, ja då behöver den inte optimeras utan man kan ägna sin tid åt viktigare saker.

Om koden behöver optimeras, då får man börja med att mäta och profilera för att ta reda på var i koden optimeringar skulle göra mest nytta.
Var i koden spenderar processorn mest tid? Om programmet använder för mycket minne, vad används minnet till? Och så vidare.

Vissa optimeringar kan man göra redan innan man skriver kod, nämligen vid val av algoritmer och datastrukturer. Man kan kanske inte göra ett optimalt val redan då, men man kan undvika många dåliga val.
Behöver man till exempel sortera en större mängd tal så är det nästan alltid bättre att använda quicksort än att använda bubblesort. Kan finnas bättre val, men vi vet att bubblesort är en av de sämre sorteringsalgoritmerna, och att quicksort är en relativt bra algoritm.
Har man data som man ofta behöver söka i, så är det lätt att inse att en länkad lista är ett dåligt val för hur man lagrar datat, så att man bör välja en lämpligare datastruktur.
Och så vidare.

Allt det här är sånt som du redan borde kunna. Det är sånt som alla som programmerar yrkesmässigt bör känna till.

Nu pratar du om hur structarna fråga används - vilket inte går att avgöra bara genom att titta på structarna själva.

Det är stor skillnad på om en klass instantieras bara ett par gånger under programmets livstid eller om det görs tiotusentals eller fler gånger.
I det förra fallet så spelar är exekveringstiden för konstruktor/destruktor oftast irrelevant. I det senare fallet kan det spela stor roll - eller inte göra någon märkbar skillnad.

Det beror ju på hur koden ser ut till att börja med! Så det kan jag inte beskriva i generella termer.
Att ta fram ett icke-trivialt exempel som demonstration skulle ta mycket mer tid och energi än jag är villig att spendera på dig.

#include <string>

struct StructWithString {
    int int_val;
    double double_val;
    std::string string_val;
};

struct StructWithBuffer {
    int int_val;
    double double_val;
    char buffer[32];
};

Vad är din poäng här? För gissar att du vill få det till att det senare fallet med en buffer (den som hanterar strängar så där med C++ 2025 borde få gå någon form av kurs...) skulle vara snabbare.

Låt oss skriva en benchmark

#include <benchmark/benchmark.h>

#include <algorithm>
#include <array>
#include <cstddef>
#include <cstdint>
#include <cstring>
#include <random>
#include <string>
#include <string_view>
#include <vector>

struct StructWithString {
    int int_val;
    double double_val;
    std::string string_val;
};

struct StructWithBuffer {
    int int_val;
    double double_val;
    char buffer[32]; // NUL-terminated
};

static inline char random_ch(std::mt19937_64& rng) {
    static constexpr std::string_view alphabet = "abcdefghijklmnopqrstuvwxyz0123456789";
    std::uniform_int_distribution<int> dist(0, static_cast<int>(alphabet.size() - 1));
    return alphabet[static_cast<std::size_t>(dist(rng))];
}

static inline std::string random_token(std::mt19937_64& rng) {
    std::uniform_int_distribution<int> len_dist(10, 20);
    int len = len_dist(rng);
    std::string s; s.resize(static_cast<std::size_t>(len));
    for (int i = 0; i < len; ++i) s[static_cast<std::size_t>(i)] = random_ch(rng);
    return s;
}

static inline void fill_buffer_from(std::mt19937_64& rng, char (&buf)[32]) {
    std::string s = random_token(rng);
    std::memset(buf, 0, sizeof(buf));
    std::memcpy(buf, s.data(), s.size());
    buf[s.size()] = '\0';
}

static inline std::size_t buf_len(const StructWithBuffer& x) {
    return ::strnlen(x.buffer, sizeof x.buffer);
}

static inline bool less_string(const StructWithString& a, const StructWithString& b) {
    const auto la = a.string_val.size();
    const auto lb = b.string_val.size();
    if (la != lb) return la < lb;
    return a.string_val < b.string_val;
}

static inline bool less_buffer(const StructWithBuffer& a, const StructWithBuffer& b) {
    const auto la = buf_len(a);
    const auto lb = buf_len(b);
    if (la != lb) return la < lb;
    // same length: lexicographic compare of exactly la bytes
    const int cmp = std::memcmp(a.buffer, b.buffer, la);
    return cmp < 0;
}

static void BM_Vector_WithString(benchmark::State& state) {
    const std::size_t N = static_cast<std::size_t>(state.range(0));
    // Fixed seed for reproducibility (use random_device() for variability)
    std::mt19937_64 rng(0xC0FFEEULL);

    for (auto _ : state) {
        std::vector<StructWithString> v;
        v.reserve(N);
        for (std::size_t i = 0; i < N; ++i) {
            StructWithString s;
            s.int_val = static_cast<int>(i);
            s.double_val = static_cast<double>(i) * 0.5;
            s.string_val = random_token(rng);
            v.emplace_back(std::move(s));
        }

        std::sort(v.begin(), v.end(), less_string);

        benchmark::DoNotOptimize(v.data());
        benchmark::ClobberMemory();
    }

    state.SetItemsProcessed(static_cast<int64_t>(state.iterations()) * static_cast<int64_t>(N));
}

static void BM_Vector_WithBuffer(benchmark::State& state) {
    const std::size_t N = static_cast<std::size_t>(state.range(0));
    std::mt19937_64 rng(0xBADC0FFEEULL);

    for (auto _ : state) {
        std::vector<StructWithBuffer> v;
        v.reserve(N);
        for (std::size_t i = 0; i < N; ++i) {
            StructWithBuffer s{};
            s.int_val = static_cast<int>(i);
            s.double_val = static_cast<double>(i) * 0.5;
            fill_buffer_from(rng, s.buffer);
            v.emplace_back(s);
        }

        std::sort(v.begin(), v.end(), less_buffer);

        benchmark::DoNotOptimize(v.data());
        benchmark::ClobberMemory();
    }

    state.SetItemsProcessed(static_cast<int64_t>(state.iterations()) * static_cast<int64_t>(N));
}

// Register with a useful size sweep
BENCHMARK(BM_Vector_WithString)->RangeMultiplier(4)->Range(1 << 8, 1 << 16);
BENCHMARK(BM_Vector_WithBuffer)->RangeMultiplier(4)->Range(1 << 8, 1 << 16);

BENCHMARK_MAIN();

Resultat på en modern CPU med en modern C++ kompilator? Well, den första med std::string är så klart snabbare! Vilket garanterat INTE hade varit fallet om vi kört med 90-tals CPUer och 90-tals C++-nivå på kompilatorer.

Ändrade till slumpmässigt från 1 till 31 tecken, för en av varianterna är inte så "säker" om man har längre strängar. Ändrar inget vad det gäller vilken som är snabbast

För att anknytna till trådens egentliga ämne - minnessäkerhet i C++ - så är det ju minnessäkerhet en stor anledning till att använda std::string istället för en fix buffer.
Använder man std::string för strängar så slipper man manuellt kontrollera att man inte försöker skriva utanför bufferten, och man slipper fundera över vad man skall göra om man får en för lång sträng som skall in där. Två källor till potentiella buggar som helt försvinner. Bara det är en tillräcklig anledning till att välja std::string.

I de fall man har många riktigt korta strängar så kan man ju faktiskt spara lite minne med att använda std::string. Istället för att slösa 32 bytes på varje buffer när merparten av strängarna kanske bara är 3-4 tecken långa så får man mer effektivt utnyttjande av minne.

Vilka anledningar kan man då ha att använda en buffer med fix storlek för att lagra strängar istället för att använda std::string?
Den främsta anledningen är nog okunskap, följt av ohejdad ovana ("så har jag alltid gjort!").

En av de få vettiga anledningarna till att använda en buffert vore väl om det egentligen inte är strängar man skall lagra utan någon form av binärdata som tar exakt 32 bytes. Om den data som skall lagras kan innehålla bytes med värdet 0 så är ju en sträng kanske inte så lämplig att använda.
En annan vettig anledning kan ju vara om man måste matcha något externt definierat format - t.ex. ett filformat eller ett nätverksprotokoll.

Att använda en buffer av fix storlek för att lagra strängar av variabel längd är lite som att använda en skruvmejsel för att slå i en spik.
Det är inte rätt verktyg för jobbet, men det är bättre än inget verktyg alls.

OK, "I did yank your chain a bit". Det relevanta här var att posterna använda längd som primär sorterings nyckel. std::string räknar ut det en gång medan C-style strängar måste räkna ut det varje gång.

Fast nästan själv lite förvånad över att det (ytterst marginellt) tiltar över för std::string även om man bara sorterar på innehåll i strängen. Samtidigt, det är nog kanske ändå förväntat för de som designat std::string har nog applicera fler "tricks in the book" än man först gissar

Detta är om innehållet i strängar används som sorteringsnyckel

Sen till frågan: finns det någon anledning att använda buffertar?
Kan egentligen bara komma på ett enda fall där det är det bättre valet. Har man hårda realtidskrav kombinerat med "safety critical" domän så är det rätt vanligt att dynamisk minnesallokering bara är tillåtet vid systemstart (d.v.s. man måste allokera för "worst-case" direkt och det är en bug att anropa malloc/free, new/delete när programmet börja köra).

I det läget är en C-style buffert vettig då man ändå behöver ta höjd för "worst-case" längd på sträng.

Poängen är ändå: börjar du se att "optimera för cache-line storkel" och "antalet genererade assemblerinstruktioner" inte längre fungerar? Bl.a. så har den dator jag kör på inte 64-bytes cache lines, de är 128 byte (och var inte helt ovanligt med 16 bytes cache-line på en del enklare system jag jobbade med i embeddedvärlden för 10-20 år sedan).

För någon som, enligt egen utsago, skriver tusentals rader kod dagligen, så skriver du väldigt lite kod, och är väldigt snabb att ta till LLM.

Det var bara ett, av oändligt många, sätt man kan tänkas vilja sortera/klassificera/... sina poster. En poäng där var att just information om längden hos en sträng är rätt vanligt att man vill veta, men det saknades ju i din buffer-lösning och kostade extra att räkna ut varje gång.

Nu fixade du den grejen. Och visst kan du göra den fina optimering som @jclr gjorde, men passar inte något sådant bättre ihop med en CPU/ISA-specifik optimering för std::string i delen som används för small-string optimization (efter som för att göra sådant måste man vara säker att när man läser förbi '\0' så får man bara läsa sådant som är garanterat "safe", vilket det är om man sagt åt kompilatorn "det finns alltid 32 bytes" här, men det är inte safe för en char* då '\0' skulle kunna ligga precis på en page-gräns och virtuella adressen efter är inte mappad. Nu går även det att reda ut om man vet storlek på page:es, men det börjar kanske så man fokuserar på fel sak).

10-20 i längd
Performance comparison: String vs Buffer (with optimizations)
==============================================================

Testing with N = 256 elements:
String sort (N=256): 55 μs
Buffer sort SLOW (N=256): 154.6 μs
Buffer sort FAST (N=256): 59.8 μs
Speedup from using stored length: 1.66292x

Testing with N = 1024 elements:
String sort (N=1024): 227.6 μs
Buffer sort SLOW (N=1024): 549.2 μs
Buffer sort FAST (N=1024): 327.8 μs
Speedup from using stored length: 1.88702x

Testing with N = 4096 elements:
String sort (N=4096): 1850.6 μs
Buffer sort SLOW (N=4096): 1928 μs
Buffer sort FAST (N=4096): 1274.8 μs
Speedup from using stored length: 1.92651x

Testing with N = 16384 elements:
String sort (N=16384): 7289.8 μs
Buffer sort SLOW (N=16384): 6709.4 μs
Buffer sort FAST (N=16384): 4087.6 μs
Speedup from using stored length: 1.65404x


25-31 i längd
Performance comparison: String vs Buffer (with optimizations)
==============================================================

Testing with N = 256 elements:
String sort (N=256): 67.6 μs
Buffer sort SLOW (N=256): 63.2 μs
Buffer sort FAST (N=256): 46.6 μs
Speedup from using stored length: 2.78333x

Testing with N = 1024 elements:
String sort (N=1024): 444.2 μs
Buffer sort SLOW (N=1024): 384.6 μs
Buffer sort FAST (N=1024): 213.2 μs
Speedup from using stored length: 2.92431x

Testing with N = 4096 elements:
String sort (N=4096): 1502.2 μs
Buffer sort SLOW (N=4096): 1560.8 μs
Buffer sort FAST (N=4096): 1266.8 μs
Speedup from using stored length: 1.95623x

Testing with N = 16384 elements:
String sort (N=16384): 6707.6 μs
Buffer sort SLOW (N=16384): 7429 μs
Buffer sort FAST (N=16384): 5237.8 μs
Speedup from using stored length: 1.56811x


25-31 i längd med avx flagga
Performance comparison: String vs Buffer (with optimizations)
==============================================================

Testing with N = 256 elements:
String sort (N=256): 58.8 μs
Buffer sort SLOW (N=256): 61.2 μs
Buffer sort FAST (N=256): 44 μs
Speedup from using stored length: 2.38333x

Testing with N = 1024 elements:
String sort (N=1024): 249.6 μs
Buffer sort SLOW (N=1024): 274.6 μs
Buffer sort FAST (N=1024): 194 μs
Speedup from using stored length: 2.33242x

Testing with N = 4096 elements:
String sort (N=4096): 1065 μs
Buffer sort SLOW (N=4096): 1265.4 μs
Buffer sort FAST (N=4096): 858.4 μs
Speedup from using stored length: 1.96761x

Testing with N = 16384 elements:
String sort (N=16384): 4711 μs
Buffer sort SLOW (N=16384): 5462.8 μs
Buffer sort FAST (N=16384): 3607 μs
Speedup from using stored length: 1.90442x

Poängen är främst: varför lägga så mycket tid på en sådan sak? Det är redan ett löst problem och "small string optimization" finns av en väldigt bra anledning.

Du verkar gilla att uppfinna egna lösningar, som inte på något sätt verkar bättre än existerande lösning. Varför skrev du t.ex. om det google-benchmark redan gjort (och där det finns en hel del minor att kliva på, som vid det här laget lär vara röjda i just google-benchmark)?

Just std::string har fått en hel del optimeringar av "jättarna" (Meta, Google, m.fl.) just då de har kodbaser där prestanda för just strängar är viktigt. Man kan absolut ha extremt specifika behov som ändå gör att det krävs speciallösningar, men har verkligen det du jobbar det och om så: vore spännande att höra varför

BTW: om jag kör på Windows/i7-12700T/MSVC++ så kan jag rätt mycket reproducera ditt resultat. Kör jag på MacOS/M4/Clang++ så är båda varianterna rätt mycket exakt lika snabba (std::string är ytterst marginellt snabbare). Kör jag på Ubuntu/U5-225H/g++ hamnar man någonstans mitt emellan. Den här typen av "optimeringar" är rätt bräckliga, just det här fallet råkade det ändå bli så att din speciallösning i alla fall inte blev sämre. Men den är svårare att begripa, "ingen" kommer vara bekant med den och skulle antagligen inte behövas speciellt mycket fantasi för att hitta fall där den är långsammare än std::string.

Just standard-biblioteken är något man ska extremt goda skäl innan man byte mot speciallösnignar. Om man ofta har problem med standard-biblioteken jobbar man nog i en miljö som är illa anpassad till sin domän.

Och stötte också på en av orsakerna varför C++ aldrig slagit ut C inom många system-områden: försökte köra MacOS varianten med g++-15. Gick inte att länka då clang++ och varianten av g++-15 som finns i Homebrew producera icke-kompatibla bibliotek (kör med google-benchmark från Homebrew som är byggd med clang++)... Att inte standardisera ABI är en "WTF Bjarne???".

Du pratar också mycket om dina "tabeller" och hur de kan användas som en "databas i RAM".

Hur är det annorlunda och bättre än denna standardlösning (som kanske inte blir fullt lika "SQL-like" med C++ standardfunktioner, men går ändå att göra rätt 1:1 logiskt sett)?

public readonly record struct User(string Name, int Age) {}
public readonly record struct Event(int UserId, DateTime Start, DateTime End) {}
public readonly record struct UserEvent(string Name, int Age, DateTime Start, DateTime End) {}

class Program
{
    static void Main()
    {
        var users = new Dictionary<int, User>
        {
            [1] = new User("Alice", 30),
            [2] = new User("Bob",   28),
        };

        var now = DateTime.Today;
        var events = new Dictionary<int, Event>
        {
            [100] = new Event(1, now.AddHours(9),  now.AddHours(10)),  // Alice
            [101] = new Event(2, now.AddHours(8),  now.AddHours( 9)),  // Bob
            [102] = new Event(1, now.AddHours(13), now.AddHours(14)),  // Alice
            [103] = new Event(2, now.AddHours(11), now.AddHours(12)),  // Bob
            [104] = new Event(1, now.AddHours(15), now.AddHours(16)),  // Alice
        };

        var joined = events.Values
            .Join(users.Values, e => e.UserId, u => u.Id, (e, u) => new { e, u })
            .OrderBy(x => x.e.Start)
            .Select(x => new UserEvent(x.u.Name, x.u.Age, x.e.Start, x.e.End))
            .ToList();

        foreach (var ue in joined)
            Console.WriteLine($"{ue.Name} ({ue.Age})  {ue.Start:t}–{ue.End:t}");
    }
}

Fast C++ har tagit det ännu ett steg längre.

Helt OK att sizeof(int) är olika storlek med avseende på olika CPU-arch/OS-kombos. Det fanns absolut en logik bakom varför man gjorde det valet i C:s tidiga dagar.

Du nämner Swift och det finns ju till flera CPU-arch/OS-kombon och där har man likt C/C++ valt att sizeof(int) är 4 bytes på 32-bit och 8 bytes på 64-bit. Däremot har C# och Java båda valt att sizeof(int) alltid är 4 bytes.

Omvänt har C/C++ har infört int32_t, int64_t från ISO C99 och framåt.

Men i fallet C++ har man ju haft problemet att ett bibliotek kan vara inkompatibelt med din applikation trots samma CPU-arch/OS-kombo, men olika kompilatorer. C har inte det problemet.

Sen kan man absolut peka på att flera lite mindre språk kanske bara har en relevant tool-chain och då blir det såklart inget problem på en given CPU-arch/OS-kombo.

Nog rätt mycket programvara som aldrig fixat det mer ovanliga varianterna hos C. Har jobbat lite med DSP:er där minsta adresserbara enhet, det C/C++ definierar till en char, var 16-bits. Var rätt få saker som fungerade "out-of-the-box" till dessa...

Idag kan man rätt mycket klassa big-endian som "historia". Little-endian "vann" och även POWER som tidigare oftast var big-endian är idag little-endian. Undrar om det längre finns DPS/MCUer där minsta adresserbar enhet är något annat än 8-bitar?
Flera val som egentligen inte spelade någon relevant roll har tack och lov konvergerat, trots en stark "network-background" är jag ändå helt OK med little-endian som "vinnare" (network-byte-order och big-endian var ju synonymer).