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

Hade det varit bra om du kunde mappa hela databasen med en fyra fem api

Ett av api för selectfrågor ett för insert ett för update och ett för delete, är det dumt?

Äntligen börjar diskussionen blir intressant och komma in på lösningar?

Varför tänker du CRUD? CRUD är troligen en av de sämsta skitarkitekturerna som något kommit på. Enda fördelen är att den är enkel för juniora utvecklare

Om vi tar exemplet med att man istället gör fyra API eller jag väljer faktiskt 5.
1 = SELECT frågor
2 = UPDATE
3 = INSERT
4 = UPSERT (antingen uppdatera eller insert)
5 = DELETE

Då kan man göra serveranrop som ser ut så här

/execute/44411 = "UPSERT,UPSERT,UPSERT,SELECT ,SELECT"

Tre stycken update och två select i ett request. Då kanske någon tänker, men varför skall jag göra så. Det ser ju krångligt ut

Då har den utvecklare aldrig gjort något speciellt svårt. Kan man packa anrop blir det mycket enklare att jobba mot servern. Prestanda går upp eftersom det blir färre anrop.

Tidigare i tråden pratade vi lite om att inte göra en server stateless, att servern skall snurra hela tiden.
Om servern kan hålla state kan man läsa in information.

Alla? relationsdatabaser stödjer exempelvis information_schema. Kör man ODBC (C/C++ och en del andra språk stödjer det) är man heller inte knuten till en speciell databas.

Då kan servern läsa in det mesta om databasen och med det kan man bygga generella regelverk och bygga SQL dynamiskt.

Men den här tekniken kan servern göras fristående från klienten (frontend), och då kan man kasta ut bygg-pipelinen. Allt blir så mycket enklare och det går att skala upp till mycket stora system utan att det blir allt för mycket för utvecklare att hålla i huvudet.

Server (backend) och frontend är decoupled

Om man jämför C++ templates med de andra, hur väl står de sig? Och hur är det med kompilatorns kunskap om koden den skannar av för hur mycket smart kod som går att göra beror mycket på hur mycket kompilatorn vet om koden.

C++ får ofta kritik för kompileringstider och det är absolut en nackdel, kanske den största. Men kompilatorn vet mycket om koden och det är också användbart.
Tar man det senaste och det som kommer, tänker på concepts och snart reflection (osäker på vad för finesser de hittat på där). Det är tekniker som underlättar för att generera kod.

Något jag själv använder mycket är strängar som används för att producera kod i compiletime (constseval, constexpr).

Annan stor fördel är att stl är genomtänkt. Namn liknar varandra vilket gör att kod fungerar bättre om man använder templates.

När jag tittat på rust så anser jag att detta är deras största misstag. Det som följer med verkar ha missat att generera kod, att jag tror det beror på att de har förkortningar och metoder som inte ser så där likvärdiga ut.

Tipsar om två bibliotek för att visa vad C++ kan (och då är de inte gjorda med det nyaste)
sol2 - https://github.com/ThePhD/sol2
compile-time-regular-expressions - https://github.com/hanickadot/compile-time-regular-expression...

Görs en lösning som kanske har en kodmängd som är en tiondel eller mindre ändå, och som återanvänder kod. Är inte det säkrare än större kodmängd som är hårdkodad

Det är de väl ändå inte va, inte i närheten ens. templates är mycket kraftfullare och blir snabbt bättre med. Många av de som sitter och bestämmer vad som skall in C++ älskar ju templates.

Ok, men C++ är 100% compile time. Hur är det med den saken och de andra språken?

Går detta i rust exempelvis

/// create rule for `variant_view` and `variant`
template <typename VARIANT>
concept IsVariant = std::is_same_v<VARIANT, gd::variant> || std::is_same_v<VARIANT, gd::variant_view>;

/// `std::get` like function for `variant` and `variant_view`

template <typename RETURN_TYPE, typename VARIANT>
requires IsVariant<VARIANT>
RETURN_TYPE get(const VARIANT& v_)
{
   if constexpr( std::is_same_v<RETURN_TYPE, bool> )
      return v_.as_bool();
   else if constexpr( std::is_same_v<RETURN_TYPE, uint32_t> )
      return v_.as_uint();
   else if constexpr( std::is_same_v<RETURN_TYPE, uint64_t> )
      return v_.as_uint64();
   else if constexpr( std::is_same_v<RETURN_TYPE, int32_t> )
      return v_.as_int();
   else if constexpr( std::is_same_v<RETURN_TYPE, int64_t> )
      return v_.as_int64();
   else if constexpr( std::is_same_v<RETURN_TYPE, double> )
      return v_.as_double();
   else if constexpr( std::is_same_v<RETURN_TYPE, std::string> )
      return v_.as_string();
   else
      return (RETURN_TYPE)v_;
}

