Ciklusváltozónak ... használok.

Programozás

i
16% (152 szavazat)
i, j, k ... valami egykarakterest
30% (288 szavazat)
valami jelentéssel bíró több karakterest
11% (105 szavazat)
helyzetfüggő: van hogy egykarakterest, van hogy több karakterest
41% (386 szavazat)
Egyéb, leírom.
2% (18 szavazat)
Összes szavazat: 949

( dejo v | 2023. 01. 01., v – 11:00 )

Ha nincs jelentősége, akkor persze, hogy i, j, k.
De ha van értelme jelentéssel bírónak akkor azt.

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

( uid_17626 | 2023. 01. 01., v – 11:17 )

Szerkesztve: 2023. 01. 01., v – 11:18

Amikor a változó nem árul el semmit, csak mondjuk iterációban van, akkor használom. De! Eddig úgy tudtam azok  együttes használatát kell elkerülni aminek a betűképe hasonló vagy együttes használata nehezen olvasható.

Ilyen a typoban [i, j] [i,l] [m,n] [p,q] [a,c]  [g,q] [o,p] ...

+ nekem már gyanús, hogy ha egymásba ágyazott for-ciklus van, akkor ott már a kettő között van tartalmi összefüggés, és lehet beszédes neveket adni. Mondjuk 2D array(-szerű) adatstruktúráknál x/y, bizonyos algoritmusoknál left/right, stb. Az i/j (a/b, stb.) nekem már határeset, hacsak nem egy-két soros a teljes ciklus.

Nem én találtam ki.

Lehet, hogy pont ez a bajom. :)

Mindenki OCD-s meg PTSD-s arra, amit mar kicsit is latott cirkuszt okozni es lassan jott ra miert. Igy tanulunk mi emberek.

De valahol meg kene talalni a balance-t a "nem igaz, hogy nem birod ki, hogy masik forrasfajlba is belenezel" es a "felesleges kognitiv terheles mas forrasfajlba rakni / abban a forrasfajlban hagyni" kozott pl.

Egyik forumtarsunk alairasara eskuszom: the only valid measurement for coding quality is wtfs/min. :)

( gargamel | 2023. 01. 01., v – 12:10 )

Csak akkor szoktam az i,j,k-tól eltérő iterátor neveket használni, ha több egymásba ágyazott, hosszú ciklusról van szó, de ugye itt jön(ne) képbe a refaktorálás.

I hate those Smurfs!

( KGer | 2023. 01. 01., v – 12:33 )

a java stream óta már csak nagyon ritkán kell bármilyen index változót használni, és van hogy az is code smell gyanús

( enpassant v | 2023. 01. 01., v – 12:41 )

Vannak sokkal jobb megoldások az indexeléses for ciklusoknál. Azokat használom.

A magyarázatból is látszik, hogy kevered. ;-)

Ha 20-30 alkalommal pislogsz, hogy ki kivel van, akkor még nem szoktad meg, így persze, hogy tévesen azt gondolod, hogy kevésbé olvasható. Az olvashatóságot csak úgy érdemes összehasonlítani, ha két ugyanolyan megszokott dologról van szó.

persons.map(person -> person.getName())

vs.

List<String> result = new ArrayList<>();
for(Person person : persons){
    result.add(person.getName());
}

Ha ugyanolyan megszokott mind a két szerkezet, akkor az első könnyebben olvasható, mint a második.

1. A masodik peldadat kb. senki nem hasznalja pont igy. Pont azert, mert konszenzusosan olvashatatlan.

2. Vannak olyan alternativak, amiket 2-3-4 nezes/pislogas utan megszoktam. A map-nal ez nagyon nem igy ment. Van osszehasonlitasi alapom boven.

3. A fentebbibol kihagytad az assign-t, hogy rovidebbnek tunjon, csaltal.

4. A lentebbibol legalabb az egyertemu, hogy mi hanyszor fut le es hogy hogy lehet belole valami gyorsabbat osszerakni ha nem eleg jo. A fenti write-only.

1. Ezt csinálja a map, azért az a példa.

2. Várom az alternatívákat, amikor egy collection-t át kell alakítani.

3. Milyen assign-t?

4. A fentiből is, csak nem szoktál hozzá. Pont annyiszor fut le, ahány eleme van a persons collection-nek. Nem lehet gyorsabbat összerakni, ha az a cél, hogy minden elemét átalakítsuk ;-) Talán vannak olyan nyelvek, ahol lassabb a map, mint a ciklusos szerkezetek, de amiket én ismerek, ott legalább olyan gyorsak, pl. Haskell, Scala, Rust.

A fenti write-only.

Kb. csak folytonosan ki kell olvasni:

A személyek minden elemét alakítsd át úgy, hogy a személyt cseréld le a személy nevére.

Kizárólag hibakezelésben használom, amikor hiba esetén a függvény végén például hibát logolok, lezárok hardware eseményeket, file-okat, akármit, majd kilépek. Az assembly más, mert ott mindig GOTO van, vagy nevezik branch-nek, jump-nak, bárminek. Esetleg feltételes skip és utána goto.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( asch v | 2023. 01. 01., v – 14:20 )

Csak egy sith gondolkodik végletekben.

( zsolt | 2023. 01. 01., v – 14:34 )

Kedvenc hozzászólásom a szálból:

How about standardForLoopIncrementingIndexCounterWithNothingSpecialAboutItWhatsoever?

Alig várom a holnapi munkanapot, ez első ciklusomnál ezt fogom használni. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

( gelei v | 2023. 01. 01., v – 15:43 )

Aki nem "helyzetfüggőt" választott, az miért nem? :)

Előrebocsátva: csak "kocaprogramozó" vagyok, ami magamnak kell és le tudom programozni (értsd: tudás és idő is adott), azt megcsinálom.

Olvasgattam a Robert C. Martin-féle Clean Code könyvet, és próbálom a benne lévő elvek jelentős részét betartva a programocskáimat írogatni. Nem fájdalmas ciklusváltozónak egy karakternél hosszabb nevet választani, és többször úgy tapasztaltam, hogy tényleg hasznos. De amikor lehet, a for-ciklusokat igyekszem kiváltani az lapply-val (vagy hasonlóval), ilyenkor az esetek nagy részében nem is kell ciklusváltozó.

Azert mert az a helyzetfuggo az nalam az esetek 99%-ban az egybetus kategoria (vagy i2, i3, i4..., de en azt belevettem az egybetusbe, mert kb annyira descriptive) Nyilvan ha van valami nagyon egyertelmu es frappans nev amit lehet a valtozonak adni, akkor adok neki, de elegge ritka., foleg ha szigoruan ciklusvaltozot nezunk, es nem pl a foreach valtozojat (bar nalam az is sokszor egybetus...).

I hate myself, because I'm not open-source.

Mert ritkán helyzetfüggő. Persze, egy mátrixszorzásra nem írnék olyat (bár, végülis, miért ne?), hogy

do irow = 1: n
  do icol = 1: n
    c(irow, icol) = 0.0_dp
    do isum = 1: n
      c(irow, icol) = c(irow, icol) + a(irow, isum) * b(isum, icol)
    end do
  end do
end do

de főleg azért nem, mert olyat írnék, hogy

auto c = prod(a, b)

azaz a nagyon elemi és gyakran előforduló dolgokra (ahol nyugodtan lehetne i, j, k, ..., mert a hülye is látja, hogy miről van szó) úgyis van függvény, a kevésbé elemi dolgoknál pedig nem baj, ha beszédes, numIterations, indexPolygon, .... Biztos előfordul, hogy mégis meg kell írni valami trivialitást, akkor kivételt teszek.

( BehringerZoltan | 2023. 01. 01., v – 15:52 )

Elsősorban amit az előírt coding standard meghatároz. Ha beszédes neveket kell hasznáéni akkor lehet kreativkodni (meg átirni a copy-paste -t ;-D)

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

( Chain-Q v | 2023. 01. 01., v – 16:11 )

Én évekig, egész zsenge programozópalánta korom óta beszédes neveket használtam ciklusváltozóra, mert az i, j, k, l, stb, amit a példakódokban használtam nem éreztem eléggé kifejezőnek. De kb. én voltam az egyetlen a környéken, emiatt emberek még szóvá is tették, code reviewban meg itt ott, hogy mi ez a non-standard izé, hagyjam már.

Szóval végül, úgy tíz éve leszoktam róla. Amúgy is, már annyi kódot írtam, hogy értem mit csinál beszédes változónevek nélkül is. Húsz évvel később úgy tűnik, ez most újra téma lett. Arról nem is beszélve, hogy rájöttem, hogy az "i" önmagában is beszédes név, mert az "index" szónak felel meg, a boldog békeidőkből, amikor a tömbök még valóban tömbök voltak nem tömbnek álcázott láncolt listák vagy hashtáblák és minden fejlesztő tudott assemblyben is (v.ö. "index regiszter" pl., x86-on ugye SI/DI (source index, destination index)...).

Nekem inkább az a gondom mostanában, hogy pl. ha felmerül bármilyen meetingen, hogy "a szoftverminőség javítása" akkor a fejlesztők 95%-a nem pont ilyen változónévadási, kódformázási és indentálási hülyeségeken kezdene el rugózni, ahelyett hogy arra fókuszálna, hogy mondjuk a szar ne fagyjon annyit és ne leakelje el az összes RAM-ot is. De ez már egy másik rant lenne... :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( locsemege v | 2023. 01. 01., v – 17:05 )

Használok egybetűseket, mert fél napomba telne egy frappáns név kitalálása, ami kizökkent. Épp elég ez a függvényneveknél. További gond, hogy használok olyan kifejezéseket, hogy egy struktúra egyik tagja tömb, annak indexe egy pointer által mutatott struktúra tagja, ami indexelve van, s amelynek van egy tagja, majd ennek az egésznek van még tagja. Ez hosszú, beszédes indexnevekkel halálosan áttekinthetetlen, nem törhető a sor úgy, hogy olvasható maradjon, az meg szintén nem jó, ha már a vízszintes scroll bar-t kell matatni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( uid_6201 v | 2023. 01. 01., v – 19:09 )

Szerkesztve: 2023. 01. 01., v – 19:12

A szavazás kérdésfeltevése nem teljesen korrekt, hiszen vannak esetek, amikor nem hogy egykarakteres, de egyáltalán nincs ciklusváltozó.

( nagyjoco | 2023. 01. 01., v – 20:04 )

Nemrég refaktoráltam korai kódjaim, ahol még i-t használtam, és azt gondolom, sokkal jobb egy line, ha txt file következő soráról van szó,  satöbbi. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

( BikMak | 2023. 01. 01., v – 21:56 )

Igyekszem nem használni ciklusváltozót. Ez kotlinban egész könnyen megoldható :)

( uid_4263 v | 2023. 01. 01., v – 22:24 )

Szerkesztve: 2023. 01. 01., v – 22:25

Nagyrészt (99%) java-zok, ott pedig inkább foreach-elünk ma már. Egyébként "i". Hagyományos.

Ha nem kell sehol se a változónév, szokás _ jelet betenni. Ezzel először Python kód esetén találkoztam. Tehát nem nevesítjük, ami nem kell.

for _ in some_file { ... }

Ha pedig mégis nevesíteni akarjuk, mert segít a megértésben, akkor _line, ezzel jelezve hogy nem akarjuk semmire használni.
Egyébként Python3 esetén még normál változó ez, print(_) kiírja az _ értékét. Rust esetén az _ ténylegesen a "nincs változónév" szerepet tölti be, ezáltal nem enged az _ jelre változóként hivatkozni.

De ez miért gond? Mármint értem, sok nyelvben létezik ilyen, ez egy tök jó feature (én is használom) de ettől még a szavazás megválaszolható. Azokból az esetekből kell kiindulni a szavazáskor, amikor van ciklusváltozó. :)

Milyen gyakran van olyan, hogy végig kell iterálni egy listán, tömbön, akármi, de nem kell semmit kezdened a konkrét adatokkal? Nyilván előfordul ilyen, de ez inkább a kivétel, nem? A példámban a "pass" helyére ne egy statikus szöveg N számú printelését képzeld oda, hanem valami érdemi feldolgozást. Nagyon ritkán kell végigiterálnom úgy egy szövegfájlon, hogy egyik sorával sem kezdek semmit. Hirtelen csak az jut eszembe, ha valamiért meg kell számolni a sorok számát, de akkor már sokkal olvashatóbb egy len(someFile.readlines()) nem?

Vagyis az i-t általában nem tartalmazza a program kimenete, csak az adat[i]-t.

goto :) Persze, legtöbbször nem. Csak amikor látok legacy kódban három egybeeágyazott for-ciklust, akkor örülnék neki, hogyha nem i-j-k lenne a változó neve, hanem valami értelmes. A fenti BUÉK-os példákban teljesen mindegy, persze, de az meg a másik véglet.

Nem a kimenet miatt érdekes, hogy mi a változó neve, hanem az én kognitív terhelésem miatt. :)

Szerintem ezért jött létre a for each.

Ja, én is azt használom az esetek 99%-ában, de szigorúan véve ciklusváltozó abban is van. :)

( ivanov | 2023. 01. 01., v – 22:57 )

Modernebb nyelvekben altalaban van lehetoseg iteralasra ciklusvaltozo-mizeria nelkul, legtobbszor azt hasznalom.
Ha megis kell a ciklusvaltozo, legtobbszor egy karakteres nevet hasznalok (i,j,k,l), mert altalaban nincs semmilyen kulonos jelentese (es mert matek), neha, amikor van, vagy szeretnem javitani az olvashatosagot (pl. tobb  van beloluk), el szoktam nevezni felhasznalasnak megfeleloen: <whatever>Index, <whatever>Count, etc.

https://develotters.com

( dotnetlinux | 2023. 01. 01., v – 23:37 )

node

i-t hasznalnék, de a lint beszól, higy inkább index legyen. Elfogadom.

Ahol pedig for...of van (esetek 90%-a), ott az elem nevének jelentése van, nincs index változó. 

( Raynes v | 2023. 01. 02., h – 01:24 )

Ebben én is bűnös vagyok, legtöbbször reflexből i, j, k, l, stb. megy ciklusváltozónak. Régi megszokás, BASIC és Pascal könyvekben is ezt láttam mindenhol, beidegződött. Igazából ez az általános programozói szokás még régebbre megy vissza, pl. a Fortran-ben is ez volt, hogy a változó nevének első betűje jelezte a típust is, pl. az i-vel kezdődőek integer típusúak voltak, és ez így van a mai napig is, ha az ember az implicite none-t nem teszi be a program elejére. Innen el is terjedt az a Fortran-valami más while, until szerkezet, vagy case, hasonlóvicc, hogy „god is real”, mivel a g, o, d-vel kezdődő változók lebegőpontos real típusúak voltak alapértelmezésben.

Az indiánnak teljesen igaza van, 2023-ban erről már illene leszokni, nincs sok értelme, jobbak lennének a beszédes változónevek, de hát a megszokás túl nagy úr. Még a megszokás se lenne akadálya, a goto-ról is leszoktak a népek végül, erről az i, j-zésről is épp úgy le lehetne jönni. Igazából már a for se annyira népszerű, inkább oldják meg máshogy a loopokat. Pláne funkcionális programnyelveknél vannak rászorítva, hogy nincs for, helyette rekurzív loop van.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( gargamel | 2023. 01. 02., h – 07:34 )

Arról ugye nem is beszélve, hogy mindennek az alapja a matek. Ilyen-olyan matematikai egyenleteket sokkal könnyebb azokkal a változónevekkel, ciklusváltozókkal kódolni/debuggolni, amit a szakirodalom használ. Az meg ugye olyan rövid és tömör, amennyire csak lehet.

I hate those Smurfs!

Ti is a szakirodalomban szereplő változóneveket szoktátok használni? Például:

fn reaktancia(f: f64, c: f64) -> f64 {
    let ω = 2.0 * π * f;
    1.0 / (ω * c)
}

Bár nem mindig, de néha szoktam ilyet csinálni, mert kifejező. Sajnos csak a vi / vim képes natív módon bevinni a :set digraph beállítása mentén a p<törlés>* és w<törlés>* karakterkombinációval. A μ jelet pedig m<törlés>* kombinációval. Az  Ω pedig W<törlés>* kombinációval vihető be.
Más editorok esetén nem tudok ilyen lehetőségekről. Esetleg érdemes lehet összeszedni, hogy a szakirodalom szerinti változó jelölést tudjuk használni a képletekben.

Ide kapcsolódik: https://hup.hu/node/180403
Hogy még mindig nem tudtak kihalni a nem UTF8-as rendszerek.

Tessék megnézni a dátumokat. Nem 5..10 év telt el azóta.
    https://www.ietf.org/rfc/rfc2044.txt - "informational"
    https://www.ietf.org/rfc/rfc2279.txt - "standards track"

És ma még mindig ott tartunk, hogy a legtöbb programozási nyelven külön kell figyelni, ha UTF8-ként akarod feldolgozni vagy továbbadni az információt.
A Rust jelenleg az egyetlen üde színfolt, ahol a string kizárólag UTF8. Pedig sokat segítene az egységesedésben, ha az UTF8 a stringekre programozási nyelv szinten ma már alap lenne és nem valami pluszkörös "ha gondolsz rá, megvalósíthatod" valami.

Ez nem ilyen egyszerű. C-t vagy assembly-t hogyan UTF8-asítod programozási nyelv szinten, amikor byte-ot címzel? Az UTF8 ráadásul nem fix szélességű, adattartalomtól függ a szóhossz. Sőt, nincs string típus, hanem az egymás után dobált karakterekre rámutatsz, hogy mától fogva string a neved, meg a végére biggyesztel egy nullát.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Amíg csak berántasz egy zárt számvektort és kinyomod valahova a zárt számvektort feldolgozás nélkül, addig tényleg mindegy. A számvektor az számvektor marad.
De játszunk tovább a gondolattal. Tördeld be például 10 hasábosra a nem angolszász betűkből álló UTF8 szöveget, netán végezz vele egyéb transzformációt.

És akkor jön az, hogy ja kérem, ne használjon a "random anyanyelvű user" saját nyelvén ékezetet, mert a szoftver nincs felkészítve az UTF8 karakterekből álló szöveg feldolgozására, átalakítására.

Számomra még az is kérdés, hogy a sokbyte-os UTF8 karakterek belsejében lehet-e valahol 0, mert ha igen, akkor az végképp világvége. Bár valahol mindegy is, mert semmiképp sem lehet végigmenni rajta byte-onként, mindenképp karakter szintű interpretáció kell.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem, nem lehet benne. Az UTF-8 az ezen felul ugynevezett self-synchronizing code, szoval relative nehez elrontani egy UTF-8 stream ertelmezeset. Es a "surrogate" blokkot leszamitva teljesen egyertelmu a lekepezese (de ugye azt a bizonyos UTF-16ot is bele kellett eroszakolni...)

Erre vannak libek, amelyek figyelembe veszik az LC változón alapulva, hogy mi a kódolási séma, és ennek megfelelően kezelik a null karaktereket, stringeket. Abban viszont nem tévedsz, hogy UTF-8-nál már nem úgy megy, hogy végigjárod a stringet bájtonként.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nincs UTF-8 belsejében 0 bájt. A 0 karakterben van, de az pont a lezáró ugye. Nem véletlenül van ez így, akik az UTF-t kitalálták nem voltak hülyék. Ha nem vágod el a stringet, akkor mindent jól fognak kezelni az eredeti C string műveletek is.

Egyébként a 0-val zárt string tárolás rengeteg szempontból nem jó, érdemes leszokni róla ha lehetséges. Én is C rajongó voltam régen, meg még kicsit vagyok is, de erről beláttam, hogy jobb a hossz+puffer tárolási mód.

Van egy nénikém, aki állandóan kezet mos. De nem tud leszokni róla. Mondja, mi jó van abban, kezet mosni?

/Rejtő Jenő: A szőke ciklon/

Idézem:

EF BB BF 30 30 30 30 20 ...

Bizony, a mániákus kézmosásból kifolyólag így kezdődik egy hexdump, amely csak a {CR}LF[0-9][A-F] karaktereket tartalmazhatja, esetleg a DOS 3.0 kompatibilitás miatt még a ^Z-t is.

Eleve elrendeltetett, hogy a kezdés a byte order mark, - ami utf8 esetén pont szükségtelen, - de azért odaírják, mert így egyértelmű az encoding. :-D

Jó (lehet) az utf8, ha multilangual text adatokkal dolgozol, vagy írsz ki valahova, de egyébként csak púp a hátunkra. Ha a programok fajtáit számszerüsítjük és nem a darabszámát, akkor a többségében inkább hátrány az utf8 alkalmazása.

Ez Rust? És a compiler tudja, hogy a π = PI, vagy azért valahol előtte meg kell neki mondani?

Egyébként inkább a görög betűk angol neveit használom: alpha, beta, omega stb. "pi"-t soha nem használnék változónévként.

//off: Az ω-t ki is lehetne ejteni: 1.0 / ((2.0 * π * f) * c)

I hate those Smurfs!

( locsemege v | 2023. 01. 02., h – 12:12 )

Tehetek én arról, hogy Z80 CPU-n egybetűs például a 'B' regiszter neve? :)

LD B, valamennyi
loop:
;....
DJNZ loop

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( marcabru | 2023. 01. 02., h – 14:33 )

Szerkesztve: 2023. 01. 02., h – 14:43

tizenévesen megtanultam a jó öreg c64-emen, hogy csakis I, azóta sem változtatok ezen.

10 FORI=0TO20STEP2
20 PRINTI
30 NEXTI

Még a végén elrontanám, és akkor jön a, aztán lehet keresgélni a GOTO spagettik között, hogy mi történt. 

?NEXT WITHOUT FOR  ERROR IN 30
READY.
█

( NevemTeve | 2023. 01. 02., h – 16:58 )

Szerkesztve: 2023. 01. 02., h – 16:59

Határeset:

for (i=0, found=-1; found==-1 && i<N; ++i) {
    if (...) found= i;
}

Meta: ha egyvalami zavaró a fórumozásban, az èppen az, amikor az emberek nem tudnak tömören fogalmazni, hanem végtelen hosszúságban magyarázzák a gondolotaikat, egyre újabb és újabb érvekkel állnak elő, számtalan részlettel és példával megspékelve, míg végül tényleg oda jutunk, hogy mire a hozzászólás végére érek, az elejét már el is felejtettem.

( davies007 | 2023. 01. 03., k – 17:53 )

2023 -ban elérkeztünk oda, hogy a programnyelveket elkezdtük lebutítani, hogy a szerényebb képességű emberek is tudjanak programozni.
Noha a legtöbb programozó írása eléggé csúnya és itt nem a változónevek vagy a style -ra gondolok, hanem arra a transzlogikus gépszopató dologra amiből gyorsan kisül, hogy életében nem volt még mikrokontrolleres környezetben és fingja nincs az írónak a számítógép működéséről. 

De megalakult a Rust és a GOlang is ami nagyon jó egészen addig amíg nem próbálja meg velem azt éreztetni, hogy én vagyok az ostoba, hogy C/C++ -ban dolgozom ami nem biztonságos a memória kezelés végett és miért nem váltok inkább a RUST -ra ahol ez megvan oldva és amúgy is tizmillió C/C++ -ban fordított wrapperelt lib van hozzá.

Ilyen bohóc világban élünk. 

Running on FreeBSD/Bhyve

Utalom azokat, akik szerint a Rust/Go "meg fogja olni" a C/C++-t. Vegtelenul szuklatokoruek, raadasul sokszor kinosan magas pozicioban.

Meg azt el is hinnem (de nem igazan hiszem), hogy 5-10 ev mulva nem fog uj projekt keszulni C-ben. De hogy nehanyan ugy viselkednek, mintha realis lenne hogy karbantartani se kell majd semmilyen meglevo C/C++ projektet, az nagyon ijeszto.

Látom semennyire sem ismered a Rust-ot. ;-)

a programnyelveket elkezdtük lebutítani, hogy a szerényebb képességű emberek is tudjanak programozni.

Ennek pont az ellenkezője történik. A Rust-nak elég magas a belépési küszöbe, a szerényebb képességűek azt meg sem tudják ugrani. Miközben a lehető leginkább a biztonságos programozást helyezi előtérbe (a program hibák 90+ százaléka memória hiba), aközben meghagyja az eszközöket a legalacsonyabb szintű kezeléshez is, pl. mikrokontrolleres környezet.
Az sem véletlen, hogy a Linux kernel fejlesztésébe beemelték, szemben a C++-szal. Ezen is elgondolkodhatsz, hogy vajon azok, akik eddig még a C++-t is az ördögtől valónak tartották a C-hez képest, azok miért tartják jónak a Rust-ot.

Ha valamit nem vagy hajlandó mélységeiben megismerni, akkor ne kritizáld!

( Toth Lali | 2023. 01. 05., cs – 21:21 )

külső ciklus: _

belső ciklus(ok): __ (___,...)

( GerzSonka | 2023. 01. 05., cs – 21:43 )

Attól függ. Pythonban például ha listán iterálok

for op in operations:

De amúgy meg C++-ban

for (i=0; i<5; ++i)

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods