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

Det brukar finnas flaggor för att runda sådant sökte snabbt och -ffast-math, /fp:fas (MSVC) ser ut och strunta i avrundningsfel, finns en del #pragma med, inte kollat upp nu men det skulle förvåna om det inte går.

precis

Koden jag skrev var för att visa principen, att "ordna data". Har inte testat just det här för att se om det går att också få den vektoriserad men det finns en hel del i C++ som man kan ta till för att berätta för kompilatorn att det är ok att vectorisera koden och även om det inte skulle gå idag, blir kompilatorer bättre och bättre.

Har prövat en hel del annan kod och den normala reaktionen är att man blir förvånad över hur duktig kompilatorn är på att snabba upp koden, inte det motsatta.

Enligt mig är det inte en bra strategi att välja tekniker där man i princip kan räkna ut att logiken snart finns direkt i språket. Har man gjort den tabben några gånger gör man den inte igen.

Skrev nära nog ett helt eget stl mellan 2001-2004 ungefär (om jag minns rätt) och orsaken var att stl då var segt, exempelvis har jag för mig att std::string inte lagrade text med extra utrymme, varenda förändring allokerade om till en ny sträng. Microsoft hade flera år tidigare släppt MFC som hade sin CString med referensräknare. Den var då mycket snabbare än stl kod. Så tog ideer från MFC och lite annat och gjorde något som passade stl. STL gick alltså inte att använda något som behövde minsta lilla snabbhet.
Saker som "move" konstruktörer som gjort livet enklare för utvecklare vad ju ett stort problem då

Jämför med stl idag, det är nästan som att jämföra python med C++

Exemeplvis är AVX512 så nytt (tänker då på att dra nytta av det med full hastighet) så det kommer säkert ta ett tag innan annat hinner ikapp och när det andra hunnit ikapp finns det nya saker igen.

Uteckliingshastighet
Det är arkitektonisk lösning för att få upp snabbhet/produktivitet och det jag tidigare kallat för DOD (data orienterad design), om det heter något annat så vet jag inte hur jag skall benämna det
I alla fall så använder du också kod i dina exempel även om det då begränsar sig till standard C++ och det är givetvis en fördel i en tråd som denna. Men det är inte samma sak som att det inte går att göra smidigare.

För de som jobbat en del med arkitektur märker säkert snabbt hur lätt olika typ av kod är att förändra för det är viktigt.
Låt säga att du i ditt exempel plötsligt behöver en sträng också, eller kanske andra typer av tal, då har du problem och får skriva om koden en del.

Kan du utveckla?

Pröva och skriv kod i compiler explorer och testa med olika flaggor så ser du hur olika koden blir.
Personligen behöver koden jag gör fungera på ARM och x86 (kanske annan cpu med) så behöver tänka på det.

Det här tog mycket tid förr innan AI men sådant här har blivit mycket smidigare

Det är inte trivialt men om man tror att program endast består av några hundra rader kod så är det trivialt. Program består inte av några hundra rader och speciellt sådan här typ av kod som inte har färdiggjorda ramverk. Att utvecklare själva måste designa koden, skillnaden är ENORM.
Din "special" kod finns bara i ditt huvud, andras lösningar finns i deras huvud. När ni börjar närma er kanske 50 000 rader där varje kodare skriver sina speciallösningar så tar stopp, under tiden har arbetet gått långsammare och långsammare.

Att så många utvecklare ändå tror att sådant här är "trivialt" är att de vanligen sitter med färdiga ramverk och har en fast arkitektur. De behöver bara följa den, inte lära sig själva varför.

Smart C++ med massa stl och templates skrivna av en programmerare som fått feeling och börjar lära sig alla coola trick, den koden blir med nära nog 100% säkerhet endast något som kommer leva programmerarens huvud. Snart bli det också tråkigt när utvecklare måste refaktorera för att man glömt saker som koden behövde fixa.
Och så dyker buggar upp, koden blir svårare och svårare att hantera.

Diskussionen om HN handlar bl.a. om det här, och det är en av alla tekniker som används för att klara av att skala stora mängder kod.

Hur menar du att din lösning inte var "hemma-kokad" ?

Ta följande sekvens

    for (std::size_t i = 0; i < Rows; ++i) {
        std::cout << '|';
        for (std::size_t j = 0; j < TotalCols; ++j) {
            std::cout << std::setw(5) << static_cast<int>(tbl[i][j]) << " |";
        }
        std::cout << '\n';
    }

Förstår att du ville göra något liknande, inte skriva en färdig lösning. Så helt ok, denna hade ju direkt hamnat i sopsäcken för normala lösningar.

Men vad jag inte förstår är att man inte ser vinsten i att kunna återanvända.

