- Telekom mobilszolgáltatások
- Samsung Galaxy A54 - türelemjáték
- Motorola Moto Tag - nyomom, követ
- Xiaomi Watch S1 - szép az idő
- Egyszerre legnagyobb és legkisebb is a Garmin Venu X1
- Vivo X200 Pro - a kétszázát!
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Macrodroid
- One mobilszolgáltatások
- Yettel topik
Új hozzászólás Aktív témák
-
dabadab
titán
válasz
dobragab
#4196
üzenetére
struct Point
{
int x;
int y;
Point()
{
x = 0;
y = 0;
}
Point(int x, int y)
{
this->x = x;
this->y = y;
}
};Sőt:
struct Point
{
int x;
int y;
Point()
{
x = 0;
y = 0;
}
Point(int x, int y):
x(x),
y(y)
{}
};Nyilván ízlés kérdése, de egyrészt nem szeretem az explicit this-ezést, mert az vagy felesleges vagy valami problémás dolgot takar, másrészt meg szerintem ez nagyon szép és intuitív (és - nem mellesleg - teljesen jól működik).
Amúgy meg van olyan kezdőknek szóló könyv, amit úgy meg bírtak írni, hogy a példák vállalhatóak?...
"az OOP-nek (objektumorientalt programozas) jo lenne, ha nem csak a szintaktikai elemeit tanitanak meg, hanem az elveket, ami menten epiteni es alkalmazni illik. Anelkul semmi ertelme az egesznek."
Így van, mert aztán az ember produkciós kódban olyat lát, hogy
pX->m_pY->m_Z = foo;(és nem egy ilyen sort, hanem több tízezer sornyi kód van ebben a stílusban írva és persze az osztályok összes tagja public (a Lock() / Unlock() is (amik mondjuk eleve azért vannak, mert a RAII sem ért el hozzájuk))
-
-
jattila48
aktív tag
válasz
dobragab
#4087
üzenetére
Köszi szépen a válaszodat. Először is engedd meg, hogy egy hibát javítsak:
static RET fptr_handler(ARGS... args)
{
tl_function(std::forward<ARGS>(args)...);
}helyesen:
static RET fptr_handler(ARGS... args)
{
return tl_function(std::forward<ARGS>(args)...);
}Egyébként szép megoldás a problémára.
Lényegében hasonló, mint amit a szimulációban írtam. Ott globálisan hoztam létre az objektumokat, ezek tfv.-eit pedig free wrapper fv.-eken keresztül hívtam meg (amik a globális objektumokhoz hozzáférnek), és a free fv.-ekre mutató fv. pointert tudom aztán használni callback fv. pointerként.
Lényegében a te megoldásod is hasonló, csak nem globális, hanem (thread_local) static std::function objecteket hozol létre (tl_function), amik tartalmazzák az objektum címét (ez a lambdában kapturált argumentum), és a megfelelő tfv. pointert. Majd ezt a tl_function std::function objectet meghívó fptr_handler statikus wrapper tfv.-nek a címét (mint közönséges pattintott C fv. pointert) adod vissza. A trükk pedig az, hogy a to_fptr function template második argumentuma egy []{} dummy lambda, aminek a típusa mindíg (fordító által generált) egyedi típus, ezért a to_fptr_t class template minden egyes alkalomkor külön-külön példányosul (a dummy lambda aktuális típusával), minden egyes function object-re külön osztályt, és azzal külön fptr_handler fv.-t létrehozva. Szép megoldás, gratula! -
#4011
m.zmrzlina
senior tag
dobragab
#4010
-
#3989
PandaMonium
őstag
dobragab
#3986
PandaMonium
őstag
-
#3987
m.zmrzlina
senior tag
dobragab
#3986
m.zmrzlina
senior tag
válasz
dobragab
#3986
üzenetére
Igen, pont erről van szó. Van egy switch-case-zel működő menürendszer ami gyárt egy 80x25-ös keretet illetve elhelyezi benne a kiírnivalókat.
Aztán a user válaszától függően vagy csak megjelenít pár sort vagy elindítja a játékot ami értelemszerűen nem pár sor. Ezt a blokkot próbáltam volna egyben kezelni de úgy látszik ennek nem ez a módja.
-
#3956
PandaMonium
őstag
dobragab
#3955
PandaMonium
őstag
válasz
dobragab
#3955
üzenetére
Az STL is objektum-orientált, hogy fogja megérteni pl. hogy működnek a file handlerek, vagy smart pointerek, ha nem tudja mi az a konstruktor és destruktor? Vagy, hogy mikor és miért akkor szabadul fel pl. a vector által allokált memóriaterület? Ez nem Java, hogy majd a GC kipucolja, érteni kell a memória allokálás és felszabadítás folyamatát, különben sokszor lábon fogod lőni magad.
Persze, tanuljon algoritmusokat meg konténereket, adatszerkezeteket, de a nyelv szemantikája és a benne használt paradigmák ugyanilyen fontosak. Ezeket sem kell rögtön PhD szinten tudni, csak annyira, hogy értsd amit csinálsz.
-
b.kov
senior tag
válasz
dobragab
#3896
üzenetére
Mentségemre szóljon, hogy igyekeztem valamiféle párhuzamot vonni az előző kódokkal, így van benne getline, és stringstream.
De természetesen igazad van, felesleges stringekbe olvasgatni.Másrészt, az olvashatóság szerintem teljesen szubjektív dolog, és megszokás kérdése.
Mobilról viszont elhiszem, hogy gyötrelem olvasni megfelelő indentálás nélkül, kódtól függetlenül.
-
cadtamas
tag
válasz
dobragab
#3876
üzenetére
Hazudnék, ha azt mondanám, hogy minden világos, de remélem ahogy haladok a tananyaggal majd megvilágosodok. Eddig nem volt bajom a könyvvel, de azt észrevettem, hogy nem bajlódik az alapokkal és bizonyos tudásszintet természetesnek vesz.
Kezdőknek semmiképp sem ajánlanám.
Egy éve tanulom a pythont, csak az unreal engine miatt kénytelen vagyok megtanulni a c++ alapjait is. Nem volt rossz ötlet azzal kezdeni, egyes dolgokat jóval nagyvonalúbban kezel. -
-
EQMontoya
veterán
válasz
dobragab
#3821
üzenetére
Hát, ha ez egy value szerinti capture (
[=]), akkor az eredeti X-et nem módosíthatja, hanem csinál egy copyt.
Ez kvázi egy private member lesz abban a function objectben, amit a lambdából csinál a fordító. Mutable meg gondolom, azért lett, mert különben nem fordult, mert a saját privát X copyját nem illene módosítania.
Szóval szerintem 0-t ír ki, és mutalbe nélkül nem fordul. -
EQMontoya
veterán
válasz
dobragab
#3775
üzenetére
az viszont bool-ra (nem tudom pontosan, miért).
4.12 Boolean conversions
1 An rvalue of arithmetic, enumeration, pointer, or pointer to member type can be converted to an rvalue of type bool.
Szóval azért, mert nincs más konverzió, amit csinálhatna vele. Pointer -> int nincs impliciten. Igen, szerintem is béna.
-
dobragab
addikt
válasz
dobragab
#3688
üzenetére
C++-ról megint tanultam újat. Rosszul tudtam eddig, megtaláltam a szabványban, hogy a
throw()és anoexceptkompatibilis.Mindezt annak nyomán találtam meg, hogy a fordító által generált move ctor vajon
noexcept(auto)-e. Igen, az, sőt a throw deklarációkat is helyesen merge-eli. Bár ez a része tökmindegy -
KREE
csendes tag
válasz
dobragab
#3727
üzenetére
Hát, sajnos béna vagyok hozzá... :S
Nem tudná esetleg megoldani nekem valaki? Privben átküldném a forráskódot.
150 soros a progi, de 80%-a csak if-es feltétel meg kommentek, viszont grafikus módban íródott Turbo C++-ban. Sztem aki ért vmi Visual studio féle cucchoz annak 5 perc... Pár napon belül le kellene adni a szakdogámat... -
sko
csendes tag
válasz
dobragab
#3718
üzenetére
Szívesen!
Nem ismerem a feladat részleteit, de a jó megoldás valószínűleg pont, kör, szakasz, stb. osztályokból állhat össze. A kör/szakasz képes lesz legalább az előre ismert pontjait tartalmazni (középpont, végpontok), esetleg adott pillanatban még ismeretleneket kiszámolni. Egy objektum másiktól való távolsága pedig a pontokon keresztül kerül meghatározásra.
Ha a feladatleírásban olyan jól behatárolható objektumok vannak, mint pont/kör/szakasz, akkor a programban is hasznos lehet leképezni azokat. A program törzse ezeken az objektumokon dolgozik, a háttérmunkát pedig az objektumokhoz rendelt "képességek" végzik el.
Jó kódolást!
-
-
bandi0000
nagyúr
válasz
dobragab
#3672
üzenetére
köszi, de még mindig ugyan azt csinálja, vagyis szinte ugyan azt, így gondoltad nem?
cout << "Kerem az " << i + 1 << " karatkerlancot\t:";
cin.getline(valami[i], 9);
cout << "Kerem az " << i + 1 << " szamot\t:";
cin >> tmb[i];
cin >> ws;
cout << valami[i] << "\t" << tmb[i]<<endl; -
-
bandi0000
nagyúr
válasz
dobragab
#3658
üzenetére
jah... igen végül is nagy nehezen át lehet látni, csak azokat az ismeretlen vackokat nem tudom mit csinálnak a kódba
na meg ezt is most vettem észre: cin.fail(), ez ha jól tévedek valami bekérési hiba lenne ? pl ha nem olyat akarok tölteni a változóba mint amilyennek lefoglaltam? pl int a-ba beletöltenék egy karaktert?
-
bandi0000
nagyúr
válasz
dobragab
#3654
üzenetére
elég sok, mert több fajta feladatot csinált egyszerre, de konkrétan ebbe a feladatba volt ez:
/*
###########################################################################################################
# Feladat: #
# Maximum 10 érdemjegy bekérése ellenörzötten/véletlenszámmal feltöltve, #
# - az átlagok kiíratása #
# - a jelesek számának kiíratása #
###########################################################################################################
*/
int i2, db, ossz2=0, jegy[20], jelesdb=0;
do
{
cin.clear(); //a hibejelzők törlése, enélkül hiba esetén végtelen ciklusba fut
cin.sync(); //a beviteli puffer szinkronizálása, és a fel nem használt elemek ürítése, enélkül végtelen ciklus
cout<<"Hány jegyet ad meg?(max.10)"<<endl;
cin>>db;
if (cin.fail() || db<1 || db>10)
{
cout<<"Nem jó érték!\n";
}
}
while (cin.fail() || db<1 || db>10);
//jegyek bevitele billentyűzetről
for (i2=0; i2<db; i2++)//tömbindexálás mindig a 0. elemtől!
{
do
{
cin.clear(); //a hibejelzők törlése, enélkül hiba esetén végtelen ciklusba fut
cin.sync(); //a beviteli puffer szinkronizálása, és a fel nem használt elemek ürítése, enélkül végtelen ciklus
cout<<"Adja meg a(z) "<<i2+1<<". jegyet!"<<endl;
cin>>jegy[i2];
if(cin.fail() || jegy[i2]<1 || jegy[i2]>5)
{
cout<<"Nem jó érték!\n";
}
}
while (cin.fail() || jegy[i2]<1 || jegy[i2]>5);
}
//jegyek bevitele véletlen számokkal
for (i2=db; i2<db; i2++)
{
jegy[i2]=rand()%5+1;
}
cout<<"A beirt jegyek\t\tA generált jegyek"<<endl<<endl;
for (i2=0; i2<db; i2++) //végig kell néznie az öszes jegyet
{
if (jegy[i2]==5)
{
jelesdb++;
}
ossz2+=jegy[i2];
}
cout<<"\nÖssesen "<<jelesdb<<" db jeles van benne.\n";
cout<<"A jegyek átlaga= "<<setprecision(2)<<(double)ossz2/db<<endl; -
lorcsi
veterán
válasz
dobragab
#3624
üzenetére
ok, kezdetihez ezt-azt csináltatni vele jó lesz
tx
felpakoltam..és egy suliban írt progit nyitottam vona, de dobott egy iylen hibát:
"elso100 - Debug": The compiler's setup (GNU GCC Compiler) is invalid, so Code:
locks cannot find/run the compiler.
Probably the toolchain path within the compiler options is not setup correctly?! (Do you have a compiler installed?)
Goto "Settings->Compiler...->Global compiler settings->GNU GCC Compiler->Toolchain executables" and fix the compiler's setup.mi a fene ez?
minden alapon van..semmit sehova nem állítottam -
jattila48
aktív tag
válasz
dobragab
#3621
üzenetére
Nincs túl nagy különbség a két megoldás közt. Végül is nálad is van type switch, csak egy kicsit másképp. Scope alatt azt értem, ami pl. a Pascal-ban a scope. Egy adott sope-ban nem lehetnek azonos nevű szimbólumok, de egymásba ágyazott scope-okban vagy különállóakban már igen. A belső scope-ban lévő név elfedi a bentfoglaló scope-ban lévő ugyanilyen nevet. Ha kilépünk a scope-ból, akkor megszűnnek e nevei. Tehát a szokásos. Egységes szimbólum táblát (és vektort benne) a scope egyszerűbb kezelése miatt vezettem be. Nálad a különböző szimbólum táblák mindegyikében kezelni kell a scope-ot, ki kell jelölni a scope határokat. Nálam csak az egyetlen táblázatban. Nálad viszont valóban nincs típus attribútum, és static_cast. A set szerintem nem alkalmas, vagy csak akkor, ha scope-onként is külön táblázatokat tartasz fent, és ezeket stack-be szervezed. Azt hiszem maradok a static_cast-nál.
Köszönöm mindenkinek a hozzászólást! -
jattila48
aktív tag
válasz
dobragab
#3617
üzenetére
Kicsit visszatérve a type switch vs. virtuális fv. problémához:
Szerintem a zavart az okozza, hogy a szimbólumot reprezentáló osztály type mezője nem az osztály típusát jelöli, hanem a szimbólumét. Egy objektum típusa meghatározza, hogy rajta milyen műveletek végezhetők. Itt azonban a típusmező a név forráskódbeli szerepére utal, nem pedig a szimbólum osztályon végezhető műveletekre. Ez két külön dolog. A virtuális fv. az objektum típusához kapcsolódik, nem pedig a szimbólum név típusához. A szimbólum név típusa ugyanolyan attribútum, mint a többi, amik a program szerkezetére lesznek hatással (hogy generálja a kódot a fordító, a név típusától függően), ezért a type switch elkerülhetetlen. Mellesleg éppen ezért helytelen type switch-nek nevezni a dolgot. -
jattila48
aktív tag
válasz
dobragab
#3617
üzenetére
A set-ben (vagy nem vektorban) való tárolásról még annyit, hogy a scope kezelést nem lehet megoldani benne (hogy tartod nyilván a scope határokat?). A sope-ok stack szerűen rakódnak egymásra, ezt pedig vektorban a legegyszerűbb kezelni. Ha set-et használsz, akkor scope-onként külön-külön (sőt szerinted ezen belül még típusonként is) szimbólum táblákra lenne szükség (annál is inkább, mivel különböző scope-okban lehetnek azonos nevű szimbólumok,a set már csak ezért sem alkalmas), amiket aztán a scope-oknak megfelelően stack-be szervezel. Biztos, hogy ez jó elgondolás?
-
jattila48
aktív tag
válasz
dobragab
#3617
üzenetére
"Futásidejű költsége nem a static_cast-nak van, hanem a type switch-nek"
Én is ezt írtam. A type switch-et meg nem tudom elkerülni, mert mikor megtalálok egy szimbólumot, akkor a tíőusától függően kell folytatni a fordítást. Pl. egész mást kell csinálni ha a szimbólum változó, mint ha függvény. És azt előre nem tudom, hogy a keresett szimbólum milyen típusú lesz.
Nem értem mi előnye lenne a különböző típusok külön tárolásának, azonban azt látom, hogy rengeteg a hátránya.Minden, típusonként külön szimbólum táblában kezelni kell a scope-ot, holott a scope a típustól függetlenül ugyanúgy vonatkozik az összes szimbólumra. A find_symbol fv.-nek végig kell keresni az összes szimbólum táblát, és attól függően, hogy melyikben találta meg a szimbólumot, vissza kell hogy adja a típusát (ezután pedig mindenképpen type-switch jön). Sőt nem csak a típusát, hanem valami módon magát a szimbólumot is, pl. iterátorral. A visszaadott iterátor minden esetben más típusú lesz, ha csak az összes szimbólum nem egy közös őstől származik, és a táblázatok az ős pointert tárolják, amiket aztán ugyanúgy típustól függően static_cast-olni kell (mint ahogy most is csinálom). De akkor miért kéne külön táblázatokba tenni? Ha valamiért új típusú szimbólumot kell bevezetni, akkor a find_symbol fv.-t bővíteni kell az új típusnak megfelelő táblázat keresésével. Ezek mind hátrányok, és bonyolítják a programot. A Te megoldásod egyetlen "előnye", hogy a szimbólumokban nem kell a típusukat tárolni.
Az, hogy a táblázat vektor-e, vagy más, teljesen lényegtelen. Max. pár száz szimbólumról lehet szó, ennyire pedig talán a vektor overhead-je a legkisebb, úgyhogy a keresés sem lesz túl lassú (egyébként is csak fordításkor van szimbólum tábla, futáskor már nincs).
Egy szó mint száz, nem tudsz meggyőzni a külön-külön tároláskor, de nem is ez volt a kérdés. A static_cast nekem sem tetszik, de nem tudok jobbat. -
jattila48
aktív tag
válasz
dobragab
#3597
üzenetére
Hát akkor marad a típus vizsgálat, static_cast. Nem tudok jobbat. A típusvizsgálatot virtuális fv. használatakor sem lehet elkerülni, hiszen a konkrét típus ismeretében tudom csak eldönteni, hogy meghívjam-e egyáltalán a virtuális fv.-t (ami ráadásul a többi osztályban esetleg nincs is implementálva). Ez után a static_cast már csak a fordítót terheli, a futást nem, szemben a virtuális fv. hívással.
A különböző típusok külön táblázatban való tárolása nem opció, mert nagyon megnehezíti a szimbólum hozzáadást, -keresést, scope kezelést, ráadásul ezeket a fv.-eket át kell írni, ha új típusú szimbólumot vezetnék be. Ez egy olyan példa, hogy noha a tárolandó osztályoknak látszólag nem sok közük van egymáshoz, mégis más okból (scope-ban nem lehetnek azonos nevű szimbólumok) célszerű őket együtt tárolni. Szóval szerintem nem tervezési hiba. A külön táblázatok viszont az lenne. -
jattila48
aktív tag
válasz
dobragab
#3597
üzenetére
Ez most egy kicsit bonyolult, de pl. változó esetén a stack-en elfoglalt helyét, az érték típusát, és a statikus level-t tartalmazza. Függvény esetében a fv.-tábla-beli pozíciót, paraméterek számát, típusát, stb. Osztály definíció esetén ...elég bonyolult. A lényeg, hogy teljesen mások a szimbólumok, viszont a scope kezelés miatt egy vektorban (igazából stack-ben) kell őket tárolni.
-
jattila48
aktív tag
válasz
dobragab
#3595
üzenetére
Konkrétan ez egy interpreter szimbólum táblája. Lehet benne változó név, típus név, foglalt kulcsszó, függvény név, stb. A konkrét típustól függetlenül, az adott scope-ban nem lehetnek egyező nevű szimbólumok, akkor sem, ha különböző típusúak. Ezért kell őket egy vektorban tárolni, hogy ezt ellenőrizni lehessen. Még csak neve sincs minden szimbólumnak. A változó pl. teljesen másképp kezelendő, mint a típus definíció. Nem hiszem, hogy ez tervezési hiba lenne.
-
jattila48
aktív tag
válasz
dobragab
#3593
üzenetére
Erre gondoltam, de mit adjon vissza a virtuális fv.? A konkrét típusú this pointert (kovariáns típus)? Az nem jó. Más virtuális fv.-t meg nem lehet bevezetni, mert amúgy a típusok teljesen különbözőek. Az egyiken elvégezhető művelet értelmezhetetlen a másikon. Ebben az esetben mit csináljon a virtuális fv,? Exception-t dobjon? Vagy esetleg az ősbeli pure virtual-nak legyen törzse, ami exception-t dob, ha meghívódik? Másrészt az ősosztályban fel kéne venni virtuális fv.-ekként az egyes konkrét osztályokon értelmezhető műveletek unióját. Vagy rosszul értem, amit írtál?
-
-
EQMontoya
veterán
válasz
dobragab
#3518
üzenetére
Egy szempontot kihagytál, már ha nem csak vektorról van szó.
Mégpedig azt az esetet, amikor az emplace lehet sikertelen: pl. setbe beszúrás. Ott jelentős különbségek vannak.Egyébként a move ctor témája érdekes, de ezzel sok probléma van. Ugye a legfőbb ok a nem generálódásra a user-defined copy ctr, ami elég gyakori. És amikor egy régi kódot átvisznek c++11-re, ott a pék se fogja utólag megkeresni és megírogatni..
A push_back vs. emplace_back témakörre: szerintem alapvetően másra szánták, és itt a jogászokhoz hasonlóan úgy gondolkodom, hogy nem csak az a lényeg, hogy pontosan hogyan működik betűről betűre, hanem hogy mire szánták. Márpedig ez itt szerintem jól jelzi a különbséget: push_back, ha már létezőt akarsz belerakni, emplace pedig ha benne akarsz konstruálni.
Ezzel pedig nagy bakot sem lehet lőni.A unique_ptr-es példára reflektálva: persze, ott nem az emplace_back a hibás alapvetően, de a unique_ptr<T> (T *p) egy explicit ctor! Tehát az emplace_back itt csúnyán elfedi, hogy Te épp hatalmas hülyeséget készülsz csinálni. Olyat, ami amúgy le sem fordulna.
-
#3517
MasterMark
titán
dobragab
#3516
MasterMark
titán
válasz
dobragab
#3516
üzenetére
Köszi.
Így már majdnem jó, még a while előtt olvasok egyet a stringstream-ből.
A good az működik ha több adat jön még utána, de ha csak az első elem van (akkor ugye az kellene, hogy a while-ba bele se menjen) az már nem jó.Én is erre gondoltam, hogy a stringstream végét nem jól látja, épp ezért kérdeztem, hogy ugyanúgy van-e mint a file. De akkor nem teljesen.
-
ToMmY_hun
senior tag
válasz
dobragab
#3499
üzenetére
Bocs, hogy erre válaszolok előbb, a másik hozzászólást még rágcsálom - szóval Neked van infód arról, hogy külsősként van-e esély bekerülni? Regisztráltam, de nem tudom hogy hány hely lesz és hogy be lehet-e férni.
Számít, hogy milyen cégnevet ír be az ember?Szerk: Köszi a választ.
-
-
Jester01
veterán
-
jattila48
aktív tag
válasz
dobragab
#3453
üzenetére
Légy szíves írj már rá egy jó kódot, ha már az enyém annyira szar! De legyen aztán boost, regexp, STL, meg minden nyalánkság, ami egy igazán szép C++ kódba kell! Egyébként milyen "súlyos hibákat" fedeztél még fel benne? Az eddig tárgyaltak: strlen, enum helyett int, char[] tömb. Elmondtam, hogy miért. Még valami? Ezek nyilván olyannyira "súlyos hibák", hogy ettől aztán egy életre tönkre teszem vele a gondolkodásmódját, és ezután már csak ilyen szar kódot lesz képes írni.
"nem biztos, hogy észreveszi, hogy szar, több sebből vérzik, esetleg gyanútlanul be is másolja a kódot, vagy úgy gondolja, így kell kódot írni... Szemben azzal, hogy útmutatásként szar kódot kapott."
Nem liheged kicsit túl ezt a dolgot? Nem vagy egy kicsit nagyképű? (dehogy is nem!)
-
jattila48
aktív tag
válasz
dobragab
#3445
üzenetére
Nem egészen értünk egyet.
1. Attól, hogy valami hatékony, még lehet egyszerű és világos. Sőt! Ez az algoritmus is világos, de ha nem, akkor nagyon szívesen elmagyarázom. Hagyjuk meg a kérdezőnek, hogy eldöntse számára világos-e vagy sem. Egyelőre még nem szólt hozzá.
2. A kódom nem rossz (legalábbis remélem), hanem lehetett volna szebben is írni, ez igaz. Ettől a lényeg (maga az algoritmus) még jól látszik rajta. Hirtelen felindulásból 5 perc alatt ennyire futotta. Nem a kódolást akartam követendőként állítani, hanem hogy, lehet a saját józan eszünket is használni ahelyett, hogy rögön mindenféle túlfejlett apparátust (boost, regext,...) kezdenénk mozgatni apró problémákra. Erről már többször írtam, a véleményem továbbra is fenntartom. Ha megérti ezt az algoritmust, akkor talán tanult is valamit (remélem), és már megérte.
3. Azt, hogy illik-e manapság C kódot írni STL helyett,... hát a fene tudja. Én sokszor szoktam ilyen kisebb feladatoknál, ugyanakkor az STL-t is használom. Szerintem jól megférnek egymás mellett. Itt a példában az algoritmus szerintem jobban látszik STL tárolók használata nélkül. Nem vonja el fölöslegesen a figyelmet. Továbbá azt is érdemes megjegyezni, hogy az STL tárolók használatának ára van. Fölösleges ide-oda másolások (túl sok ilyen kódot láttam), ha nem pont alkalmas a tároló amire a használni akarja, akkor egész elborzasztó "patkolásra" is képesek,...
4. Egyébként ha nagyon akarja valaki, akkor könnyen ki lehet cserélni STL tárolókra a tömböket, és akkor mindenki boldog lesz.
Én remélem tudtam segíteni, ellenben tőletek semmilyen konkrét segítséget nem kapott.
-
jattila48
aktív tag
válasz
dobragab
#3442
üzenetére
Az eredmény tömböt úgy juttatom ki, hogy előbb bejuttatom. Vagy helyben történik a feldolgozás, és akkor az input egybe output is, vagy kívül foglalok az output tömbnek helyet, a rámutató char * pointert és a puffer méretét pedig paraméterként kapja a fv. De ezt szerintem neked nem kell magyarázni.
-
jattila48
aktív tag
válasz
dobragab
#3442
üzenetére
Ezt a restrict-et nem tudom mi, sose használtam, de azt hiszem eltértünk a lényegtől. Szerintem akár strlen, akár nem, attól az algoritmusom még hatékonynak mondható. Maradjunk annyiban, hogy a for így módosul:
for(int i=0;ipv6_addr[i]!=0;++i)
És most már próbáljatok nem kötekedni, hanem érdemben segíteni a kérdezőnek. Köszi!
-
jattila48
aktív tag
válasz
dobragab
#3433
üzenetére
Valóban a trim-nek enum-nak kéne lenni. Ha több állapot lenne, vagy esetleg bővülhetne, akkor biztos úgy csinálnám. Persze osztályt is lehetne csinálni belőle, meg string-gel dolgozni. Csak az algoritmust akartam bemutatni, hogy mennyire egyszerű, és nem kellet hozzá sem boost, sem regexp, sem vector<string>, amiknél feltehetőleg jóval hatékonyabb így (futásidőben, és memória használatban is (főleg ha helyben történik a feldolgozás)).
Csak mivel felvetődött a téma azért kérdeztem rá, hogy ha majd egyszer.... akkor merre. Bár a VS-t lehet, hogy kipróbálom.
De természetesen igazad van, felesleges stringekbe olvasgatni.
locks cannot find/run the compiler.
BTW tegnap meglett a Prog nyelvek C++, jöhet a számgraf meg az oprendszerek 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ú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!
- Telekom mobilszolgáltatások
- Samsung Galaxy A54 - türelemjáték
- Luck Dragon: Asszociációs játék. :)
- Gyúrósok ide!
- gerner1
- Motorola Moto Tag - nyomom, követ
- Xbox tulajok OFF topicja
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- gban: Ingyen kellene, de tegnapra
- Xiaomi Watch S1 - szép az idő
- További aktív témák...
- LG 40WP95XP-W - 40" NANO IPS - 5120x2160 5K - 72Hz 5ms - TB 4.0 - HDR - AMD FreeSync
- 123 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!)
- Apple iPhone 13 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Új, verhetetlen alaplap sok extrával!
- Samsung Galaxy A16 128GB Kártyafüggetlen, 1Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest