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

Det där är ju struntprat från början till slut.

Det är ofta som en kompilator inte genererar optimal maskinkod. Inte ens C-kompilatorer. I synnerhet gäller det om man kompilerar utan alla optimeringsflaggor påslagna.
Moderna kompilatorer genererar oftast mycket bra maskinkod, men vad som är optimal kod varierar ju beroende på vilken CPU-modell den exekveras på, så i stort sett ingen genererad kod är alltid optimal.

Fortran har länge varit bättre för att generera snabb kod för stora numeriska beräkningar. C/C++ har långsamt närmat sig, men inte passerat.

Just den presentationen var skrivet av Bjarne och planen var att han skulle presentera det. Men saker kom emellan som gjorde att Herb drog den istället.

Och vad som presenteras där är rätt mycket vad _alla_ aktiva C++ programmerare jag känner anser är en självklarhet idag. Är din ståndpunkt, "det ska vara pre-C++11 style annars blir det inte bra" som är helmärklig IMNSHO.

unsafe är en opt-in funktion som gör att "allt" går att göra. Det som är så bra är att det just är opt-in, saker är "safe by default".

Och ofta klarar man sig rätt bra i safe-miljö. Lycka till att hitta något C++-ramverk som är enklare och mer effektivt än Rayon i Rust för att utnyttja multicore.

Så "rätt" sätt är "safe-by-default" och "effektivt". Är precis det Safe-C++ och TrapC också sägs uppnå.

Hur mycket assembler har du skrivit? Har skrivit hela spel i 68k assembler, gjort en del assembleroptimeringar (när sådant forfarande var relevant utanför SIMD) för OS till x86, ARM, MIPS, SPARC, PowerPC och ARM64. Har en rätt bra idé om vad en modern kompilator genererar, men det är egentligen helt irrelevant över: en modern kompilator kommer i majoriteten av fallen idag skriva minst lika bra kod som jag skulle handknacka (var väldigt länge sedan man kunde cykelräkna).

Precis som jag sedan länge är "glad" att slippa skriva i assembler är jag allt mer nöjd över att kunna ignorera C++ i stort sätt helt idag. Men finns ändå use-cases för C och C++, använder det trots allt fortfarande för mikrokontrollers.

Och diskussionen handlar inte om vad jag, eller rent allmänt någon specifik anser, utan vi diskuterar C++ framtid givet att bl.a. amerikanska staten rätt mycket säger "välj något annat än C/C++ för de är säkerhetshot, väljer du ändå dessa och det blir ett säkerhetshål anser vi att du är inkompetent och vi kommer stämma dig för detta".

De som vill se en framtid för C och C++ bör nog i alla fall fundera om det finns något man kan göra för att förbättra situationen.

Tycker personligen att Safe-C++ är fel väg att gå, detta då det ser så annorlunda ut från "modern C++1x" och ändå kräver en rewrite för att man ska dra nytta av det.

Tror TrapC kan vara rätt väg. Det kräver omkompilering och har "breaking changes", men slutreslutatet ser rätt mycket ut som "vanlig C" trots att det är "safe by default"! Detta kan vara rätt recept!

USA kan ju skrota vad dom vill men EU har fortfarande CRA och NIS2.

"Det finns ingen riktig Post längre...." (dom som vet, vet..)

Nu låter du ju bara som en gammal gubbe.

Som med nyare versioner av såväl operativsystem som andra program, om du vill kan du väl bara fortsätta använda dom äldre versioner av C++ som passar dig.

Om du är en så fantastisk utvecklare som du verkar mena att du är, så antar jag att du har en fantastisk produkt/tjänst och ingen av dina kunder kommer reagera på det.

(och det menar jag verkligen, jag fattar att stora statliga/kommunala aktörer kan vara viktiga kunder, och att ingången till den här tråden var att dom kanske ska börja kravställa utifrån språk (typ) och det tycker jag egentligen är en mer intressant diskussion, men 90% av kunderna skiter fullständigt i vilket språk din produkt är skriven i, bara den levererar.)

Det där är bevisligen fel. Det är just "bevisligen"-delen som har lett till en rejäl aktivitet på både C++- och C-sidan kring detta.

Under lång tid kunde man bara anta/gissa att Rust skulle minska antalet säkerhetsrelaterade problem. Inte en alltför vågad gissning, med tanke på att man redan såg att t.ex. Java och C#, som båda sedan länge varit mycket välanvända, hade långt färre problem. Men Rust var ändå speciellt eftersom det var det första programmeringsspråket utan GC och designat specifikt för systemprogrammering, vilket gav motsvarande garantier.

Nu, när det finns ett par större Rust-projekt som dessutom varit i drift ett tag, ser man att det faktiskt är precis så bra som man kunde hoppas på. Det normala är inte "en minskning med X %", utan noll rapporterade fel av den typ som plågar C och C++ extra mycket.

Det är också fel, även om det faktiskt skulle finnas C++-programmerare utsända av Gud som alltid gör allt 100 % rätt. Problemet är att ett opt-in-system gör att alla måste göra rätt för att inga fel ska uppstå. Det Rust visar (och som Safe-C++ och TrapC vill kopiera) är att när, inte om, man gör fel, så kommer kompilator och/eller runtime att fånga felet.

Det känns som att du helt missförstår vad som sägs, och dessutom verkar du förbise att allt fler företag inför liknande policyer, helt utan krav från regler eller lagar.

Det är helt enkelt ingen konkurrensfördel att skapa programvara med säkerhetshål.

Framförallt, vad jag har sett så här långt, är det ingen som säger "totalförbud mot C och C++". Det man säger är att dessa två språk aldrig längre ska väljas av slentrian, utan endast användas om det inte är realistiskt att göra andra val. I över 99 % av fallen betyder det "vi gör en utökning till något existerande som är skrivet i C eller C++; det är inte realistiskt att skriva om allt."

Det sista är fullt rationellt. Därför blir det otroligt spännande att följa DARPA-projektet, där de ska undersöka hur realistiskt det är att översätta stora mängder C och C++ med hjälp av LLMs till Rust. Detta projekt startar i mars 2025, det vill säga under denna månad.

Från TrapC-specifikationen (som släpptes i fredags)

"TrapC differs in approach from efforts to achieve memory safety by rewriting C code in Rust. Starting in March 2025, the DARPA TRACTOR “Translating all C to Rust” research project will attempt to use AI to translate C code wholesale into the equivalent Rust code. And, there are efforts to migrate C-to-Rust manually. Germany’s Soverign Tech Fund (STF) is a sponsor of FreeBSD, the Rustls TLS library written in Rust, and the uutils rewrite of the Linux coreutils library in Rust."

Som du ser finns också redan ett flöde mot Rust från C och C++. Så diskussionen kring "vad borde C och C++ gängen göra" är högst aktuell.

Och att C++ utvecklas relativt snabbt är bara ett större kontext av vad som diskuteras här.

varet på vad man borde göra är långt ifrån självklart. C och C++ har tagit olika vägar här – C är i praktiken ganska mycket fryst på C99 (bl.a. Microsoft har ignorerat att implementera C11; strikt taget har Visual Studio bara fullständigt stöd för C89, medan GCC/Clang har fullt C99-stöd, vilket bl.a. Linux-kärnan använder).

Du är långt ifrån ensam om att vägra C++11, a.k.a. "modern C++". När man använder C++1x fullt ut blir resultatet väldigt annorlunda än "your father’s C++".

Kritikerna mot att fortsätta lägga till nya saker i C++ har ändå en hel del bra argument. De viktigaste två är att C++-specifikationen redan är löjligt stor och komplex, samt att det tyvärr märks i att det blir allt svårare för kompilatortillverkarna att få ihop en kompilator som är någorlunda stabil och som faktiskt lyckas implementera hela standarden. Är väl ingen som har fullständigt stöd för något senare än C++17 än?

Angående Safe-C++ borde man definitivt följa DARAP-projektet. Om det ser lovande ut tycker jag att den rimliga slutsatsen borde bli: det finns ingen vettig anledning att försöka implementera Rust inom ramen för C++.

Även om det projektet blir ett rejält misslyckande bör man bestämma sig för vad som är viktigast framåt. Ska man fokusera på stabilitet (av toolchain och grundläggande ramverk) och likt C i stort sett frysa specifikationen, eller ska man försöka hålla C++ relevant även för nya green-field-projekt och då bl.a. hitta en lösning på säkerhetsproblemen, här vet vi att statisk analys och liknande inte räcker fullt ut. För att göra en bra lösning krävs förändring på språknivå.

Det är svårt att tolka det på ett annat vis när du refererar till språkguidelines för säkerhet som "dumheter".

Det är ingen som föreslagit ett totalförbud mot språk utan det handlar om att prioritera säkerhet över språk. Du kan ju fortsatt skriva i vilket språk du vill men om det går snett så kan din arbetsgivare hållas juridiskt ansvarig och behöva motivera bl a språkval. Speciellt om det är minnesrelaterat.

Självklart kommer andra språk att hållas ansvariga men jag misstänker att processen kommer blir enklare för företag som följer guidelines:en.

Som vanligt är jag late to the party här, men jag kan inte lämna detta oemotsagt.

Det är utan tvekan så att C-standarden är formulerad så att kompilatorimplementatörer skall ha möjlighet att generera effektiv kod i olika miljöer. Exempelvis, specas saker som evalueringsordning inom uttryck som unspecified behavior, här kan den optimerande kompilatorn välja den ordning som blir effektivast, medan storleken på int är implementation-defined behavior, så man kan välja en storlek som passar för den processor man vill köra på. Likaså är saker som tecken på resultatet på modulo med negativa tal och tecken på resultatet på högershift av en signed integer type implementation-defined behavior för att kompilatorn skall kunna välja det beteende de existerande instruktionerna har och slippa lägga ut extra kod för att se till att resultatet alltid är negativt/positivt. Men när vi kommer till "inte ljuga" är du helt ute och cyklar...

Jag saxar lite ur draften till C-standarden. (min fetstil):

5.1.2.3 Program execution

1 The semantic descriptions in this International Standard describe the behavior of an
abstract machine in which issues of optimization are irrelevant.

2 Accessing a volatile object, modifying an object, modifying a file, or calling a function
that does any of those operations are all side effects, which are changes in the state of
the execution environment. Evaluation of an expression may produce side effects. At
certain specified points in the execution sequence called sequence points, all side effects
of previous evaluations shall be complete and no side effects of subsequent evaluations
shall have taken place. (A summary of the sequence points is given in annex C.)

3 In the abstract machine, all expressions are evaluated as specified by the semantics. An
actual implementation need not evaluate part of an expression if it can deduce that its
value is not used and that no needed side effects are produced (including any caused by
calling a function or accessing a volatile object).

4 When the processing of the abstract machine is interrupted by receipt of a signal, only the
values of objects as of the previous sequence point may be relied on. Objects that may be
modified between the previous sequence point and the next sequence point need not have
received their correct values yet.

5 The least requirements on a conforming implementation are:

• At sequence points, volatile objects are stable in the sense that previous accesses are complete and subsequent accesses have not yet occurred.

• At program termination, all data written into files shall be identical to the result that execution of the program according to the abstract semantics would have produced.

• The input and output dynamics of interactive devices shall take place as specified in 7.19.3. The intent of these requirements is that unbuffered or line-buffered output appear as soon as possible, to ensure that prompting messages actually appear prior to a program waiting for input.

Standarden säger vad som skall hända, den nämner inte vad som inte skall hända utan lämnar det helt upp till kompilatorimplementatören. Det finns i standarden en massa shall not-meningar, men de handlar om vad man inte får göra i C som användare. Standarden säger till och med att den inte lägger sig i hur C-programmet omvandlas till något körbart.

This International Standard specifies the form and establishes the interpretation of
programs written in the C programming language. It specifies
— the representation of C programs;
— the syntax and constraints of the C language;
— the semantic rules for interpreting C programs;
— the representation of input data to be processed by C programs;
— the representation of output data produced by C programs;
— the restrictions and limits imposed by a conforming implementation of C.

This International Standard does not specify
— the mechanism by which C programs are transformed for use by a data-processing system;
— the mechanism by which C programs are invoked for use by a data-processing system;
— the mechanism by which input data are transformed for use by a C program;
— the mechanism by which output data are transformed after being produced by a C program;
— the size or complexity of a program and its data that will exceed the capacity of any specific data-processing system or the capacity of a particular processor;
— all minimal requirements of a data-processing system that is capable of supporting a conforming implementation

Det får hända hur mycket som helst vid sidan av det du ber om i ditt program. Så länge det som språkstandarden säger skall hända händer är det en giltig översättning och om ditt C-program är ett välartat C-program har programmet självt ingen möjlighet att avgöra huruvida det utförs extra instruktioner eller inte. Hur tror du verktyg som address sanitizer fungerar? Är det fortfarande en giltig översättning av ditt C-program när man slår på address sanitizer? Det kan vara värt att notera att om programmet gör en array-out-of-bounds-access så är vi in undefined behavior-land och det är helt standard conforming att programmet terminerar med ett felmeddelande.

DET är en väldigt bra fråga!

Som jag skrivit flera gånger redan: jag är inte alls övertygad om att Safe-C++ är rätt väg framåt, det just för att jag inte ser poängen att göra C++ till "Rust med C++-syntax".

Bjarne verkar inte heller helt övertygad (enligt honom är problemet redan löst bara man konsekvent håller sig till modern C++ och de guide-lines han, Herb, m.fl. lagt upp i C++ Core Guidelines).

De som vill få in stöd för detta i C++ gör det för att de anser (helt korrekt) att det finns C++-specifika problem som kan lösas om man förändrar språket. Frågan är vad bästa "nästa steg" är här.

En, i min mening fullt rimlig, väg är att säga "det ska vara så för värdet ligger i första hand att kunna underhålla existerande kod".

En annan är att "vi kommer tvinga bort folk från C++ om vi inte fixar de problem som bevisligen finns". Då är huvudfrågan vad man bäst gör för att hantera problemet. Safe-C++ (kraftig ändring i hur man skriver, opt-in, men fördel att existerande kod fungerar) och TrapC (liten till ingen förändring av kod, opt-out, all existerande kod måste byggas om för att dra nytta, breaking changes) är exempel på två olika vägar.

Absoluta sökvägar blir naturligtvis problematiskt, potentiellt även om det är samma OS på en annan dator.

Men vad är problemet med resten, framförallt givet att man redan använde std::filesystem?

Windows stödjer explicit både "/" och "\", det är även del av C++-17 att båda fungerar på Windows
https://en.cppreference.com/w/cpp/filesystem/path

Är det omvända som är problematiskt, när något Windows-specifikt-hack ska köras på *NIX.

Finns väl inget just där som är C++-specifikt? C#, Go, Java, Rust, Python, m.fl. kan ju också göra allt du visar här via deras respektive standardbibliotek.

Varför implementera det på egen hand? Det finns ju redan i standardbiblioteket

#include <filesystem>
#include <print>
namespace fs = std::filesystem;
int main()
{
    fs::path fn{"test////path/file.txt"};
    std::print("Initial filename = {}\n", fn.string());
    fn = fn.lexically_normal();
    std::print("Lexically normal filename = {}\n", fn.string());
}

Output på Windows

Initial filename = test////path/file.txt
Lexically normal filename = test\path\file.txt

Output på MacOS/Linux

Initial filename = test////path/file.txt
Lexically normal filename = test/path/file.txt

Nice! Men även det finns ju redan i std::filesystem, så vad är vinsten att replikera det?

Innan du gör fler galna utsagor om Rust: TESTA!
En av de klagomål nybörjare har är att Rust är extremt picky hur man skriver, många saker som "bara" blir dålig kod i t.ex. C++ vägrar ens att kompilera på Rust (mer vanligt relaterad till dålig hantering av minne och andra resurser, men ändå).

Du menar att folk som har dåliga ovanor har svårt för att göra sig av med dem? Kan man tänka sig.

Det finns tillfällen där det är inte bara vettigt utan till och med nödvändigt att pilla på specifika minnesadresser, eller bry sig om den interna representationen av olika objekt, men om man inte håller på med maskin-/arkitektur-specifika saker så blir program nästan alltid bättre av att man håller sig borta från sådant.

Får man fråga varför ni stödjer Windows 95/98/ME år 2025? För alla versioner av Windows NT har stöd för forward och backward slash. Eller du kanske menar att problemet egentligen inte ligger i Windows utan i bibliotek/program ni använder?

Nu är jag i en lite speciell situation just kring standardbiblioteket för C++11, 14 och 17 då jag behövt implementera dem på ett RTOS och därmed tragglat det mer än nog... Men nä, ser faktiskt noll poäng med den wrapper ni gör givet vad C++17 har för stöd i std::filesystem. Verkar mest vara ett fall för "not invented here syndrome", vilket i.o.f.s. inte är helt ovanligt.

Så du menar att typiska junior-misstag som att återuppfinna hjulet där det inte behövs uppfinnas skulle vara vanligare hos C++-programmerare?

Varför tror du AI-boomen är så totalt dominerat av Python och bibliotek som PyTorch och TensorFlow? Det är en svårt nog domän och genom rätt abstraktioner har man lyckas skapa extremt kraftfulla ramverk som, trots att de används från Python, presterar exceptionellt väl (typiskt hårt SIMD och multicore optimerade på CPU och kan väldigt enkelt även köras på GPGPU med ännu bättre prestanda).

Gillar personligen inte dynamiskt typade språk, vill ha en kompilator som pekar ut de uppenbara fallen där jag är en idiot. Men när det kommer till AI är det bara att acceptera att Python är det enda rätta, vare sig man vill få prestandan och framförallt om man vill få något relevant gjort på rimlig tid.

Och ja, de underliggande biblioteken är till stor del skrivna i C++. Men är exakt DET man ska använda abstraktioner till!

Vilket låter helt trivialt att uppnå med standardbiblioteket! Varför inte använda det då det lär hålla minst lika hög kvalité och det är garanterat mer portabelt än erat egenrullade.

Fast nu är just Rust, precis som C och C++, specifikt ett systemspråk som är flexibelt nog att skriva hela OS i och därmed bevisligen har alla tänkbara och de flesta otänkbara (då man kan skriva OS kan man även hantera hela MMU-delen via Rust, vilket är ungefär så "low-level" man lär kunna bli m.a.p. minneshantering).

OK, vad gör jag fel i hur boost::asio används i min "hello-world" HTTP-server?

#include <boost/asio.hpp>
#include <boost/beast.hpp>
#include <iostream>
#include <memory>
#include <thread>
#include <vector>

namespace asio = boost::asio;
namespace beast = boost::beast;
namespace http = beast::http;
using tcp = asio::ip::tcp;

class HttpSession : public std::enable_shared_from_this<HttpSession>
{
public:
    explicit HttpSession(tcp::socket socket) : socket_(std::move(socket)) {}

    void start()
    {
        read_request();
    }

private:
    tcp::socket socket_;
    beast::flat_buffer buffer_;
    http::request<http::string_body> request_;

    void read_request()
    {
        auto self = shared_from_this();
        http::async_read(socket_, buffer_, request_,
                         [self](boost::system::error_code ec, std::size_t)
                         {
                             if (!ec)
                                 self->handle_request();
                         });
    }

    void handle_request()
    {
        auto response = std::make_shared<http::response<http::string_body>>(http::status::ok, request_.version());
        response->set(http::field::content_type, "text/html");
        response->body() = "<h1>Hello, World!</h1>";
        response->prepare_payload();

        auto self = shared_from_this();
        http::async_write(socket_, *response,
                          [self, response](boost::system::error_code ec, std::size_t)
                          {
                              self->socket_.shutdown(tcp::socket::shutdown_send, ec);
                          });
    }
};

class HttpServer : public std::enable_shared_from_this<HttpServer>
{
public:
    static std::shared_ptr<HttpServer> create(asio::io_context &ioc, unsigned short port)
    {
        auto server = std::shared_ptr<HttpServer>(new HttpServer(ioc, port)); 
        server->start_accept();                                            
        return server;
    }

private:
    tcp::acceptor acceptor_;
    tcp::socket socket_;

    HttpServer(asio::io_context &ioc, unsigned short port)
        : acceptor_(ioc, tcp::endpoint(tcp::v4(), port)), socket_(ioc)
    {
    }

    void start_accept()
    {
        auto self = shared_from_this();
        acceptor_.async_accept(socket_, [self](boost::system::error_code ec)
                               {
                                   if (!ec)
                                   {
                                       std::make_shared<HttpSession>(std::move(self->socket_))->start();
                                   }
                                   self->start_accept();
                               });
    }
};

int main()
{
    try
    {
        const unsigned short port = 8081;
        const int thread_count = std::thread::hardware_concurrency();

        asio::io_context ioc(thread_count);
        auto server = HttpServer::create(ioc, port);

        std::vector<std::thread> threads;
        for (int i = 0; i < thread_count; i++)
        {
            threads.emplace_back([&ioc]()
                                 { ioc.run(); });
        }

        std::cout << "Server running on port " << port << " with " << thread_count << " threads.\n";

        for (auto &thread : threads)
        {
            thread.join();
        }
    }
    catch (const std::exception &e)
    {
        std::cerr << "Server error: " << e.what() << std::endl;
    }
}

Detta gör rätt mycket samma sak skrivet med Go:s extremt väloptimerade standardbibliotek för HTTP

package main

import (
	"fmt"
	"net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintln(w, "<h1>Hello, World!</h1>")
}

func main() {
	port := 8080
	fmt.Printf("Server running on port %d...\n", port)

	http.HandleFunc("/", handler)
	err := http.ListenAndServe(fmt.Sprintf(":%d", port), nil)
	if err != nil {
		fmt.Println("Server error:", err)
	}
}

Skrev detta på väldigt kort tid och är långt ifrån någon expert på boost::asio. Du får gärna ge tips för Go-versionen är inte bara löjligt mycket enklare, den hanterar också runt x3 fler transaktioner per tidsenhet (Go:s "killer feature" är extremt bra I/O-prestanda, så är i.o.f.s. inte förvånad).

Nu trollar du igen...

Detta är raka motsatsen till ett av dina tidigare argument när du yrat om stora kodbaser och vikten av att återanvända kod. Nu säger du att man inte ens ska återanvända standard libet och hacka ihop egen funktionalitet.

Än en gång, undrar jag varför du envisas med att köra C++? C har ännu smalare standard lib och tvingar dig att implementera mer så varför inte köra C?

Vilken krock och vilka paradigm ska separeras?

Detta är nog något av det dummaste jag hört. Kan du förklara hur du tänker och ge exempel här gällande abstraktioner?

Vad är det för pinsamt agg du har mot Python... ?

Vi har sagt fler gånger att du kan pilla på minnet i Rust om nu har sådana krav... Det finns motsvarande memset och memcpy i Rust också. Det känns verkligen som att inget fastnar hos dig...

Jag tror inte att det är språkskillnaderna som är problemet. De flesta som hängt kvar i tråden kodar C och/eller C++ och du kanske har märk att de flesta inte delar flertalet av dina åsikter?

En webbserver inte är inte svår att skriva om det enbart ska vara HTTP 1.0 och om den enbart ska användas av dig själv men än en gång så frågar jag mig hur du motiverar för din arbetsgivare att återuppfinna hjulet(fast lite sämre) varje gång?

"som inte är stateless". Ett udda krav för en web server, med tanke på att vanlig HTTP är stateless.
Vad är det egentligen för tillstånd som din tänkta web server skulle behöva hålla reda på?

Du har fortfarande inte svarat på min fråga om vilken sorts tillstånd som din tänkta webserver skulle behöva hålla reda på.
Och du har inte berättat varför du tror att C++ skulle vara märkbart bättre för uppgiften än många andra programmeringsspråk.

Vilken sorts "smartare api" tänker du på?
För en fristående webserver borde det bara vara två typer av API:er som är inblandade, och ingendera är definierat av webservern.
Det ena API:et är det som webservern använder för att kommunicera med operativsystemet.
Det andra är de (standardiserade) protokoll som en webläsare använder för att kommunicera med webservern.

Det slår mig nu att du har för ovana att använda icke-standard terminologi.
Kan det vara så att när du säger "webserver" så menar du vad resten av världen kallar en "webapplikation"? För då blir det ju en lite annan sak - fast det finns fortfarande ingen uppenbar fördel med C++ framför många andra språk.