Klistrar in en bild här för att visa andra format som kan skriva ut tabellen. Aktuellt fall handlar om hjälptext för terminal applikation. Om text måste få plats inom en viss bredd behöver logik skrivas för att bryta texten. Räkna ut hur många rader texten behöver. Inte nog med det utan de andra kolumnerna behöver också förlängas med samma antal rader.
Det här tar en del tid att skriva kod för och den tiden hade inte investerats i en lösning som inte är återanvändbar, då exploderar koden i storlek och går inte hantera.
Kan man däremot skriva återanvändbar logik är investerad tid mycket bättre använd för plötsligt har man en metod som kan användas lite överallt.

Programmerare som vet att skriva återanvändbar kod skriver säkrare kod och är mycket snabbare än de som hårdkodar

Och då jobbar du också i en inarbetat arkitektur, antingen har det funnits utvecklare som vet hur designar kod eller så har de använt något färdigt. Att nå +50 000 rader kod med att skriva likt exempelkod som man kanske snabbt kokar ihop i en tråd som denna görs givetvis inte, den koden hade inte ens nått 10 000 men bara att förstå hur viktigt det är att ha hanterbar kod, det är något som förbryllat mig varför inte fler förstår

Spenderat timtal i diskussioner med andra utvecklare som ser ut som ufon så fort man pratar generella lösningar

Det är flera men för att fokusera på utskrifter finns följande, saknas någon kan jag snabbt lägga till den

/// tag dispatcher used for csv formatting
struct tag_io_csv {};
/// tag dispatcher used for json formatting
struct tag_io_json {};
/// tag dispatcher used for xml formatting
struct tag_io_xml {};
/// tag dispatcher used for command line interface
struct tag_io_cli {};
/// tag dispatcher used for raw formatting, this is used to write data without any formating, just as it is in table
struct tag_io_raw {};
/// tag dispatcher for uri formatting
struct tag_io_uri {};
/// tag dispatcher for sql formatting
struct tag_io_sql {};

Observera namngivningen också för namngivning tror jag är något som slarvas mest med.
En C++ utvecklare kan förmodligen en del metodnamn vanliga i STL, förstår vad "to_string" är för något eftersom det också finns sådana metoder i STL biblioteket. Väljs namn och att kod skrivs med samma principer som STL kommer utvecklare ha lättare att jobba i koden. Det här är kanske en av de "smartaste" detaljerna i stl även om det finns några missar i namngivning. Vet man bara några få ord går det mesta att använda i stl.
Namn som begin, end, size, empty, clear, to_string, insert, find o.s.v

Läses kod och man ser att de håller sig till de här namnen är koden normalt enklare att förstå. När metodnamn skenar i väg i antal ord blir det så mycket svårare och det är en stark signal om att metoder gör flera saker,

Om tabellen har 10 kolumner så spara information för varje kolumn, värdena i tabellen behöver inte någon information så det är i princip ett enda block med rader x storlek för data. så om det är 10 double så är det rader * 10 * sizeof(double)

1000 rader blir då 1000 * 10 * 8 = 80 000 byte.

Ja och det är väl den enda? märkligt att något så enkelt har så få bibliotek att välja på. Har som du säkert sett skrivit en egen med mer flexibilitet än argparse

Tittade på det här för drygt 2 år sedan och vad som jag framförallt saknade var logik för att skicka in olika typer av format. De var centrerade kring att skicka med det som tas emot i main. Att parsa en sträng likt den som man skriver i terminalen direkt eller att generera en sträng (andra hållet) saknades. Förutom det så tror jag det var krångligt att lägga till argument efter parsning eller modifiera lästa argument

Vad som däremot fanns mycket av är validering och regler kring argument, även kontroller av typ.

   /// Parse application arguments (like they are sent to `main`)
   std::pair<bool, std::string> parse( int iArgumentCount, const char* const* ppbszArgumentValue, const options* poptionsRoot );
   std::pair<bool, std::string> parse( int iArgumentCount, const char* const* ppbszArgumentValue ) { return parse( iArgumentCount, ppbszArgumentValue, nullptr ); }
   
   /// parse single string, splits string into parts and parse as normal
   std::pair<bool, std::string> parse( const std::string_view& stringArgument );
   /// parse vector of strings as normal
   std::pair<bool, std::string> parse( const std::vector<std::string>& vectorArgument );
   /// parse single terminal line, splits string into parts and parse as normal, this is the exakt format as you type in terminal
   std::pair<bool, std::string> parse_terminal( const std::string_view& stringArgument );

   std::string to_string() const;

Det är free functions (separata metoder) likt stls to_string som tar tabell som parameter. För precis som du säger, absolut förbjudet att blanda logik i generella objekt.

Det är viktigt

Enligt mig så är det viktigt att lösa problem på enklast möjliga sätt, ofta går det att få ihop något som fungerar flexibelt utan att det är så märkvärdigt. Tabellen var ursprungligen framtagen för att ersätta "dto" objekt (data transfer object). Få bort en hel massa structer som används för att fånga upp data från databas frågor (SELECT) och förenkla arbetet. För det vart mycket buggar med så många olika samt värden att hålla reda på. Få in allt i en enda tabell och bygga logiken kring den istället förenklade lösningen och det var enklare och verifiera (matcha mot databas och liknande). Sedan har det växt

