- Fotók, videók mobillal
- One mobilszolgáltatások
- 65 órányi zenét ígér az Audio-Technica új TWS fülese
- Yettel topik
- Samsung Galaxy Watch7 - kötelező kör
- iPhone topik
- Csíkszélességben verné az Exynos 2600 a Snapdragon 8 Elite 2-t
- Samsung Galaxy A53 5G - kevesebbet többért
- Sony Xperia 1 V - kizárólag igényeseknek
- Milyen okostelefont vegyek?
Új hozzászólás Aktív témák
-
ToMmY_hun
senior tag
válasz
dobragab
#3425
üzenetére
A feladat nem, a megoldás viszont lehet hogy az.
A két mátrix szorzatán egyelőre elegendő lenne az aktuális paraméterekre a függvény által visszaadott számértékek egyszerű számként való szorzatát érteni. Azért emeltem ki a szorzatot és összeget, mert úgy szeretném megcsinálni, hogy a függvény eredményeként adott számot adja, illetve szorozza össze a program akkor, ha én a függvényre mint objektumra hivatkozok.
Az x és y matematikai értelemben paraméterek, tehát a függvény hívásakor értékük ismert.
-
EQMontoya
veterán
válasz
dobragab
#3418
üzenetére
Anno én is így voltam ezzel, amikor még fiatal voltam, és balga. Ugyanakkor rengeteg olyan probléma van, amire a manapság használt, erősen típusos és fordított nyelvek (c++, java, c#) egyszerűen túl komplikáltak, nehézkesek sok esetben. Szóval jött a shell sript, majd a Python.
Pl. ki akarok szedni A mappából minden olyan filet, aminek a neve illeszekedik egy regexre, a héten volt módosítva és nem tartalmazza az "aszpartam" szót.
Vagy pl. egy logfilet kellett bányásznom, abból kiszedni bizonyos sorokat, azokból bizonyos adatokat, ebből gyártani egy html táblázatot és azt elküldeni mailben. Ezt meg lehet oldani persze javaban is, de Pythonban "kicsit" kényelmesebb. -
ToMmY_hun
senior tag
válasz
dobragab
#3418
üzenetére
Tényleg sok helyen használják. BigData elemzéshez rengeteg Python-ban íródott eszköz van, szóval az is sokat segít a felhasználóbázis növelésében. A szintaktikáját én sem szeretem, de még mindig sokkal barátságosabb, mint a Perl. Van egy olyan vicc, hogy mi lesz ha leültetsz egy millió majmot kódolni? Egy majom C++ kódot ír, a többi Perl-t.
-
EQMontoya
veterán
válasz
dobragab
#3348
üzenetére
Amivel nem csinálsz semmit, mert nem kerül bele a coutba!
![;]](//cdn.rios.hu/dl/s/v1.gif)
Egyébként az első sor önmagában nyilván nem csinál semmit, elvégre a C elején az A rész van.
A virtuális desktruktorral (és bármi egyéb virtuális függvénnyel ugyanúgy) viszont behozol egy vptr-t a class elejére, tehát az elején már nem A lesz. -
kobe24
tag
válasz
dobragab
#3338
üzenetére
Köszönöm ismét a segítséget!
Ezzel a megoldással amúgy csak annyi a problémám, hogy a második résznél azt se értem mi történik. Biztos ez a legegyszerűbb módja, de egy minimális magyarázatot kaphatok, mert érteni is szeretném a programomat, de ez egyelőre csak összekavar.
-
jattila48
aktív tag
válasz
dobragab
#3322
üzenetére
Jó összefoglaló, csak egy kis kiegészítést engedj meg:
"- default ctor: végighívja az ősosztályok és adattagok copy ctor-át, sorrendben."
Itt fontos megjegyezni, hogy az ősosztályok ctorát az öröklési sorrendben, az adattagokét pedig deklarációjuk sorrendjében hívja. Vagyis nem feltétlenül a taginicializáló listában írt sorrendben (néhány fordító warning-ot generál, ha a taginicializáló lista sorrendje eltér a deklaráció sorrendjétől). Ezek után hajtódik végre a szóban forgó objektum ctorának törzse. A destruktorok hívása éppen fordított sorrendben történik: Először az adott dtor törzse fut le, ami végül a ctor-ok hívásának fordított sorrendjében meghívja az adattagok és ősosztályok dtorait.A move operációt illetően: a szabvány bizonyos feltételek mellett (kb. amit leírtál) előírja implicit move operáció generálását, azonban erősen kétséges, hogy ez valóban jó ötlet-e. Bizonyos fordítók (talán a VS2010 is) ezt nem teszik. Ha egyáltalán generálható implicit move operáció, akkor az kb. ugyanaz mint a copy operáció, ezért fölösleges a move. A move-nak akkor van igazán értelme, amikor implicite nem generálható, pl. user defined dtor esetén. A move-val legfőbb probléma az, hogy milyen állapotban maradjon a moved-from objektum, vagyis az operáció forrás objektuma. Legyen default konstruált? Mi van, ha nincs default ctor-a? Az "elmove-olt" erőforrást a dtor-nak már nem szabad felszabadítania. A moved-from objektum egyfajta "zombivá" válik, hasonlóan a kétfázisú inicializálással létrehozott objektum esetén, amikor a ctor már lefutott, de az inicializálás még nem történt meg teljes egészében (ez mint tudjuk, kerülendő). A moved-from objektum ezután már csak copy vagy move assignment cél operandusaként használható, vagy megsemmisítendő, de minden esetre ügyelni kell rá, hogy ne használjuk újra (mint ahogy a félig inizializált objektumokat sem).
-
ToMmY_hun
senior tag
válasz
dobragab
#3322
üzenetére
Nagyon szépen köszönöm a részletes leírást!
Nekem sok újat mondtál és gyors összefoglalónak kiváló - legalábbis így kezdőként könnyen fel tudtam fogni. A biztonság kedvéért a mester könyvében lévő konstruálással foglalkozó fejezetet tervezem átnyálazni, bár sok információt a cppreference.com-on is leírnak.Java-hoz képest jóval bonyolultabb a konstruálás (is), de nagyon szimpatikus az a precizitás, amit a nyelv megkövetel. Kivéve amikor ilyen apróság miatt megy el pár óra.
EQMontoya: "Elég fontos dolog, ha mélyebben belemész a c++-ba." Teljesen jogos, meg is van a programom estére.
-
dabadab
titán
válasz
dobragab
#3313
üzenetére
"Amíg nem érti tökéletesen, mi az a tömb, hogy a méretét nem tudja lekérdezni függvényből, hogy mi köze a pointerhez, stb. addig nem szabad neki std::vectort tanítani, mert utána már sosem tanulja meg, mi is az a tömb."
Ez abszolút nem igaz. Én is megtanultam, pedig BASIC tömbökkel kezdtem, amik sokkal több rokonságot mutatnak az std::vectorral, mint a C-s tömbökkel.
Valahol el kell kezdeni a tanulást és nem lehet rögtön kettes számrendszerrel meg mutatókkal kezdeni, mert hiányoznak az alapok ahhoz, hogy meg tudják érteni, hogy mi az. Meg én is előbb használtam virtuális függvényt, minthogy tudtam volna, hogy mi az a vtable, aztán mégis ember lettem
-
jattila48
aktív tag
válasz
dobragab
#3266
üzenetére
VS használható mingw-gcc-vel. Próbáld ki a VisualGDB-t. 30 napos teljes értékű próba verzió, utána fizetős (nem túl drága). Vannak még hibái, de egész jó. Az MSVC-nél én is találtam olyat amit le kellett volna fordítania, de mégsem tette (ezeket itt meg is tárgyaltuk). Amit "többet" tud mint a szabvány (microsoft extensions), arra adhat warning-ot, vagy hibát, vagy semmit (beállítható). Ilyen pl., hogy temporális értéket megenged nem const lvalue referenciához kötni (szabvány szerint csak const lvalue vagy rvalue referenciához lenne köthető).
-
jattila48
aktív tag
válasz
dobragab
#3260
üzenetére
"Windows-ra fordításhoz ott a mingw-gcc cross"
A mingw-gcc valóban jó, de még kell rajta dolgozni. A Windows COM-mal pl. nagyon nem boldogul. A saját headereit sem mindig fordítja le. Különböző rejtélyes makrókat kell #define-olni (vagy preprocessor-nak definiálni), hogy rá vedd a fordításra. Több tízezer soros header-ek esetén ennek kiderítése igencsak strapás.
-
jattila48
aktív tag
válasz
dobragab
#3260
üzenetére
Ez lehet, de ha speciel Windows-on kell vele dolgoznom, akkor nem vigasztal. Linux-on nem kell buildelni, nem függ a gcc verziójától, a lib-ek verziói is stimmelni fognak, vagy csak mindezt magától megoldja az apt-get? Azért Linuxon is szívtam én már hasonlóan (a boost-ot nem használtam).
-
dabadab
titán
válasz
dobragab
#3239
üzenetére
"Megírhatták volna a contains-t is, de minek?"
Ergonómia, ahogy mondtam.
Melyik olvashatóbb?if(mmap.count("idk"))
vagy
if(mmap.contains("idk"))
Lefordítva meg mind a kettő ugyanaz, az STL kódolásánál meg dokumentálásánál meg kb. nulla többletmunkát jelentett volna és nagyjából ez lenne a második-harmadik leggyakrabban használt metódus a konténereknél.
-
ToMmY_hun
senior tag
-
ToMmY_hun
senior tag
-
ToMmY_hun
senior tag
válasz
dobragab
#3224
üzenetére
Köszi szépen a részletes leírást! Jól sejted, valóban Javaztam eddig.
Azt nem hangsúyoztam ki a kérdésemben, hogy kulcs-érték párokat szeretnék tárolni a könnyű visszakereshetőség miatt, szóval vector helyettt inkább map-et használok majd. Szükség lesz egy STL tárolót burkoló osztályra, mert szeretném megoldani hogy az összes konténerben egy kulcs csak egyetlen egyszer szerepelhessen, biztonsági okokból."...std:: ostream-et visszaadó) << operátora..."
Ezt manuálisan overloadolnom kell saját osztály esetén?
Más kérdés: Hamarosan aktuális lesz az álláskeresés, és ennek okán kérdezném, hogy szerintetek mi az, amivel mindenképpen tisztában kell lennie egy juniornak C++ kapcsán?
Köszi előre is!
-
jattila48
aktív tag
válasz
dobragab
#3207
üzenetére
Hát, szintaktikusan biztos hogy hibás. using stílusú typedef-et soha nem használtam (VS2012 le sem fordítja), de nem is értem mit kéne csinálnia. Mi a (void) a swallow előtt? Gondolom különböző típusú argumentumokat írna ki. Kerek zárójelek nincsenek párban, a végén a ... sincs jó helyen (szerintem), szóval ennyi.
-
-
EQMontoya
veterán
válasz
dobragab
#3111
üzenetére
std::vector tudomásom szerint nem malloc-ot hív, hanem :: operator new-t. Ez a tény mondjuk C++ alapjai vizsgán erős.
Ez így erős egyszerűsítés. Egyrészt implementációtól függ. De nézzük akkor x86-64-en.
Std::allocator-t használ ugye alapból a foglalásra.
Utána placement new-val konstruálgat.
Ha pedig törölsz belőle, és nem a végéről, akkor op=-vel pakolja az elemeket visszafelé, majd az utolsót destruálja. (pedig nem azt törölted) -
EQMontoya
veterán
-
jattila48
aktív tag
-
jattila48
aktív tag
válasz
dobragab
#3067
üzenetére
De hát a fájl lezárás most is a dtor-ban van, de nem a ctor-ban van a megnyitás.
B leszármazottai abban különböznek egymástól, hogy más-más helyről olvassák be az egyébként ugyanolyan formátumú bináris adatot. Tehát a leszármazott osztályok egyetlen dolga, hogy ezt megtegyék, és a blob-ot átadják az ősosztálynak (erre van az init). A B nem függ a leszármazottaktól, mert ő már csak a blob-on dolgozik, de nincs értelme önálló B objektumot létrehozni, mert a blob-ot mégis csak be kell olvasni valahonnan.
"Tényleg jobb lenne D konstruktorába pakolni az allokációt, de ebben a formában nem lehet megoldani. Az ős-ctor hívása mindenképp előbb van, mint a ctor törzse, úgyhogy arra nincs esélyed normálisan megoldani."
Hát pont erről beszélek. Ha viszont a D ctor-ában szeretném megoldani az allokációt, akkor mindenképpen B::init-et kell hívnom a D ctor-ának törzsében. Ez lehet, hogy szerinted nem normális megoldás (alapesetben szerintem sem az), de mivel hogy B nem példányosítható, ezért elnézhetőnek tartom. Ha ezt nem teszem meg, akkor valóban csak ez a fajta factory megoldás marad amit írtál, azonban itt az erőforrások átvétele (shared vagy unique pointerek vagy egyéb erre a célra létrehozott osztályok formájában) sokkal macerásabb és több hibalehetőséget rejt, mint az init fv."Mindenesetre a kötelezően hívandó init() szerintem ennél sokkal büdösebb: el lehet felejteni a hívását, és B többet tud, mint a feladata."
Mint ahogy fent írtam, szerintem nem, de ez már ízlés kérdése. Azt hogy el lehet felejteni a hívását, ennyi erővel D bármely más tagjának az inicializálását is el lehet felejteni, ahogy írtam. Tulajdonképpen úgy tekinthető, hogy az init nem a B-t inicializálja, hanem a D inicializálásához szükséges. "Normál" esetben is szokás a ctor-ban különböző tagokat inicializáló fv.-eket hívni. B egyáltalán nem tud többet mint a feladata, mert a forrásról semmit sem tud, csak a blob-ot kapja meg, ami minden leszármazott esetén ugyanolyan formátumú.
"Alapesetben nem kéne, hogy egy osztálynak legyen ctor-ként működő init-je."
Valóban. De ha nem példányosítható? Erről szólt az egész elmélkedésem."Kicsit más jellegű lenne az a megoldás, ha B kap tisztán virtuális read() és write() függvényeket, és azokat override-olja D. Viszont read()-et nem hívhatod ctorból, úgyhogy ez nem működik."
Azon kívül, hogy ctor-ból nem működik, nem lehet megcsinálni, mert forrásonként különböző paraméterezést igényelne. Másrészt ekkor már tényleg fölöslegesen sokat tudna a B és függne a leszármazott osztálytól.
Minden esetre köszönöm az eddigi hozzászólásaidat, most ezt a kétféle megoldást látom alkalmasnak, a mondott okok miatt azonban a sajátomat fogom választani.
-
jattila48
aktív tag
válasz
dobragab
#3062
üzenetére
Ezzel csak az a bajom, hogy ez a megoldás lényegében nem különbözik attól, hogy "kívül" megnyitod a fájlt, memória területet foglalsz, oda beolvasod a fájlt, majd ezt a memória területet átadod a D ctor.-ának. Tehát a fájl megnyitás, és a memória terület foglalás nem a D ctor-ában történik, viszont az erőforrás felszabadítást (legalábbis a fájl lezárást) a dtor-ban akarod megoldani. Ez egy felemás RAII lenne, ami szerintem koncepcionálisan hibás. Az, hogy ezt az egészet bele tetted egy statikus factory fv.-be, a lényegen nem változtat. Sőt az allokált memória terület már a factory fv. lefutásával felszabadulhat (bár itt mivel const & hivatkozás van rá, valószínűleg kitart annak élettartamáig. Egyébként a const & nekem nem lesz jó, mert változni fog a memória terület, amit az objektum "elhalásakor" vissza szeretnék írni a fájlba. nem const referencia pedig tudtommal nem tartja életben a temporális objektumot. Lehet hogy tévedek!). Ha közvetlenül a D ctor-ával hozod létre az objektumot, akkor a helyzet ugyanez. Tehát a statikus factory fv. használata semmit nem tesz jobbá, a zárójeles megjegyzésem értelmében még esetleg rosszabb is lehet.
Ellenben az én megoldásommal a D ctor-ába lehet tenni mind a fájl, mind pedig a blob allokálását, és ezáltal ezeket az erőforrásokat RAII módon lehet kezelni, ahogy "kell". Ennek az ára a B kétfázisú inicializálása, ami azért nem hibás koncepcionálisan, mert sem félig, sem teljesen konstruált B objektumot nem lehet létrehozni. Mindössze a D konstruálása során van olyan pont, amikor a D B része félig konstruált, de ekkor a D még kész sincs. A protected init fv.-t kell meghívni kötelezően a D ctor.-ában, ennek elmulasztása azonban nem különbözik attól, mintha "elfelejtenénk" D valamelyik tagját inicializálni (végül is az ős osztály is egy "tagnak tekinthető"). A tagok inicializálása pedig nem csak inicializációs listában, hanem a ctor törzsében is megtörténhet, pont akkor, ha az inicalizáláshoz számításokat kell végezni. A lényeg, hogy ezzel a módszerrel D-ből csak teljesen konstruált objektumot lehet létrehozni, B-ből pedig semilyet. -
jattila48
aktív tag
válasz
dobragab
#3059
üzenetére
"Ha B önmagában nem olvasható be, vagy D-vel együtt kellene, mert B beolvasása után kellenek még az adatok, D-t is adhat vissza a beolvasó függvény."
Factory? És ez a D-t hogy állítja elő? Egy másik construktorral? Ugyanezzel nem lehet, mert végtelen rekurzió lenne. Hogyan inicializálná a B részét a visszaadott D-nek? Hiszen most pont ezen küzdünk. Vagy ha már a beolvasó fv. visszaad D-t, akkor minek ezt újra felhasználni a D egy másik ctor-ában? Akkor már jó a most visszaadott is. Vagy a beolvasó fv. inicializálatlan B részű D-t adna vissza? Ez ismét csak kétfázisú inicializálás lenne, ráadásul rosszabb mint az enyém, mert konkrétan létre is kéne hoznod félig konstruált D-t.
A statikus tfv.-nyel való inicializálás (nem több, hanem osztályonként csak egyetlen stfv.) életképes lehet, ha nem B-t ad vissza (főleg nem pedig D-t), hanem valami egyszerű struktúrában a bináris adatot (pointer+méret: röviden blob). Itt viszont megint csak az történik, hogy a D ctor-ában meg KELL hívnod egy bizonyos fv.-t (a beolvasó statikus tfv.-t), ugyanúgy ahogy az én megoldásomban is meg KELL hívni a B init tfv.-ét. A különbség annui, hogy nálad a D ctor-ának inicializáló listájában, míg nálam a törzsben kell ezt megtenni. Ja, és szükség lesz egy "köztes" blob struktúrára (amit a beolvasó visszaad), aminél már csak az a kérdés, hogy mikor, és hogy szűnik meg. -
jattila48
aktív tag
válasz
dobragab
#3059
üzenetére
Ha jól értem, akkor fájlból, innen-onnan binárisan beolvasó statikus függvény a D osztály statikus fv.-e. Minden egyes D osztályhoz csak 1 ilyen statikus fv. van (nem több forrástól függően), hiszen ha a forrás különböző, akkor az osztálynak is különbözőnek kell lenni. Vagyis igazából a forrás beolvasása a D osztály feladata, bár ha jól értem, szerinted nem. Azonban pl. a fájlból való beolvasáshoz tartozik egy file handle, amit az objektum megszűnésekor le kell zárni (RAII). Ez a file handle természetesen nem lehet a B osztály tagja, mert registryből olvasva már egy registry handle fog hozzá tartozni, stb. Vagyis egész természetes módon adódik, hogy a beolvasó fv.-nek nem statikusnak, hanem rendes tfv.-nek kell lenni. Ha egyetlen D osztály lenne, aminek forrásonként külön beolvasó statikus fv.-ei lennének, akkor a D osztály valójában felesleges, hiszen free fv.-ekkel ugyanez megoldható, a bináris adat pedig közvetlenül átadható lenne B konstruktorának.
Ha valóban a D statikus tfv.-eiről írtál, akkor a
"A statikus függvények meg lehetnek protected-ek, hogy a RAII-t ne lehessen kívülről zavarni, és hívhasd B / D ctorából." mondatodat nem értem. Ez a mondatod arra utal, hogy a B statikus tfv.-eiben valósítanád meg a beolvasást, ami azért nem lenne jó, mert előre nem tudhatja a B írója, hogy milyen forrásokból lesz a beolvasás.
"B innentől önállóan is működőképes osztály": Mármint úgy, hogy a konstruktorának meg tudunk adni bináris adatot is (pointer+méret: röviden blob)? Erre egyáltalán nincs szükség, hiszen ha ilyen osztály kellene, írnék egy leszármaztatott D-t ami pont ezt tudja. -
jattila48
aktív tag
válasz
dobragab
#3057
üzenetére
Akkor egy kicsit konkrétabban: B egy olyan osztály, ami bináris adatot tartalmazó memória területet dolgoz fel. A memória terület pointerét, és méretét kapja meg az init tfv.-ből. Van nem default ctor-a, amiben egyéb paramétereket vár. A leszármazott D osztály valahonnan (pl. file, registry, stb.) beolvassa a bináris adatot, lefoglalja a megfelelő memória területet, és ennek a címét és méretét a B::init-nek argumentumként átadva B::init meghívásával (a D ctor-ában) teljesen inicializálja B-t. A D ctorának fájl név a paramétere, ha fájlból olvas, vagy registry kulcs, ha registryből, stb. A probléma az, hogy ha nem az init-et hívom, hanem a B ctorának akarnám átadni a memória területet, akkor az adatot előbb kellene beolvasni, mint ahogy a B ctora meghívódik. Azonban az adat beolvasást mindenképpen a D ctor-ában szeretném elvégezni, nem pedig kívül (pl. RAII miatt). Ha a B ctor-ának az egyéb paraméterek mellett a memória pointer és a méret is paramétere lenne, akkor ezeket valahogy az inicializáló listában kéne előállítani (akár D statikus fv.-ei segítségével). Ehelyett én azt mondom, hogy mivel B-t nem lehet példányosítani, a D pedig nem tekinthető teljesen megkonstruáltnak ha nem hívja meg ctor-ából az init-et, talán elfogadható a B kétfázisú inicializálása. Ez koncepcionálisan nem mond ellent annak, hogy ne hozzunk létre félig konstruált objektumot, mivel ha D a konstruktorában nem hívja meg az init-et, akkor maga a D tekinthető félig konstruáltnak.
-
-
jattila48
aktív tag
válasz
dobragab
#2952
üzenetére
Hát, ez lényegében ugyanúgy egy lineáris keresés, de nekem mindegy! Megkeresed a vége előtt az első nem beolvasható elemet, és közben csinálsz valamit. A lényeg nálam is ez volt: Adott hosszúságú adathalmaz (tömb) elemein sorban haladva egy bizonyos feltétel bekövetkeztéig csinálok valamit. Ha a feltétel bekövetkezik, abbahagyom a feldolgozást (break). Ez a for-break legkézenfekvőbb alkalmazása. Végül is mi volt a baj a lineáris kereséssel?
-
dobragab
addikt
válasz
dobragab
#2951
üzenetére
Jutott eszembe. Fájlból beolvasás, és error handling. Kicsit bugyuta, de a célnak megteszi.
int i;
for (i = 0; i < n; ++i)
{
if(!(file >> tomb[n]))
break;
// handle data, probably more errors
}
if (i != n)
{
std::cerr << "Error while reading the file!" << std::endl;
throw whatever{};
}Itt a break is a funkcionális dekompozíciót segíti. Elválasztja egymástól a normális futást és a hibakezelést.
-
jattila48
aktív tag
válasz
dobragab
#2948
üzenetére
Félreértetted (vagy félre akartad érteni). Egyáltalán nem utasítom el funkcionális dekompozíciót, természetesen én is használok fv.-eket. Én a kérdésre válaszoltam, és nem jutott jobb példa eszembe, mint a lineáris keresés (és őszintén szólva most sem. Mondj egy példát, ahol a for ciklus break kombo helyénvaló, és az nem a lineáris keresés!). Magam részéről így csinálnám meg, de lehetőleg break nélkül a ciklusfeltételbe építve. Van azonban olyan eset, amikor nem lehet a ciklusfeltételbe beépíteni, ekkor használható a break (fv. hívás helyett is). Egyébként mint kiderült, a kérdező is a lineáris keresésre gondolt. Egy kezdőnek meg azzal sem kell tömni az agyát, hogy mindenáron túl általános sablonos c++ megoldást válasszon, és a hatékonyságot is illik szem előtt tartani. Erről írt Linus is.
-
EQMontoya
veterán
válasz
dobragab
#2945
üzenetére
A funkcionális dekompozició azért is támogatott, mert ha nincs megszokva, akkor ésszerű esetekben sem fogja csinálni az ember.
Múltkor az egyik versenyre írtunk olyan útvonaltervezést (alapvetően dijkstra alapon), amely:
-std::func-ként vette át a súlyfüggvényt, amit használnia kell
-std::func-ként kaphatott predikátumot, ha nem bizonyos pontra, hanem a legközelebbi, adott feltételt teljesítő pontra akarsz tervezniHa ezt nem szedi szét az ember már az elején, akkor a végén orbitális cumi lesz belőle.
-
jattila48
aktív tag
válasz
dobragab
#2945
üzenetére
A kérdező azt kérdezte, hogy for ciklusban OK-e a break.A válasz: igen. Lehet, hogy neked maga a for ciklus (főleg break-kel) már pattintott C korszak, de azért kíváncsi lennék, hogy írnál meg egy find and replace-t szövegbufferben amúgy elegánsan, modern C++ stílusban. Milyen konténerben tárolnád a szöveget, milyen standard fv.-eket használnál, és hogy kerülnéd el a for ciklusokat (break-kel együtt)? Egyébként biztos ismered Linus Torvalds véleményét a C++ nyelvről. Magam részéről ezzel persze jórészt nem értek egyet, de az általa "substandard programmers"-nek nevezett tagokról hasonló a véleményem. Ja, akkor a linux szerinted pattintott C korszaki, ugye?
-
-
jattila48
aktív tag
válasz
dobragab
#2941
üzenetére
Egy kicsit vegyél vissza az arcodból! "Szerintem itt a return a ciklus közepéből semmivel sem jobb mint a break (egyik sem struktúrált megoldás)" idézted tőlem. Az itt szócska talán elkerülte a figyelmedet. Én azt írtam, hogy van ahol jó a break (persze nem mindenhol), te meg azt mondod, hogy mindig van jobb megoldás. A példában jobbnak tartom, mint ezt a függvényhívás megoldást. Jelen esetben a fv. hívás maga túlságosan költséges az elvégzett feladathoz képest. Nem kell ide keverni olyan nyilvánvaló eseteket, ahol nincs létjogosultsága a break-nek, mert nem erről volt szó. Kezdünk elkanyarodni az eredeti kérdéstől. Fölösleges lenne most itt RAII-vel meg mélyebb C++ és OOP koncepciókkal dobálódzni. Nem ez volt a kérdés!
-
jattila48
aktív tag
válasz
dobragab
#2936
üzenetére
Szerintem itt a return a ciklus közepéből semmivel sem jobb mint a break (egyik sem struktúrált megoldás), ráadásul beépítesz egy fölösleges függvény hívást. És, ha nem kell végigmenni, hanem csak az első két előfordulást kell megtalálni? Akárhogy csűrjük, csavarjuk, szerintem van ahol kifejezetten jó megoldás a break for ciklusból. Aztán persze van ahol, van jobb megoldás.
)![;]](http://cdn.rios.hu/dl/s/v1.gif)
Nekem sok újat mondtál és gyors összefoglalónak kiváló - legalábbis így kezdőként könnyen fel tudtam fogni. A biztonság kedvéért a mester könyvében lévő konstruálással foglalkozó fejezetet tervezem átnyálazni, bár sok információt a cppreference.com-on is leírnak.
Azt nem hangsúyoztam ki a kérdésemben, hogy kulcs-érték párokat szeretnék tárolni a könnyű visszakereshetőség miatt, szóval vector helyettt inkább map-et használok majd. Szükség lesz egy STL tárolót burkoló osztályra, mert szeretném megoldani hogy az összes konténerben egy kulcs csak egyetlen egyszer szerepelhessen, biztonsági okokból.
Új hozzászólás Aktív témák
Hirdetés
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- EA Sports WRC '23
- LED világítás a lakásban
- Kazy Computers - Fehérvár - Megbízható?
- Az áremelések és a GTA VI késése miatt nem költekeznek a játékosok?
- Debrecen és környéke adok-veszek-beszélgetek
- Autós topik
- Azonnali alaplapos kérdések órája
- Borotva, szakállnyíró, szakállvágó topic
- Elstartolt az AMD munkaállomásokhoz szánt platformja
- gban: Ingyen kellene, de tegnapra
- További aktív témák...
- Samsung Galaxy Xcover 5 64GB, Kártyafüggetlen, 1 Év Garanciával
- Bomba ár! MacBook AIR 13" 2018 - i5-8210Y I 16GB I 512SSD I OS X Sonoma I Cam I Gari!
- ÁRGARANCIA! Épített KomPhone Ryzen 7 9800X3D 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Bomba ár! Lenovo ThinkPad P50 - i7-HQ I 16GB I 256SSD I Nvidia I 15,6" FHD I Cam I W10 I Gari!
- Telefon felvásárlás!! iPhone 16/iPhone 16 Plus/iPhone 16 Pro/iPhone 16 Pro Max
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest