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

Du sågar väl som vanligt av dig själv vid fotknölarna ...

Jag vet inte vad du menar med enkla språk men jag skulle uppfatta att Rust och C++ är ungefär samma användarkomplexitet medans Rust är mer genomtänkt med tanke på att man lämnar garantier kring minnessäkerhet och UB.

Nja, du får det som att låta som att man inte kan prioritera multipla saker. Men visst om det står mellan att få något lite sämre prestanda i något enstaka fall mot att introducera UB så kommer man självklart att inte introducera UB.

Nej alla språk är inte designade för produktivitet, det finns en hel kategori med språk som är konstprojekt eller skämt. Sedan produktivitet i detta fallet kan vara att man exempelvis inte behöver extra kod för att explicit allokera/frigöra minne och att många saker dom debug-printing, jämförelse osv kan härledas från det starka typsystemet.

Du brukar inte ha koll på läget så jag tror Rust klarar sig bra utan att ändra något mer än att reducera tröskeln för att locka fler användare.

Svammel... Vad jag vet så heter det "konstruktor" och "destruktor". Nu kan jag inte C++ men om en av design principerna är att classer ska ha en konstruktor och en destruktor så låter det som en 14åring skrivit design principerna.

Du har som vanligt fel. traits kan väl lättast att beskriva som interface. Drop kan du se som ett interface om man vill lägga till manuell hantering när objektet går ur scope. I de flesta fallen behöver du inte bry dig om Drop eftersom alla typer i standard lib:et redan implementerar detta. Så nej, Drop är inte ett hack.

Styrkan med traits är att du kan implementera traits för objekt som du inte deklarerat.

Korrekt Rust har ingen konstruktor, precis som C och new() är inte en metod utan en funktion i objekt-namespacet som returnerar en objektinstans.

Varför? Jag har personligen inte stött på ett scenario där jag känt att jag vill överlagra något ...

Varför? Det låter som mer jobb att ha redundant kod i multipla konstruktorer.

Det låter som att du inte förstått varför det är långa metodnamn. En anledning är konventioner som as_*, to_*, into_*.
https://rust-lang.github.io/api-guidelines/naming.html#ad-hoc...

Ge gärna exempel på Rust-metoder med långanamn enl. dig.

Än en gång förstår jag inte fixeringen med överlagring. I Rust så hade jag implementerat traitet std::ops::Add och sedan hade jag kunnat göra "my_obj += 1" eller "my_obj.add(1)".

Du tror mycket som vanligt...

Varför är du så fixerad över vad jag kodar?

Att du kommer med märkliga påstående, fördomar, missförstånd och inte kan betydelsen av vanliga begrepp som du använder har inget med min kod att göra.

Det är för att mycket av det du säger är direkt felaktigt.

Jag tror att våra meningar går isär eftersom jag upplevt scenarion som direkt dementerar många av dina påståenden. Det känns som att du lever i en bubbla och inte försöker utforska något utanför din bubbla eftersom du är rädd för att det skulle ändra din världsbild.

Som att grupper folk som Python-utvecklare eller C++-utvecklare. Alla utvecklare som jag känner skriver åtminstone 3 språk, dvs för mig finns inte sådana grupperingar.

Som att kalla Drop ett hack. Vad jag kan tolka så är du förvirrad kring Drop och traits och istället för att erkänna det för dig själv och sedan fråga, kanske skriva något i Rust och när du har bättre förståelse komma med ett sådant påstående och kunna underbygga varför du upplever det som ett hack så slänger du ur dig saker efter 5 minuters Googlande eller som i fallet med recession testing inte ens läst länkarna som du postat...

Håller med. Men ser inte varför något i Rust skulle förhindra det.

En ett exempel på något som snarare gör att man lättare tar sig "snabbt fram" med Rust jämfört med många andra språk är saker som att "arithmetic overflow" ger notis i _debug byggen_ i Rust (men inte i Release för att inte påverka prestanda).

Det är "opt-in" att stänga av alla former av rail-guards. När man skriver drivers och/eller kanske använder Rust i microkontrollers så behöver man ibland stänga av "safe Rust". Men att göra det är ju en standardfunktion, och ser man diskussionen i C++ lägret kring bl.a. minnessäkerhet har man även där kommit till insikt att säkerhet "by default, med out-out vid behov" är den vettigaste designen.

Har använt TDD i C#, Go, Rust, C++ och även C. Det fall som varit mest "coolt" är så här långt i C där vi jobbande i månader med ett projekt där vi hela tiden höll 100 % test-coverage.

Var rätt häftigt att se en komplett TCP/IP-stack köra en fullt fungerande TCP-implementation första gången den placerades i ett "riktigt system". Så nära 100k rader C som aldrig kört något annat än tester där flera personer jobbade parallellt fungerade på första försöket. Var det buggfritt? Knappast, men det var tillräckligt väl-testat via TDD för att ändå fungera helt OK på första försöket.

Här ser man också skillnad i de "nya" språken. Både Rust och framförallt Go har TDD integrerat i standard tool chain (Go har även mikrobenchmarks där, Rust kräver likt C++, C# m.fl. 3:e-parts bibliotek men där det finns "de-facto standarder").

Ge ett enda konkret exempel!

Är helt med på att väldigt få tragglar med template-meta-programming eller ens gör egna containers eller liknande. Men det gäller oavsett om det är C++, Rust, C# eller vad det nu är.

Och precis som i C++ hittar man ofta de mest komplexa delarna i Rust om man behöver ge sig på sådana fall. Annars kan det, likt C++, vara långt enklare och det är nog normalfallet.

Men ge gärna något konkret exempel där det är väsentligt enklare i C++ jämfört med motsvarande i Rust.

Vänta här, var inte det där rätt mycket "hur man bör skriva modern C++20/23 kod"? Saker som iteratorer är inte super-vanligt att implementera i C++, men det är inte super-vanligt någonstans. Har ändå själv haft behov av detta i alla icke-triviala projekt och det suger i C++ då det är betydligt mer komplext än i stort sätt alla andra språk!

Är överhuvudtaget inte med på vad skillnaden skulle ligga här.

Vill man ha den frihetsgraden måste man så långt som möjligt "programmera mot ett interface, inte en implementation". Det är traits i Rust och "pure abstract base-classes" i C++ (den senare har rätt rejält mycket märkligare syntax...).

Vidare har det inget med builder-pattern. Den är i princip en separation av konstruktion i två delar. Först bygger man upp något form av "config-object" som sedan används för att skapa en instans med det specificerade tillståndet.

Kodmässigt ser detta själva "builder-pattern" delen väldigt lika ut i Rust och C++. Att jobba mot ett interface ser lite olika ut, men det är absolut helt väldefininerat i Rust via "impl Interface for ConcreteType" konstruktionen.

Det skrivet: håller med om att Rust är komplext, men det är inte mer komplex jämfört med C++. Tyvärr är båda dessa rätt mycket de mest komplexa språken man hittar, vilket gör att de flesta nog bör välja något annat om man inte måste ha just miljöer med de unika egenskaper C, C++ och Rust råkar ha.

So, what's your problem?

Det är för dig ett ovant sätt att uttrycka initieringen, men om kompilatorn inline-expanderar allting blir det precis lika effektivt som ett inline-expanderat constructor-anrop. Alla medlemmar skall tilldelas "sitt" argument, känns det bättre om allting går i ett anrop än om det är olika anrop som initierar olika delar? Det är mer att skriva, men det kan väl inte du ha några problem med som tycker att man hellre skall skriva egen kod än att använda sig av färdig kod i bibliotek?

Jag är inte heller rädd för att visa kod men det fyller inget syfte i diskussionen. Du delar kod om saker som inte varit relevanta precis som du försöker briljera men i själva fallet framstår det enbart som korkat eftersom vi framförallt diskuterar språkaspekter och inte implementationsdetaljer. Kodexempel har varit relevanta vid diskussioner när du hävdat ineffektivitet och Yoshman gått igenom instruktionerna för att motbevisa felaktiga påstående.

Inlägget som vi pratar om var missförstånd om vad traits är och missförstånd gällande Drop-traitet. Du påstår även att builder-pattern åker i soporna utan någon direkt motivering och jag frågar varför? Så hur tillför kod från något av mina hobbyprojekt till detta? Mitt huvudsakliga hobbyprojekt är skrivet i Erlang, hur bidrar den koden till dina missförstånd om Rust?

Bob Ross nu får du lugna dig (referens "No wrongs only happy little accidents")... Du slänger ur dig påstående om allt möjligt bananas som att säga att Python är ett deklarativt språk, Rust-utvecklare bryr sig inte om minnet osv.

Det är intressant att se andras lösningsförslag. @Yoshman Advent of code i Rust var väldigt lärorik för mig som inte kodat mängder med Rust. Jag känner dock inte att generella implementationsdiskussioner hör hemma i denna tråden.

Du läste inte mitt förra meddelande ...

Om du tycker att det är givande så ha det så skoj(implementation av bittorrents peer wire-protokoll)

-module(ertorrent_peer_proto).

-export([msg_handshake/2,
         msg_keep_alive/0,
         msg_choke/0,
         msg_unchoke/0,
         msg_interested/0,
         msg_not_interested/0,
         msg_have/1,
         msg_bitfield/2,
         msg_request/3,
         msg_piece/4,
         msg_cancel/3,
         msg_port/1]).

-export([
         send_keep_alive/2,
         send_message/2,
         send_bitfield/2,
         send_handshake/3,
         send_interested/1,
         send_unchoke/1
        ]).

-include_lib("eunit/include/eunit.hrl").

-define(CHOKE, 0).
-define(UNCHOKE, 1).
-define(INTERESTED, 2).
-define(NOT_INTERESTED, 3).
-define(HAVE, 4).
-define(BITFIELD, 5).
-define(REQUEST, 6).
-define(PIECE, 7).
-define(CANCEL, 8).
-define(PORT, 9).
% Fast Extension
% http://www.bittorrent.org/beps/bep_0006.html
-define(SUGGEST_PIECE, 13).
-define(HAVE_ALL, 14).
-define(HAVE_NONE, 15).
-define(REJECT_PIECE, 16).
-define(ALLOWED_FAST, 17).

-define(HANDSHAKE_MSG, <<19:8/integer,
                         "BitTorrent protocol",
                         0:64/integer,
                         Info_hash:160/bitstring,
                         Peer_id:160/bitstring>>).

-define(KEEP_ALIVE_MSG, <<0:32>>).

-define(CHOKE_MSG, <<1:32/integer, ?CHOKE:8/integer>>).
-define(UNCHOKE_MSG, <<1:32/integer, ?UNCHOKE:8/integer>>).
-define(INTERESTED_MSG, <<1:32/integer, ?INTERESTED:8/integer>>).
-define(NOT_INTERESTED_MSG, <<1:32/integer, ?NOT_INTERESTED:8/integer>>).
-define(HAVE_MSG, <<5:32/integer, ?HAVE:8/integer, Piece_index:32/integer>>).
-define(BITFIELD_MSG, <<Length:32/integer, ?BITFIELD:8/integer, Bitfield/bitstring>>).
-define(REQUEST_MSG, <<13:32/integer, ?REQUEST:8/integer, Index:32/integer, Begin:32/integer, Length:32/integer>>).
-define(PIECE_MSG, <<Length:32/integer, ?PIECE:8/integer, Index:32/integer, Begin:32/integer, Block/binary>>).
-define(CANCEL_MSG, <<13:32/integer, ?CANCEL:8/integer, Index:32/integer, Begin:32/integer, Length:32/integer>>).
-define(PORT_MSG, <<3:32/integer, ?PORT:8/integer, Listen_port:32/integer>>).

-record('peer.msg.announce', { info_hash = <<>>, peer_id = <<>> }).
-record('peer.msg.keep_alive', {}).
-record('peer.msg.choke', {}).
-record('peer.msg.unchoke', {}).
-record('peer.msg.interested', {}).
-record('peer.msg.not_interested', {}).
-record('peer.msg.have', { piece_index :: integer() }).
-record('peer.msg.bitfield', { length :: integer(), bitfield = <<>> } ).
-record('peer.msg.request', {
        index :: integer(),
        begins :: integer(),
        length :: integer()
    }).
-record('peer.msg.piece', {
        length :: integer(),
        index :: integer(),
        begins :: integer(),
        block = <<>>
    }).
-record('peer.msg.cancel', {
        index :: integer(),
        begins :: integer(),
        length :: integer()
    }).
-record('peer.msg.port', { port :: integer() }).

msg_handshake(Info_hash, Peer_id) ->
    %Flags = 16#0004000000000000,
    {ok, ?HANDSHAKE_MSG}.

msg_keep_alive() ->
    {ok, ?KEEP_ALIVE_MSG}.

msg_choke() ->
    {ok, ?CHOKE_MSG}.

msg_unchoke() ->
    {ok, ?UNCHOKE_MSG}.

msg_interested() ->
    {ok, ?INTERESTED_MSG}.

msg_not_interested() ->
    {ok, ?NOT_INTERESTED_MSG}.

msg_have(Piece_index) ->
    {ok, ?HAVE_MSG}.

msg_bitfield(Bitfield_length, Bitfield) when is_binary(Bitfield)->
    lager:debug("~p: ~p: length '~p', bitfield '~p'",
                [?MODULE, ?FUNCTION_NAME, Bitfield_length, Bitfield]),
    Length = 1 + Bitfield_length,
    {ok, ?BITFIELD_MSG}.

msg_request(Index, Begin, Length) ->
    {ok, ?REQUEST_MSG}.

msg_piece(Block_size, Index, Begin, Block) ->
    Length = 9 + Block_size,
    {ok, ?PIECE_MSG}.

msg_cancel(Index, Begin, Length) ->
    {ok, ?CANCEL_MSG}.

msg_port(Listen_port) ->
    {ok, ?PORT_MSG}.

send_keep_alive(Socket, Timer) ->
    TimerRef = erlang:send_after(Timer, self(), {keep_alive_internal_timeout}),

    {ok, Keep_alive} = msg_keep_alive(),

    case gen_tcp:send(Socket, Keep_alive) of
        ok ->
            {ok, TimerRef};
        {error, Reason} ->
            erlang:cancel_timer(TimerRef),
            {error, Reason}
    end.

send_message(Socket, {Type, Message}) ->
    case gen_tcp:send(Socket, Message) of
        ok ->
            ok;
        {error, Reason} ->
            lager:warning("~p: ~p: failed to send '~p' '~p', reason '~p'",
                          [?MODULE, ?FUNCTION_NAME, Type, Message, Reason]),
            error
    end.

send_bitfield(Socket, Bitfield) ->
    Bitfield_len = bit_size(Bitfield),
    {ok, Bitfield_msg} = msg_bitfield(Bitfield_len, Bitfield),
    send_message(Socket, {bitfield, Bitfield_msg}).

send_handshake(Socket, Peer_id_str, Torrent_info_bin) ->
    % TODO Check if this is correct after peer_id change
    Peer_id_bin = list_to_binary(Peer_id_str),
    {ok, Handshake_msg} = msg_handshake(Torrent_info_bin,
                                        Peer_id_bin),
    send_message(Socket, {handshake, Handshake_msg}).

send_interested(Socket) ->
    {ok, Interested_msg} = msg_interested(),
    send_message(Socket, {interested, Interested_msg}).

send_unchoke(Socket) ->
    {ok, Unchoke_msg} = msg_unchoke(),
    send_message(Socket, {unchoke, Unchoke_msg}).

parse_msg(?KEEP_ALIVE_MSG) ->
    {ok, #'peer.msg.keep_alive'{}};
parse_msg(?CHOKE_MSG) ->
    {ok, #'peer.msg.choke'{}};
parse_msg(?UNCHOKE_MSG) ->
    {ok, #'peer.msg.unchoke'{}};
parse_msg(?INTERESTED_MSG) ->
    {ok, #'peer.msg.interested'{}};
parse_msg(?NOT_INTERESTED_MSG) ->
    {ok, #'peer.msg.not_interested'{}};
parse_msg(?HAVE_MSG) ->
    {ok, #'peer.msg.have'{ piece_index = Piece_index }};
parse_msg(?REQUEST_MSG) ->
    {ok, #'peer.msg.request'{
        index = Index,
        begins = Begin,
        length = Length
    }};
parse_msg(?PIECE_MSG) ->
    {ok, #'peer.msg.piece'{
        length = Length,
        index = Index,
        begins = Begin,
        block = Block
    }};
parse_msg(?CANCEL_MSG) ->
    {ok, #'peer.msg.cancel'{ index = Index, begins = Begin, length = Length }};
parse_msg(?HANDSHAKE_MSG) ->
    {ok, #'peer.msg.announce'{ info_hash = Info_hash, peer_id = Peer_id }};
parse_msg(?BITFIELD_MSG) ->
    {ok, #'peer.msg.bitfield'{ length = Length, bitfield = Bitfield}};
parse_msg(?PORT_MSG) ->
    {ok, #'peer.msg.port'{ port = Listen_port }}.

-ifdef(EUNIT).
-define(TEST_INFO_HASH, <<"c12fe1c06bba254a9dc9">>).
-define(TEST_PEER_ID, <<"ET001-abcdefghijklmn">>).

handshake_test() ->
    {ok, Msg} = msg_handshake(?TEST_INFO_HASH, ?TEST_PEER_ID),
    {ok, #'peer.msg.announce'{info_hash = Info_hash, peer_id = Peer_id}} = parse_msg(Msg),
    ?assertEqual(?TEST_INFO_HASH, Info_hash),
    ?assertEqual(?TEST_PEER_ID, Peer_id).

keep_alive_test() ->
    {ok, Msg} = msg_keep_alive(),
    {ok, Parsed} = parse_msg(Msg),
    ?assertEqual(#'peer.msg.keep_alive'{}, Parsed).

choke_test() ->
    {ok, Msg} = msg_choke(),
    {ok, Parsed} = parse_msg(Msg),
    ?assertEqual(#'peer.msg.choke'{}, Parsed).

unchoke_test() ->
    {ok, Msg} = msg_unchoke(),
    {ok, Parsed} = parse_msg(Msg),
    ?assertEqual(#'peer.msg.unchoke'{}, Parsed).

interested_test() ->
    {ok, Msg} = msg_interested(),
    {ok, Parsed} = parse_msg(Msg),
    ?assertEqual(#'peer.msg.interested'{}, Parsed).

not_interested_test() ->
    {ok, Msg} = msg_not_interested(),
    {ok, Parsed} = parse_msg(Msg),
    ?assertEqual(#'peer.msg.not_interested'{}, Parsed).

have_test() ->
    {ok, Msg} = msg_have(42),
    {ok, Parsed} = parse_msg(Msg),
    ?assertEqual(#'peer.msg.have'{ piece_index = 42 }, Parsed).

bitfield_test() ->
    Expected = <<1:1, 1:1, 1:1, 0:1, 0:1, 0:1, 0:1, 1:1>>,
    {ok, Msg} = msg_bitfield(binary:referenced_byte_size(Expected), Expected),
    {ok, Parsed} = parse_msg(Msg),
    ?assertEqual(#'peer.msg.bitfield'{ length = 2, bitfield = Expected }, Parsed).

request_test() ->
    {ok, Msg} = msg_request(42, 4444, 5555),
    {ok, Parsed} = parse_msg(Msg),
    ?assertEqual(#'peer.msg.request'{
                    index = 42,
                    begins = 4444,
                    length = 5555 }, Parsed).

piece_test() ->
    Expected = <<4:4, 2:4, 0:4, 1:4>>,
    {ok, Msg} = msg_piece(byte_size(Expected), 12, 4096, Expected),
    {ok, Parsed} = parse_msg(Msg),
    ?assertEqual(#'peer.msg.piece'{
                    length = 11,
                    index = 12,
                    begins = 4096,
                    block = Expected }, Parsed).

cancel_test() ->
    {ok, Msg} = msg_cancel(42, 4444, 5555),
    {ok, Parsed} = parse_msg(Msg),
    ?assertEqual(#'peer.msg.cancel'{
                    index = 42,
                    begins = 4444,
                    length = 5555 }, Parsed).

port_test() ->
    {ok, Msg} = msg_port(424242),
    {ok, Parsed} = parse_msg(Msg),
    ?assertEqual(#'peer.msg.port'{ port = 424242 }, Parsed).

-endif.

Logisk separation msg_* skapar ett binär meddelande send_* skickar det. Lite som att inte lägga allt i en konstruktor. *_test är unit test, det är förutbestämt av unit test-ramverket. Språket är Erlang så det är funktionellt och faller helt riktigt in under deklarativa språk.

Jag skriver framförallt C men Erlang är fascinerande. '=' är inte assign utan match och den kommer alltid att försöka matcha så om man har ett 'X = foo.' och variablen X är unbound(odefinierad) så kommer matchningen att tilldela X värdet foo för att uppfylla matchningen men om man sedan försöker med 'X = bar.' då kommer man få en krash eftersom 'foo != bar'. Så '<< ... >>' är binära patterns så genom att matcha dom mot byte-sekvenser från en buffer så kommer man att validera formatet och parse:a binärdatan i samma veva.

Jag skriver C, Golang, Rust, Shell scripting(portabell), Python och Erlang så det är ju enbart ett deklarativt språk i en rad av imperativa så jag lutar nog mer mot imperativa språk. Det är ju just aspekter av exempelvis Erlang som vidgar ens vyer på språk(pattern matching, actor modell, tail recursion, immutability, inget delat minne) om man kommer från imperativa språk.

Det är väl inte någon av de här?

Jag håller med om att coupling ställer till det. Om vi tar ditt favoritfel message chaining (a()->b()->c()->d()) handlar det om att du använder din kunskap om vad exempelvis b() returnerar. Här drar du nytta av/låser fast att ett funktionsanrop returnerar en pekare av en viss typ och opererar direkt på den. I detta fall måste typen ha en c-metod.

Den coupling vi ser här är inte direkt kopplad till anropskedjan i sig. Det går precis lika bra/är lika fel att göra samma antaganden även om du mellanlandar i olika variabler:

auto tmp_a = a();
auto tmp_b = tmp_a->b();
auto tmp_c = tmp_b->c();
tmp_c->d();

Den kodsnutten uppvisar precis samma problem som om man gjort anropen i direkt följd.

Om nu språket har ett antal vedertagna kodningsmönster som

Builder pattern där man logiskt delar upp en initiering i flera mindre olika delar som alla returnerar objektet de delinitierade (jag kan tycka det är enklare att förstå än att skicka 9 godtyckliga siffror in i en konstruktor)

let obj = ObjectIn3DSpace::new()
    .position(1.0, 2.0, 3.0)
    .rotation(0.0, 90.0, 0.0)
    .dimensions(2.0, 2.0, 2.0);

eller Pipeline pattern där man itererar över en container och operationen returnerar den nya containern för att man skall kunna applicera nya operationer på resultatet

let result = vec![1, 2, 3, 4, 5]
    .iter()
    .map(|x| x * 2)
    .filter(|x| x > &5)
    .collect::<Vec<_>>();

är det verkligen message chaining då?

Koden följer för språket vedertagna mönster och alla vet precis vad som händer. Anser du att dessa kodmönster försvårar refactoring? Skulle du vilja ha friheten att låta en del-constructor returnera något annat? I Pipeline-fallet skickar du bara in funktioner till map och filter, är det hämmande för din frihet som programmerare att map och filter beter sig som de gör?

Lyft blicken och tänk på vad koden gör istället för att låta ryggmärgsreflexen säga message chain, dåligt.

Men det är väl i princip bara du som tror att det du har visat (kodmässigt) säger någonting om dig som utvecklare, bra eller dåligt.

(jag skulle säga att det du visat i övrigt säger en hel del om dig som utvecklare)

Bra är bra, nytt är oftast inte bra.

Med lite självinsikt så inser man också att det man själv ser som "nytt" är nytt enbart för att 100 andra har gjort samma sak före en, men insett att det är idiotiskt och kastat den lösningen.

Terence Howard t.ex. är ett ypperligt, aktuellt exempel på detta.

Du postade ju en video tidigare i denna tråd som pratade om "couplings/message-chains" och varför det är dåligt.

Samma video nämnde också att "pipeline-style" ser på ytan ut lite som "message-chains", men den förra saknar problematiken med stark koppling och är därför inte alls problematiskt.

Gissar att du missat den nyansen och framförallt missat när det är "message-chains" resp. "pipeline-style".

Om man förenklar det hela till att bara visa typer ser det typiskt ut så här

Message chains (bad)

T -> T-method -> S -> S-method -> P -> P-method -> Q -> Q-method ...

Pipeline style (good)

I fallet build pattern där T är konfig-objekt och S är skapat objekt

T -> T-method -> T -> T-method -> T -> T-method -> T -> T-method -> S

I fallet map/filter/reduce/etc

[T] -> filter[T] -> [T] -> map[T] -> [S] -> reduce[S] -> S

I.e. kod med många message-chains skapar beroende mellan många typer på ett sätt som potentiellt gör det svårare att byta ut/ändra i någon av de ingående typerna.

Kod med pipeline-style är generellt sett bara lättare att läsa då den innehåller återkommande och rätt standardiserat mönster som typiskt opererar på en/två specifika typer per gång.

Builder-pattern har flera fördelar

1. vettig sätt att exponera väldigt flexibla/komplicerade strukturer där man oftast (men inte alltid) väljer att förändrar några få parameters

2. går att ha flera builders mot samma gränssnitt, så en komplex typ T (t.ex. någon form av fordon med hjul) kan ha olika builders för att skapa t.ex. terrängbil, racerbil, arbetsfordon, lastbil, etc.

3. det lyfter ut en potentiellt rätt komplex del ur en typ där builder-delen bara är relevant för att skapa en instans av typen, men efter det är helt irrelevant.

Så var aldrig med på att du ansåg build-pattern dålig. Trodde du ansåg att den på något sätt gick att göra mycket bättre i C++ jämfört med andra språk (vilket kändes helmysko)

Det är ohälsosamt att vara så pass känslomässigt knuten till sin kod. Fältet rör sig snabbare än kapaciteten för en enskilds lärande så det finns alltid något att lära sig och ingen blir fullärd.

Nja, det är väl framförallt för att du tycker om att skylta med kod som inte har med ämnet att göra.

Jag tycker att skryt är OK men då får man backa det. Att skryta samtidigt som man är sämst i klassen ser dumt ut.

Skryt tycker inte jag hör ihop med lärande. Jag tycker att det är hälsosammare att lära sig från andra hållet. Att man publicerar sin kod för kommentarer om man har svårt med något eller vill få hjälp med optimeringar, istället för att publicera sin kod med syftet att hävda sig. Att hävda sig inför osäkra personer hämmar snarare dialogen.