Detta är open source så tror ingen är beredd att betala. Och det är relativt färdigt. Men det beror på vad som önskas göra, mest hjälp tror jag databasapplikationer som hanterar mycket SELECT frågor har. De skulle kunna rensa bort mycket kod om de idag använder dto'er för att samla data.

Ja precis och även att testaköra applikationer. Scripta dem så att man exempelvis kan ha en fil med en hel hög olika argumentsekvenser som testkör olika saker.
"egen" history har också varit viktigt

Vet att jag tyckte det var extremt märkligt att det var så svårt att hitta saker men kanske letade jag på fel ställen. Det var andra som också letade och det vi började med var argparse men den var verkligen ingen hitt. Det kanske finns bättre saker nu

Aha, tror jag förstår frågan
Det stämmer att tabellen inte är en bra lösning om alla värden ligger på rad. Men där finns den "normala" std::vector. Den typen av bearbetning har stl bra lösning för

Är med, man kan visserligen göra en tabell med en enda kolumn men ser inte riktigt poängen i det för som du beskriver så ligger värden på rad och samma operation skall göra på varje värde så är det enklare med std::vector.

Men där måste du oavsett ordna om data. Om det görs i en lokal buffer (kanske på stacken), en vector eller om man har något egen snickrat som jag. Det måste ändå utföras ett arbete innan för att få till det hela.

Men var det inte det jag gjorde?
Gissar jag rätt att du tittat en del på hur spelutvecklare applicerar DOD? Spel (grafik) brukar inte ha så många olika beräkningssteg vad jag sett när de håller på. De har det lättare att lyckas placera data i långa rader och behålla det så.

Antal steg i olika beräkningar jag skrivit kod för kan vara över 20 och det är ofta en del komplexitet kring varje beräkning med flera olika värden som är involverade

table data(… { {… "symbolId"}, {…} , {… "timestamp"}, {… "orderId}, {"int32", 0, "volume"}, {…}, {"int32", 0, "price"}, {…}}, …)

Den egen snickrade lösningen kan plocka ut alla värden från en kolumn och lägga dem i en vector. det hade varit ett alternativ men jag hade nog istället valt att tråda lösningen.

   /// @name harvest values from table into other type of container objects
   /// 0TAG0harvest.table_column_buffer
   ///@{

   template <typename TYPE>
   std::vector<TYPE> harvest( uint64_t uRow, unsigned uColumn, unsigned uCount, tag_row ) const noexcept;
   template <typename TYPE>
   std::vector<TYPE> harvest( uint64_t uRow, const std::string_view& stringName, unsigned uCount, tag_row ) const noexcept { return harvest<TYPE>( uRow, column_get_index( stringName ), uCount, tag_row{} ); }
   template<typename TYPE>
   std::vector< TYPE > harvest( unsigned uColumn, uint64_t uFrom, uint64_t uCount ) const;
   template<typename TYPE>
   std::vector< TYPE > harvest( unsigned uColumn, uint64_t uFrom, uint64_t uCount, tag_null ) const;
   template<typename TYPE>
   std::vector< TYPE > harvest( const std::string_view& stringColumnName, uint64_t uFrom, uint64_t uCount ) const { return harvest<TYPE>( column_get_index(stringColumnName), uFrom, uCount); }
   template<typename TYPE>
   std::vector< TYPE > harvest( unsigned uColumn ) const { return harvest<TYPE>( uColumn, (uint64_t)0, get_row_count() ); }
   template<typename TYPE>
   std::vector< TYPE > harvest( const std::string_view& stringColumnName ) const { return harvest<TYPE>( column_get_index(stringColumnName), ( uint64_t )0, get_row_count()); }
   template<typename TYPE>
   std::vector< TYPE > harvest( const std::string_view& stringColumnName, tag_null ) const { return harvest<TYPE>( column_get_index(stringColumnName), ( uint64_t )0, get_row_count(), tag_null{}); }

   /// harvest row values into vector with arguments
   void harvest( uint64_t uBeginRow, uint64_t uCount, std::vector<gd::argument::arguments>& vectorArguments ) const;
   void harvest( std::vector<gd::argument::arguments>& vectorArguments ) const { harvest( 0, get_row_count(), vectorArguments ); }
   std::vector<gd::argument::arguments> harvest( tag_arguments ) const { std::vector<gd::argument::arguments> v_; harvest( 0, get_row_count(), v_ ); return v_; }
   void harvest( const std::vector<uint64_t>& vectorRow, std::vector<gd::argument::arguments>& vectorArguments ) const;
   void harvest( const std::vector<uint64_t>& vectorRow, std::vector< std::vector<gd::variant_view> >& vectorRowValue ) const;

   void harvest( const std::vector< unsigned >& vectorColumn, const std::vector<uint64_t>& vectorRow, table_column_buffer& tableHarvest ) const;
   void harvest( const std::vector< std::string_view >& vectorColumnName, const std::vector<uint64_t>& vectorRow, table_column_buffer& tableHarvest ) const;
   ///@}