Det verkar vara samma, men syntaxen... En del klagar hårt på C++ templates, det här var faktiskt värre

Tolkar jag Go koden rätt så är det inte samma, det är runtime där

Fick lite feeling och skrev ihop en typ av logik som är ganska enkel men som också behöver tänja lite på språket för att det också skall bli lätt att skriva kod. Lätt att förstå utan att nörda ner sig

Följande länk går till en "archive" class. det handlar om att serializera data och den vill man gärna få smidig för att kunna skriva och läsa information så enkelt som möjligt.

Länken till hela headern (nästan all kod är i headern så det lilla som ligger i en cpp behövs inte).
https://pastebin.com/4te3rTZD

Exempel kod i kommentarer men klistrar in det här också

* Usage example:
 * \code
 * // Writing to a file
archive ar("output.bin", std::ios::out | std::ios::binary);
uint32_t value = 42;
ar << value;

// Reading from a file
archive archiveRead("output.bin", std::ios::in | std::ios::binary);
uint32_t read_value;
archiveRead >> read_value;
 * \endcode
 * 
 * Write samples - shows how to write values to file in different ways
 * \code
// pathFile = some file path
archive ar_(pathFile, gd::io::tag_io_write{});
int iValue = 10, iValue2 = 20, iValue3 = 30;
ar_.write(iValue).write(iValue2).write(iValue3);
ar_.write_all(iValue, iValue2, iValue3);
ar_ << iValue << iValue2 << iValue3;

std::string s1 = "1111111", s2 = "2222222", s3 = "3333333";
ar_.write_all(s1, s2, s3);

archive ar2_(pathFile2, gd::io::tag_io_write{});
gd::argument::shared::arguments arguments( {{"one", "one"}, {"one", "one"}, {"one", "one"}, {"one", "one"}, {"one", "one"}});
ar2_.write_block( (uint64_t)arguments.buffer_size(), arguments.data() );
\endcode

Read samples - shows how to read values from file in different ways
 * \code
// pathFile = some file path
archive ar_(pathFile, gd::io::tag_io_read{});
int iValueRead = 0, iValue2Read = 0, iValue3Read = 0;
ar_.read(iValueRead).read(iValue2Read).read(iValue3Read);
ar_.read_all(iValueRead, iValue2Read, iValue3Read );
ar_ >> iValueRead >> iValueRead >> iValueRead;

archive ar2_(pathFile2, gd::io::tag_io_read{});
std::string s1, s2, s3;
ar2_.read_all(s1, s2, s3);

archive ar2_(pathFile2, gd::io::tag_io_write{});
gd::argument::shared::arguments arguments( {{"one", "one"}, {"one", "one"}, {"one", "one"}, {"one", "one"}, {"one", "one"}});
ar2_.write_block( (uint64_t)arguments.buffer_size(), arguments.data() );
ar2_.close();
ar2_.open(pathFile, gd::io::tag_io_read{});
gd::argument::shared::arguments argumentsRead;
ar2_.read_block64( [&argumentsRead](uint64_t uSize) -> void* { argumentsRead.reserve( uSize ); argumentsRead.buffer_set_size( uSize ); return (void*)argumentsRead.data(); });
 * \endcode

Är självklart hemmablind då jag är van vid C++ men min reaktion när jag ser andra språk och de skall göra likartade saker, det är att koden ser krångligare ut. Men jag tror att många som jämför kod mellan C++ och andra språk jämför saker som är färdigjorda. Och så tänker inte alltid C++ utvecklare. I C++ skrivs så mycket själv, medan annat språk, där väljs eventuellt att leta upp någon serialize klass även om det bara tar några timmar att skriva ihop en.

Hur skulle delar av ovanstående kod se ut i andra språk?

Eller så spetsa öronen för jag tror det är ovanligt att få så mycket "udda" tips i dagens strömlinjeformade utvecklingstekniker

Det är möjligt men i det du beskriver just nu så verkar jag ha förstått rätt, att min kritik stämmer. Och att det snarare handlar om att du missuppfattar C++.

Som jag skrivit tidigare i varianter. C++ är inte gjort för att vara lätt, det är inte gjort för att använda sig av ett paket med funktionalitet som följer med språket. C++ är ett verktyg för att möjliggöra bästa möjliga lösning (utan att börja hacka assembler).

Att andra språk är "enklare" vet jag också. Men vad som är enkelt i ett språk är inte samma sak som att det skulle vara enkelt att skriva kompletta applikationer som skall installeras hos kunder eller köras av väldigt många användare.

Min poäng med mitt senaste C++ exempel var att visa hur "enkelt" det är att själv skriva en lösning som fungerar flexibelt utan extra bibliotek.

Andra språk har inte det målet, andra språk försöker göra det så lätt som möjligt att byta ut programmerare. Om du tar ett mycket vanligt konsultspråk, och jag skriver konsultspråk eftersom när bolag hyr in konsulter så kommer de också bytas ut. Då måste koden skrivas på ett sätt så att det går att byta ut konsulten.
C# är vanligt och orsaken är bl.a. att C# skeppar med ett gigantiskt bibliotek med funktionalitet som backas upp av Microsoft. Företag känner sig trygga med det och programmerare skall inte lösa saker själva, de skall använda .NET.

C# och C++ är två totalt olika språk, samma med java. De är varandras motpoler.
java skeppar också en herrans massa funktionalitet.

Exakt, det är verkligen ingen översättning. Det är en helt annan lösning för du plockar där in ett bibliotek som någon annan skrivit åt dig. Och det är självklart bra för utvecklare då de slipper skriva koden själv men det visar brister i språket. Istället för att lära sig programmera behöver du lära dig bibliotek.

Lite tidigare diskuterades lösningar weblösningr och vi (inte du och jag) kom in på CRUD lösningar. CRUD är fantastiskt populärt för att det är lätt. Men är det bra? Verkligen inte.
CRUD lösning görs för att det är lätt att byta ut utvecklare. Det fungerar hyffsat för en till tre utvecklare om antalet tabeller håller sig under 25 och inte kräver allt för komplicerad hantering. Går man över är det stor risk att allt plötsligt tar väldigt lång tid. Skall de göra större system brukar de därför splitta upp databaslösningar på olika sätt, kan vara microservices eller annat så varje utvecklare slipper komma ihåg.

I C++ tänker man inte så (jag vet att det finns men de har missuppfattat). Att göra en CRUD lösning i C++ är galenskap.

Det är ingen brist utan språket är så kraftfullt att du kan göra det mesta bättre själv

Menar du att det är riskfritt att använda annans kod?
Skall du göra ett system som skall ha en livslängd på +20 år, då begränsar det ordentligt vad du kan plocka in. Du måste tänka annorlunda jämfört med om livslängden är kanske 3 år innan det behöver börja refaktoreras.
Externa bibliotek är att bygga in sig.

Med det menar jag inte att man aldrig lägger med externa bibliotek i C++. Det gör jag också men inte alls på samma sätt som när man gör det i andra språk. Personligen så handlar det nästan uteslutande om extern funktionalitet där källkoden är med och kompileras upp. Är det inte källkoden som är med skall det väldigt mycket till för att ta med det.

Mitt första program jag skrev som utvecklare, jobbade 7 månader på ett bolag och skrev då ihop en. mitten på 1990 talet. Det säljs fortfarande och omsätter runt 50 miljoner varje år. Det skrev för Windows 3.11 och Microsoft MFC användes som ramverk.

Att C++ lösningar kan leva så länge är för många mycket viktigare än att slänga ihop något som endast fungerar för vad just det företaget har behov av.

Kan ta ett exempel här för att beskriva och som jag tror är lätt att förstå.
XML och JSON är supervanligt att använda för att transportera data. De flesta klarar sig med formatet. De flesta nya språk måste snabbt lägga till bibliotek/funktionalitet för att hantera dessa format om språken skall kunna locka till sig användare.

Microsoft och sitt .NET vet jag har logik för det och de har även med XPATH för att kunna selektera XML, minns jag rätt har de till och med två versioner. Men man är alltså begränsad till vad som finns i .NET. Skall du hitta andra bibliotek för att hantera så vanliga format som JSON och XML är det väldigt tomt.

C++ har flera stycken open source för att hantera formaten. Värstingen för XML tror jag är Xerecs from mozilla. Den har det mesta och har för mig att det är den som används för olika plugins i editorer när de skall ha funktionalitet för att smidigt editera xml.
pugixml är vanligt om man vill ha XPATH men samtidigt hålla nere komplexiteten. Har man inte behov av att selektera xml finns en hel hög med bibliotek.

För JSON vet jag att jsoncons har selekteringsmöjligheter, två olika faktiskt. Annars är de flesta bibliotek i C++ för JSON oftast gjorda för hastighet eller enkelhet att jobba med.

Jämför jag med hur C# utvecklare tänker när de jobbar med json jämfört med C++ så för att måla med bred pensel skiljer det.

i C# används json för att transportera data till alla DTO objekt. Microsoft har byggt funktionalitet kring detta och därför är det lätt. De skall inte experimentera själva.

Skulle någon C++ utvecklare säga till mig att börja göra DTO objekt i C++ och skeppa data med json är det dags för den utvecklaren att växla upp. I C++ kan du göra så mycket mer för att få till smidiga lösningar. Att bygga ett system men +500 tabeller i en databas med C++ är inte speciellt svårt. Men det är helt omöjligt med CRUD lösning