- A franciáknak elege van abból, hogy minden gyerek mobilozik
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Milyen routert?
- Az iPadOS-re írt appokra is díjat vet ki az Apple
- Windows 11
- Milyen NAS-t vegyek?
- VPN topic
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Crypto Trade
- Debian GNU/Linux
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- GoodSpeed: ASUS ROG STRIX B650E-F GAMING WIFI - Memory Context Restory (MCR)
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- sziku69: Fűzzük össze a szavakat :)
Új hozzászólás Aktív témák
-
EQMontoya
veterán
-
jattila48
aktív tag
válasz mgoogyi #3600 üzenetére
Leírtam, hogy miről van szó. Ha nem tudod mi az a szimbólum tábla, akkor azt most nem tudom teljes részletességgel elmagyarázni. Nem ismétléseket kell keresni benne, hanem hanem amikor a programszövegből új nevet olvas a szintaktikus elemző, meg kell állapítani, hogy előfordult-e már ilyen nevű szimbólum. Ezt vagy azért teszi, mert új nevet definiálunk (ekkor ellenőrizni kell, hogy a scope-ban szerepel-e már), vagy azért, mert hivatkozunk rá (ekkor ki kell keresni (nem csak a scope-ból), és a tárolt attribútumai szerint folytatni a fordítást). Leírtam, hogy miért kell az összes különböző típusú szimbólumnak egy táblázatban szerepelni. Mivel különböző típusúak, ezért nem lehet őket egységesen (polimorf módon sem) kezelni. Az, hogy a szimbólum tábla most vektor-e, map, vagy hash tábla, teljesen mindegy. Nekem bőven elég a vektor. A hangsúly a heterogén tároló használatán van.
„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 mgoogyi #3603 üzenetére
Ne haragudj, de szerintem nem érted miről van szó. Persze, hogy csak a pointerek vannak sorfolytonosan a vektorban (hiszen írtam, hogy csak ezeket tárolom vektorban). EQMontoya arra gondolt, hogy vektorban (a sorfolytonos elrendezés miatt), kis elemszám esetén gyorsabb az ismétlődés keresés, mint pl. set-ben. Ez akkor is így van ha, csak az objektumok pointereit tároljuk, mert az algoritmus ezen fog föl-alá futkosni, miközben a pointerek által hivatkozott objektumokat hasonlítja össze. Ha jól van megírva az ismétlődés kereső algoritmus, akkor mindössze egy összehasonlító operátort kell neki átadni, és pont ugyanúgy működik, mint egyéb esetben.
Na de ennek semmi köze az eredeti problémához, mert szimbólum táblában NEM keresünk ismétlődést.„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
mgoogyi
senior tag
válasz jattila48 #3602 üzenetére
Tudom mi a szimbólumtábla, viszont nem tudom, hogy mi történik pontosan a "tárolt attribútumai szerint folytatni a fordítást" során. Különböző külső függőségei vannak a különböző objektumoknak a további feldolgozás szempontjából? Még mindig az van a fejemben, hogy minden objektumra lehetne egy Process-t hívni, ami kezelné az adott objektumot a típusának megfelelően, ami kaphat egy olyan külső függőséget, amin keresztül mindent megkaphat, amire esetleg szüksége van, vagy esetleg vmi callback-et. Ha viszont teljesen heterogén és abszolút összegyezhetetlen dolgok vannak, akkor nincs ötletem.
-
EQMontoya
veterán
-
jattila48
aktív tag
válasz mgoogyi #3606 üzenetére
Nekem úgy tűnik, mégsem egészen tudod, mi a szimbólum tábla (bocs). Ha egyszer bekerült a szimbólum a táblázatba, akkor azt már nem kell "feldolgozni" (legfeljebb törölni), hanem szükség szerint megtalálni kell, és az attribútumai alapján generálni a megfelelő kódot. A tárolt szimbólumnak ha lenne virtuális fv.-e, akkor az csak getter lenne, de semmiképpen nem "processz". Tulajdonképpen a find const pointereket ad vissza, mivel egyáltalán nincs szükség a megtalált szimbólum megváltoztatására. Azonban a szimbólumok, ahogy írtam teljesen különbözők, így nincsenek hasonló attribútumaik sem (a nevet és típust kivéve). Ezért nem lehet (és nem is kell) őket egységes interfészen keresztül kezelni.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
mgoogyi
senior tag
válasz jattila48 #3610 üzenetére
Lehetséges, hogy nem tudom..
Nem az, amit leírtál? Egy tábla, ami tárolja a lefordítandó kód szimbólumait, mint változó, függvény, stb. és arra használod pl., hogy ellenőrizd, hogy az adott objektumra az adott scopeban lehet e egyáltalán hivatkozni.
A process kapcsán arra gondoltam, hogy valami gépi vagy köztes kódot generálsz, mikor mész a következő sorra a kódban és találkozol pl. egy szimbólumon végzett művelettel.
És elnézést, hogy beledumáltam (inkább ne tettem volna), nem vágom, hogy működnek a fordítóprogramok. -
jattila48
aktív tag
válasz mgoogyi #3611 üzenetére
De, erről van szó. Azonban a kód generálás, már nem a szimbólum tfv.-einek hívásával történik, hanem a szimbólum attribútumai alapján. A megtalált szimbólum állapotán már nem változtatunk. Ahogy írtad, pl. függvények, változók neveiből keletkeznek szimbólumok, teljesen különböző attribútumokkal. Ezért nem lehet egységes interfészen kezelni őket, viszont mégis egy táblázatban kell tárolni ezeket.
Nyugodtan dumálj bele, nem leugatni akartalak. Bocs, ha így érezted.„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
mgoogyi
senior tag
válasz EQMontoya #3613 üzenetére
Értem mire gondolsz, de ez csak a pointerekre vonatkozó cache miss.
Az objektumok kapcsán annyi cache miss lesz, ahányat feleslegesen megnézünk, azaz set esetén O(log(N)), vektor esetén meg O(N).Ha csak a pointert elég használni a komparálásra, akkor teljesen igazad van, de nem látom, hogy ez milyen esetben van.
A fordító csak a szimbolúm nevét látja, nem?A kis elemszámra hol van algoritmikus overheadje a set-nek pointeren keresztüli elemkeresésnél?
(Mondjuk ez tök mellékes, mert úgyis elhanyagolható.)[ Szerkesztve ]
-
dobragab
addikt
válasz jattila48 #3599 üzenetére
Futásidejű költsége nem a static_cast-nak van, hanem a type switch-nek. De ha az enum értékei 0-n-ig folytonosak, a fordító O(1) jump table-t tud belőle generálni. Pont pár hete néztem meg.
Szerintem az a legtisztább megoldás, ha külön tárolod. Egyedül a keresést kell az összes tárolóra kiterjeszteni, és a scope keresésben azt hívni. A scope kezelése nem tudom, hogy megy, főleg, hogy nem tudom, milyen nyelvről van szó A hozzáadás tuti nem macerásabb, hiszen hozzáadáskor tudod, milyen típust adsz hozzá, csak a megfelelő kollekcióba kell belerakni.
Aztán ja, nem hiszem, hogy ezeket
std::vector
-ban kéne tárolni, ha a tárolási sorrend nem életbe vágó, és csak egy lehet mindenből. Errestd::set
vagystd::unordered_set
jobb, szerintem az utóbbi.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 #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.„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 #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?
„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 #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.„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 jattila48 #3618 üzenetére
A keresést úgy értettem, hogy a
bool symbol_exists(Symbol)
van szétosztva, és nem a find_symbol. Szarul fogalmaztam.Szóval valami ilyen type switch van neked:
Symbol * s = find_symbol("int");
switch(s.type)
{
case KEYWORD:
Keyword * k = static_cast<Keyword*>(s);
// blablabla
break;
case TYPE:
Type * t = static_cast<Type*>(s);
// blablabla
break;
}Ennél mennyivel rosszabb ez?
std::string symbol = "int";
auto it_keyword = keywords.find(symbol);
if(it_keyword != keywords.end())
{
// use *it_keyword
return;
}
auto it_type = types.find(symbol);
if(it_type != types.end())
{
// use *it_type
return;
}A scope kezelést még mindig nem tudom, hogy kéne működnie.
[ 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 #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!„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
lorcsi
veterán
elkezdtem szept.-től programozást tanulni-...
c++ és C# is van-lesz (később meg majd java is)a C++ Code bocks-al írjuk..
mennyire használják még ezt a felületet?
vagy mennyire elavult?C#-ot pedig microsoft visual C# express 2010 verzióval..
szintén ez lenne a kérdésem...-nem vág túlzottan témába, de hátha... -
dobragab
addikt
Alap dolgokra teljesen jó a C:. Maga az IDE nem a legokosabb, de nem tartom valószínűnek, hogy ennek hátrányát látnád.
A VS egy kifejezetten jó IDE, pláne C#-ra. Bár a 2010 még kicsit butácska, a 2013 sokkal kényelmesebb.
[ Szerkesztve ]
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
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[ Szerkesztve ]
-
kispx
addikt
Be kell állítani a fordítót, amit a kiírt helyen megteheted.
Windows platformon van egy olyan szokása, hogy két fajta telepítő is van az oldalukon.
codeblocks-16.01-setup.exe
Ebben csak az IDE van.codeblocks-16.01mingw-setup.exe
Ebben az IDE és (mingw) fordító program is van. Ha az elsőt töltötted le, akkor fordítód nincs. Így érdemes a codeblocks-16.01mingw-setup.exe letölteni. (vagy külön egy mingw fordítót felrakni.)[ Szerkesztve ]
-
bandi0000
nagyúr
sziasztok
használja itt valaki a visual studiot? először telepítettem, de hiányzik belőle egy "modul" amikor létrehozom az új projektet, és nem tudom honnan szedjem le
Xbox One: bandymnc
-
bandi0000
nagyúr
válasz bandi0000 #3634 üzenetére
ezt végül is megoldottam, csak le kellett tölteni
viszont van egy kis prog feladatom, beadandót kéne csinálni, sima lottó sorsoltás, ugyebár nem ismétlődhet 0-90 ig ezzel nincs is gond, csak van e ennél egyszerűbb vagy szebb megoldás?
dupla for, mindkettő elmegy <6-ig, első for alatt random számot generálok, a 2. for is <6-ig megy, de ott meg megvizsgálom, hogy az eddig kisorsolt számok között van e olyan mint amit most sorsoltam, ha nincs akkor beletöltöm a tömbbe, ha van akkor meg az első for változóját, (i-t) minuszolom egyel, tehát hogy sorolja ki még1-szer azt
Xbox One: bandymnc
-
Karma
félisten
válasz bandi0000 #3635 üzenetére
Ennél csak jobb megoldás van. Egy dolog, hogy nehezen olvasható és követhető a ciklusváltozók belső manipulációja miatt, de még le is fagyhat az algoritmusod (még ha ez egy ötöslottónál nem is valószínű).
Szerintem itt nem baj, ha a valóságra támaszkodsz: vegyél egy vectort, benne a számokkal 1-90 között, használd az std::shuffle függvényt hogy megkeverd őket, és vedd ki az első öt számot.
“All nothings are not equal.”
-
sztanozs
veterán
válasz bandi0000 #3637 üzenetére
Igazából egy elég hosszú for ciklussal + random szám generátorral is össze tudod keverni az elemeket, ha nem akarsz olyat használni, amit még nem tanultatok.
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
bandi0000
nagyúr
ja értem már, akkor ez csak összekeveri az elemeket, és 0-4-ig kiíratom a tömb elemeit, amik elvileg nem 1,2,3,4,5 lesz, hanem kevert valami
(#3639) sztanozs : azzal próbáltam, vagyis megírom úgy hogy legyen egy tuti jó, aztán ráérek kísérletezni vele, mert így is úgy is meg kellene tanulnom ezeket, ha akarok is kezdeni vele valamit, mert ezt már régen megírtam, de most valami miatt nem akar menni, vagyis, nem is értem, mert már akkor meg hal a program, mikor a jó és nem ismétlődő számot, bele akarom tölteni a tömbbe...
do
{
szam = rand() % 90 + 1;
j = 0;
while (sors[j] != szam && j < 6)
{
j++;
}
if (j == 6) { sors[i] = szam; i++; }
else i--;
} while (i != 6);persze feltöltöttem a sors tömböt
[ Szerkesztve ]
Xbox One: bandymnc
-
bandi0000
nagyúr
válasz bandi0000 #3640 üzenetére
bocsesz, sztornó, sokat segített volna, ha ki 0-zom az i-t, miután kicseréltem do-while-ra a for-t
am most ugye nem code blocks-ba programozok hanem visual studioba, és nem C#-be hanem c++-ba, attól még ugyan úgy kellene működniük az általános dolgok mint a for nem?
Xbox One: bandymnc
-
EQMontoya
veterán
válasz bandi0000 #3643 üzenetére
Arra miért nem jó egy másik shuffle?
De ha nem akarsz shuffle-t használni:
std_vector<int> nums;
std_vector<int> results;
for(int i=1;i<=90; ++i)
{
nums.push_back(i);
}
for(int i=0;i<5;++i)
{
int rand_index = //generálsz egy randomot 0 és nums.size()-1 között.
result.push_back(nums[rand_index]); //berakod a generált számot a végeredmény containerbe
std::vector<int>::iterator it = ( nums.begin() + rand_index ); //szerzel egy iterátort az indexelt elemre
nums.erase(it); //ezt az elemet törlöd a containerből
}A fenti megoldásnak az az előnye, hogy amit egyszer kisorsoltál, azt ki is veszed, így legközelebb egyel kisebb méretű vektorban sorsolsz, ami így nem is fog tudni ütközni.
Same rules apply!
-
bandi0000
nagyúr
válasz EQMontoya #3644 üzenetére
biztos jók amit mondotok meg stb, de az a baj hogy nem tudom mit írtál most le természetesen nem várom hogy elmagyarázd, majd apránként megtanulom ezeket, de annak sincs értelme ha csak lemásolgatom amit írtok
tetszik ez a shuffle, sztem ezt majd használom
de a vektor alatt ti mit értetek? sima tömböt nem?
Xbox One: bandymnc
-
cattus
őstag
válasz EQMontoya #3644 üzenetére
Ez amúgy szép és jó, de egy kezdő programozó, aki nem látott még C++ kódot, nem nagyon fogja tudni ezt értelmezni.
Egy egyszerű megoldás lehet még, hogy egy 5 elemű tömbbe generál random számokat 1 és 90 között, és ha még nem szerepel benne, akkor berakja.
Do the thing!
-
dobragab
addikt
válasz bandi0000 #3647 üzenetére
Másik jó megoldás, hogy generálsz egy 90 elemű tömböt. Aztán ötször:
- generálsz egy n-t 0-89-ig,
-tomb[n]
-t kiválasztod
- majdtomb[n]
-t kiveszed tomb-ből. Ez legegyszerűbbentomb[n]
és az utolsó elem cseréjével oldható meg, és ezután már 0-88-ig generálsz n-tKódban még egyszerűbb is.
int megoldasok[5];
int tomb[90];
for(int i = 0; i < 90; ++i)
tomb[i] = i;
for(int i = 0; i < 5; ++i)
{
int n = rand() % (90-i); // jó, éles kódban ne rand-ot használj
megoldasok[i] = tomb[n];
std::swap(tomb[90-1-i], tomb[n]); // vagy sima segédváltozós csere
}Nem próbáltam ki, lehet benne elírás...
[ Szerkesztve ]
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
Ú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!
- Helldivers 2 (PC, PS5)
- Filmvilág
- Forza sorozat (Horizon/Motorsport)
- Android alkalmazások - szoftver kibeszélő topik
- Samsung Galaxy A54 - türelemjáték
- Samsung Galaxy S24 - nos, Exynos
- Politika
- A franciáknak elege van abból, hogy minden gyerek mobilozik
- TCL LCD és LED TV-k
- Az Apple megszerezné a klubvilágbajnokság közvetítési jogait
- További aktív témák...
- Commlite CM-EF-NEX Auto-Focus Adapter (Canon EF - Sony E)
- Üzletből, garanciával, legújabb Asus Vivobook 17" i7-1355U 10 mag 5GHz/16RAM/1TBSSD/17,3"FULLHD
- Üzletből, garanciával DeLL XPS 15 9500 i7-10750H 32GBRAM 1TBSSD/GTX1650Ti 15,6"4KTOUCH
- i5 12400f 3070 gamer pc
- DeLL Precision 7740 workstation, üzletből, I7-9850H/32RAM/512GBSSD/NVIDIA QuadroRTX3000/17,3"FULLHD
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest