- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- Két Zen 5-ös dizájnjának mintáit is szállítja már az AMD
- A Colorful "fagyosan kompakt" alkatrészekkel megy elébe a nyárnak
- A Keychron ismét egy űr betöltését vállalta magára az egerek szegmensében
- Az átlagnál vaskosabb ventilátorok kandikáltak ki a Corsair vitorlája mögül
Hirdetés
-
Snapdragon 8-as szériával várhatók a Honor 200-ak?
ma A Honor 200 állítólag a 8s Gen 3-at, a 200 Pro változat pedig a 8 Gen 3-at használja majd.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Az iPadOS-re írt appokra is díjat vet ki az Apple
it A DMA értelmében az iPadOS-t is kapuőrnek mondta ki az Európai Bizottság, így erre is technológiai alapdíjat vet ki az Apple.
Új hozzászólás Aktív témák
-
jattila48
aktív tag
válasz dobragab #2922 üzenetére
Ennyi. Ehhez képest nem bonyolította túl. Szerintem a fordító ugyanazt a kódot generálja. Code review-ban én nem tenném szóvá. Ha neki így érthetőbb, akár kommentként is felfogható.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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!
[ Szerkesztve ]
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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?
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.
Same rules apply!
-
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.
[ Szerkesztve ]
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.
[ Szerkesztve ]
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
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?
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
jattila48
aktív tag
válasz dobragab #3014 üzenetére
És ezt szerinted " igazán C++-osan" map-pel "illik" megoldani? Szerintem nem, de hát ízlések és pofonok... Az "Újszövetségben": minimize!=avoid, often!=always, in general!= in all circumstances.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.[ Szerkesztve ]
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
jattila48
aktív tag
válasz dobragab #3070 üzenetére
A konkrét példakód túl hosszú lenne. Egyébként nem is init-nek, hanem init_blob-nak hívom (csak így egyszerűbb volt leírni). Valóban a deszerializációt végzi, de a B szempontjából ez mégis csak kettős inicializálás. Viszont pont ezért nem példányosítható.
[ Szerkesztve ]
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
EQMontoya
veterán
válasz dobragab #3105 üzenetére
Sosejöttemvónará, Captain Obvious!
(bocs, kezdem magam őszintére fogyasztani )Egyébként alaptípusra is érdekes lesz a dolog, ha elkezded használni, mert random memóriaszemétre lesz inicializálva a dolog. De az önmagában igaz, hogy konstruktor nem kell.
[ Szerkesztve ]
Same rules apply!
-
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)[ Szerkesztve ]
Same rules apply!
-
jattila48
aktív tag
válasz dobragab #3121 üzenetére
Most tényleg nehéz felfogni, hogy nem ez a lényeg? C-ben írtam, mert az algoritmust akartam bemutatni, és nekem jobban "kézre áll". Ezek is valóban igen "értékes" megjegyzések voltak. Esetleg az algoritmusról is van véleményed?
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
pvt.peter
őstag
-
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.
[ Szerkesztve ]
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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!
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
ToMmY_hun
senior tag
válasz dobragab #3230 üzenetére
Rendben, köszönöm szépen! Készen is van és működik frankón Közben ismét új kérdés merült fel. Szeretnék logolni fájlba, Java-ban a log4j-t használom erre nagy általánosságban. Azt tudom, hogy C++ támogatás is van benne, de esetleg ismertek jobb megoldást?
C programmers never die, they are just cast into void.
-
ToMmY_hun
senior tag
válasz dobragab #3236 üzenetére
Valóban, köszönöm a tippet, így viszont érvényét veszíti amit az előbb írtam. Nem tudom hogy siklottam át felette, mert eléggé ideális megoldásnak tűnik a set használata. Lecserélem majd, de most vár még egy kellemes este socketezéssel meg multithreadinggel.
C programmers never die, they are just cast into void.
-
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.
DRM is theft
-
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).
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!