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

Jag förstår inte, har jag sagt att jag aldrig använder smartpointers? Kommer inte ihåg men kan inte tänka mig att jag sagt det för det stämmer inte. I "skitkod" som jag brukar kalla domänspecifik kod använder jag det ofta. Har även skrivit "egna" smartpointers fast då för annan typ av hanering, små hjälpklasser för att hantera objekt.

Japp, och som jag skrev ovan, i skitkod är det mitt vanliga

Annan kod som är skriven för att återanvändas och skall vara smart, där läggs mycket tid för att få det hela så optimerat som möjligt och eftersom det återanvänds är det säkrare. Skitkod är fullt med unika lösningar för olika typer av situationer och måste han en annan typ säkerhet.

För mig är det mycket sällsynt att använda shared_ptrs, det är enligt mig dålig design. Viktigt att veta vem ägaren är till data. När saker flyttar omkring blir koden mycket svårare att hantera.
För varje shared_ptr har jag säkert +50 unique_ptr.

Men jag är inte emot dem
De har sin uppgift och där det passar använder man dem.
Hade inte använt dem om man exempelvis skriver en parser men i skitkod så absolut, trådad kod så nära 100% säkert att jag använder det.

Exempel på vad som kan bli problem med för mycket stl och det här är långt ifrån något extremt exempel

   /// @brief Type alias for table, which can be either a `gd::table::dto::table` or a `gd::table::arguments::table`.
   using table_t = std::variant< std::unique_ptr< gd::table::dto::table >, std::unique_ptr< gd::table::arguments::table > >;
   std::vector< table_t > m_vectorTableCache;

Vad som är så jobbigt med denna typ av lösning är att den är svår och debugga och svår för andra att förstå, normalt tänker jag mycket på att koden skall vara lätt att debugga så det behöver verkligen vara vinster om kod skrivs som ovan

Jag hade inte reagerat om du inte hade frågat efter vettiga namn på svenska. Utifrån kontexten så var det helt uppenbart exakt vad du menade. Kolla bara på hur många som rör ihop parameter och argument utan att man ens tänker på det. Jag har samma känsla som du att man nog gör sig mer förstådd på "svengelska" än att envisas med att översätta alla termer till svenska. Däremot kan "svengelska" bli lite mycket i tal ibland så jag förstår viljan av att hitta svenska ord.

Däremot förstår jag fortfarande inte vad @kik menar med överlagring och varför det är så viktigt?

Den ständigt växande listan med intressanta saker man ska titta på nån gång i framtiden. Jag har knappt skrivit GUI kod i APL men det finns bindings för .Net så man kan skriva .Net / Windows Forms kod direkt i APL. Det finns även ⎕WC som också är win form baserat.

Bad AI göra en jämförelse mellan std::vector och rusts Vec. Rust behöver normalt nära dubbelt så många olika metodnamn jämfört med C++ på grund av att de saknar överlagring. Det kanske inte upplevs som så problematiskt om man inte är van vid att skriva generell kod eller skriva kod som skall återanvändas.

Men det är problem som ökar snabbt eftersom man hela tiden behöver hitta på nya namn, namn är svåra att hantera.

Ta en jämförelse, låt säga att du har 1000 skruvar till en bil, är det 1000 olika skruvar hade bilen blivit mycket dyr. Desto mer lika du kan få skruvarna desto lättare blir bilen att skruva samman.

Med överlagring är det enklare att ha samma namnuppsättning för olika typer av objekt och då slipper utvecklare läsa igenom koden. Bra namngivning i C++ och du behöver i princip inte läsa kod, du vet hur du skall använda det eftersom det följer mönster (fasta strukturer) och där är namn en viktig del.

Problemet med avsaknad av överlagring blir speciellt jobbigt i värdeklasser. I alla fall har jag inte lyckats få AI att skriva om C++ kod till något som verkar trevligt och jobba med. std::vector som här jämförs är långt ifrån det värsta exemplet, tvärtom

Med det sagt så är rust ett jättebra undervisningsspråk. För nya utvecklare är tydliga namn lättare att förstå jämfört med "smart" C++ kod

***

### Comparison of `std::vector` (C++) and `Vec` (Rust) Method Proliferation

A key difference between the C++ and Rust APIs is the number of method names. C++ leverages function overloading and context, while Rust uses distinct names to explicitly signal mutability, ownership, and error handling.

**Operation: Get an element**
* **C++** (Fewer names): `operator[]`, `at`, `front`, `back`
* **Rust** (More names, explicit): `[]` (via Index trait), `get`, `get_mut`, `first`, `first_mut`, `last`, `last_mut`

**Operation: Add an element**
* **C++:** `push_back`, `emplace_back`
* **Rust:** `push`, `insert`

**Operation: Remove an element**
* **C++:** `pop_back`, `erase`
* **Rust:** `pop`, `remove`, `swap_remove`

**Operation: Create an iterator**
* **C++** (Overloaded names): `begin`, `end` (with `const`, non-`const`, and reverse variants)
* **Rust** (Explicit names): `iter` (immutable borrow), `iter_mut` (mutable borrow), `into_iter` (take ownership)

**Operation: Change size**
* **C++** (Single method): `resize`
* **Rust** (Specific methods): `resize`, `resize_with`

**Operation: Remove elements by condition**
* **C++** (Algorithm + method): Use `std::remove_if` + `erase`
* **Rust** (Built-in methods): `retain`, `drain`, `drain_filter` (unstable)

**Operation: Append another collection**
* **C++** (Overloaded method): `insert` (with iterators)
* **Rust** (Specific methods): `append`, `extend`, `extend_from_slice`

**Operation: Handle errors on access**
* **C++** (Exception handling): `at` (throws an exception on error)
* **Rust** (Type-based handling): `get`, `get_mut` (return an `Option<&T>` type)

Var det ironi?

AI genererade en tabell med metoder mellan std::vector och rusts Vec, jag kan inte metoderna för rust (korrekt) men frågan handlade om överlagring