- Zenelejátszó építése, a kiváló hangzásért
- Egyszerűsíti termékportfólióját a HP
- Milyen belső merevlemezt vegyek?
- Vezetékes FEJhallgatók
- Kormányok / autós szimulátorok topicja
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- TCL LCD és LED TV-k
- E-book olvasók
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Vezetékes FÜLhallgatók
Hirdetés
-
Bemutatkoztak a Microsoft aktuális Surface gépei
ph A Surface Laptop és Pro hamarosan megjelenő iterációi a 45 TOPS-os NPU-val érkező Snapdragon X platformra épülnek.
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
-
Folyamatosan hazudott a bitcoin állítólagos feltalálója
it Egy brit bíró szerint Craig Wright, a bitcoin állítólagos feltalálója folyamatosan hazudott és bizonyítékot hamisított.
Új hozzászólás Aktív témák
-
jattila48
aktív tag
válasz don_peter #5162 üzenetére
Hirtelen ez jutott eszembe, de biztos van gyorsabb módszer is:
unsigned char reverse_bits(unsigned char x)
{
unsigned char y=0;
y=y | ((x & 0x80) >> 7);
y=y | ((x & 0x40) >> 5);
y=y | ((x & 0x20) >> 3);
y=y | ((x & 0x10) >> 1);
y=y | ((x & 0x8) << 1);
y=y | ((x & 0x4) << 3);
y=y | ((x & 0x2) << 5);
y=y | ((x & 0x1) << 7);return y;
}„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 don_peter #5170 üzenetére
Ez talán egyszerűbb és gyorsabb, ha a ciklust kigörgeted:
unsigned char reverse_bits(unsigned char x){
unsigned char y=0;
for(int i=0;i<8;++i){
y=y >> 1;
y=y | (x & 0x80);
x=x << 1;
}return y;
}„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 maestro87 #5473 üzenetére
A float példádból az látszik, hogy a pontos bináris ábrázolásból az alsó legalább 7, de legfeljebb 12 bitet elhagyja, majd kerekít. Ha csak 6 bitet hagyna el, akkor a kiírásban pontos értéket, míg ha 13 bitet, akkor kisebb értéket (6119424) kaptál volna. Pl. lehet, hogy az alsó 8 bitet hagyja el (valószínűleg így van). Szerintem a float-od 24 bites, amiből a mantissza 16 bit (előjellel együtt, vagyis 15 értékes bit), a karakterisztika pedig 8 bit. Ha 32 bites float-ra is ugyanez a kiírás adódik, akkor a mantissza szintén 16 bit, viszont a karakterisztika is 16 bit (bár ennek nem sok értelme lenne). A float érték úgy ábrázolódik, hogy a mantissza 15 értékes bitjét 0,xxxxxxxxxxxxxxx értéknek tekinted (0, kettedes vessző után jönnek a mantissza bitjei), amit megszorzol 2^karakterisztika-val. 8 bites karakterisztikával kb. 2^127 nagyságrendű számokat tudsz ábrázolni, vagyis bőven elég nagyokat. Viszont 16 bites mantisszával legfeljebb 1/2^16 relatív pontosság érhető el. Az, hogy hány tizedes jegyre (vagy "kettedes" jegyre) pontos az ábrázolás (ez az abszolút hiba), függ a szám nagyságától, ezért csak relatív pontosságról van értelme beszélni (abszolút hiba/pontos érték). A példádban a relatív hiba 64/6123456, ami megfelel a 15-16 bites mantisszának. Ami a szorzást illeti: egész biztos, hogy mindkét operandusod float-ra fog konvertálódni, vagyis 8 bites karakterisztikával bőven ábrázolható lesz, viszont a relatív hiba ugyanúgy megmarad 1/2^16 felső korláttal. Mivel az operandusok már hibával terheltek, ezért a szorzat is az lesz (szorzásnál a relatív hibák összeadódnak). Tehát nem a kiírásnak vannak korlátai (legfeljebb normál alakban írja ki), hanem a szám ábrázolásnak, amit tudomásul kell venni, és így kell velük dolgozni. Természetesen ezekkel a korlátokkal is megvalósíthatsz tetszőleges pontosságú egész vagy float aritmetikát, azonban ez igen macerá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 Jester01 #5573 üzenetére
"A tömb pedig ekvivalens a pointerrel"
Na na! Csak óvatosan! Pointernek adhatsz értéket, tömbnek nem. Ez egy igen lényeges különbség. A tömb, mint cím, fordítás idejű konstans, míg a pointer egy változó, ami futás időben kap értéket. Pointernek veheted a címét (hiszen változó), tömbnek pedig nem (mármint char array[10]; char **p=&array; utasításoknak nincs értelme, míg char *p; char **pp=&p; -nek pedig van). Az, hogy a C-ben és C++ -ban szemantikailag nincs eléggé megkülönböztetve a pointer és a tömb, az a nyelv egyik hiányossága, amellett, hogy nagyfokú rugalmasságot is biztosít.
C++ -ban például teljesen helyénvaló származtatott osztály pointert (D *) publikus ősosztály pointerként (B *) használni, míg D ** pointer B ** pointerként való használata tiltott, nyilvánvaló okok miatt. Ugyanakkor nyugodtan meg lehetne engedni D *[] típusú változó B *[]-ként való használatát, azonban ezt mégsem lehet, mivel nincs eléggé megkülönböztetve a pointer és a tömb.„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
Úgy látom nagy a baj! Nem csak a memória kezeléssel, hanem úgy általában. Az fstab egy 1 byte (karakter mérete) hosszú memória terület kezdőcíme.
fstab[i-1]=='\n'
Ez mi? Inicializálatlanul használod az fstab memória területet, ráadásul rögtön -1 indexszel, ami egyébként is a lefoglalt memória területen kívül esik. Mivel nem írsz rá, hanem csak olvasod, jó eséllyel nem akad ki a program azonnal, de akár az is előfordulhat.
Szerintem előbb gondold át mit is akarsz csinálni, mert nem csak a C nyelvvel állsz hadilábon. Ha lesz időm, válaszolok bővebben is.„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
Tudnátok a tömbre mutató pointernek valami értelmes alkalmazását mondani?
int ia[2];
int (*pia)[2];
pia=&ia;
pia az ia tömbre mutató pointer, értéke az ia tömb címe. Nade mire jó?[ 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 Domonkos #6022 üzenetére
Vagyis? Bővebben? Az argv char *[] típusú, azaz char * típusú címeket tartalmazó tömb. Nem ugyanaz, mint a (char *)[], char tömbre mutató pointer típus, amit én kérdezek
[ 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 Domonkos #6024 üzenetére
Ha megnézed, a getopt paramétere char *[] típusú, nem pedig (char *)[] típusú. A két típus különböző. Én az utóbbit kérdezem. Az első címeket tartalmazó tömb, vagyis az elemei pointerek. A második pedig tömbre mutató pointer, aminek értéke a tömb címe. Régóta programozok C-ben, tudom mire való az argv, getopt és társai. De ez má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 kovisoft #6028 üzenetére
Nem felel meg, mert az arr nálad csak egy tömb, nem pedig tömbre mutató pointer. Az én példámban
sizeof(pia)==4
(vagy 8), azaz pointer méret. Náladsizeof(arr)
az arr tömb mérete. A tömb nem ugyanaz, mint a tömbre mutató pointer.„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 kovisoft #6032 üzenetére
Ha több ugyanolyan típusú tömböt egységesen akarok kezelni, akkor:
int ia1[5],ia2[5];
int *pia;
pia=ia1;
//valamit csinálok a pia pointeren keresztül
pia=ia2;
//stb...Ha a méretükre van szükségem, akkor
ARRAYSIZE(ia1)
,
de még egyszerűbb, ha#define ASIZE 5
int ia1[ASIZE],ia2[ASIZE];
...[ 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 kovisoft #6034 üzenetére
A baj csak az, hogy a tömbre mutató pointerhez hozzá van kötve a tömb mérete. Tehát, ha a tömbre mutató ponter egy fv. argumentuma, akkor annak semmilyen más méretű tömböt nem lehet átadni. Így aztán a tömb méretét lekérdezni nem sok értelme van, hiszen ez a fv. csak ilyen méretű tömböt képes fogadni.
Nem vitatkozni akarok, csupán érdekel, hogy miért létezik ez a konstrukció a C nyelvben. Akkor lenne értelme, ha nem lehetne elkerülni a használatát, vagy az elkerülése bonyolultabb lenne. Ehelyett mindig el lehet kerülni, és egyszerűbben, mint használni. Pointereket leggyakrabban azért haználunk, hogy az általuk mutatott memória címen megváltoztassuk a memória tartalmát (vagy mert a stack-en nem lehet nagyméretű objektumokat átadni). Ehhez képest a tömbre mutató pointeren keresztül nem változtatjuk meg a tömböt (ami itt a tömb címét jelenti), hiszen az nem is balérték. Úgy tűnik, hogy igazából semmi értelme nincs, mindössze a C típusdefiníciós szintaxisának egy csökevénye.„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 jattila48 #6035 üzenetére
Közben rájöttem, mikor van értelme a tömbre mutató pointer használatának.
int iia[10][5];
int (*piia)[5];
piia=iia;
Az iia kétdimenziós tömb neve önmagában leírva nem int ** típusú, hanem int (*)[5] típusú. Ezért ha ezt a kétdimenziós tömböt akarjuk átadni az f fv.-nek, akkorvoid f(int (*x)[5]);
prototípusúnak kell lennie.„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 kovisoft #6042 üzenetére
Bármelyik kivágott lyuk a forgatások miatt 4 pozíciót határoz meg, amelyek közül csak ezt az egyet lehet kivágni. Hogy egy, forgatások által meghatározott négyes melyik elemét választod ki, az 4-féleképpen lehetséges. Összesen 9 db. négyes van, amelyek mindegyikéből csak egy-egy elemet lehet kiválasztani, ezt pedig összesen 4^9 féleképpen lehet megtenni. Szerintem az én megoldásom a jó!
Egyébként ilyen módon a Cardano rácsot a (rejtjelezés kulcsát) egy 9 hosszú sorozattal lehet reprezentálni, amelynek minden eleme pl. 1,2,3, vagy 4 (pl. 1,3,2,1,2,4,3,2,4), és meg lehetne állapodni, hogy a sorozat elemei rendre az (sor,oszlop)=(1,1),(1,2)(1,3)(1,4),(1,5)(2,2),(2,3),(2,4),(3,3) elemek által reprezentált 4-esek valamelyik elemét jelentik. A fenti példából az (1,1),(6,5),(3,6),(1,4),(5,6),(5,2),(5,4),(4,5),(4,3) Cardano rács adódik, méghozzá úgy, hogy a reprezentáló elemeket helyben hagyjuk (a kulcsban ezt 1 jelöli), vagy 90 fokkal jobbra (2 jelöli), 180 fokkal jobbra (3 jelöli), 270 fokkal jobbra (4 jelöli) forgatjuk.
Lehetne bonyolítani a programot, hogy a kulcsot ilyen tömörebb módon adjuk meg.
Érdemes lenne elgondolkozni azon, hogy hogy lehet egy elég hosszú szöveget a kulcs ismerete nélkül megfejteni. A maga idejében ez elég reménytelen feladatnak látszott, azonban számítógép segítségével ma már nem az.„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 kovisoft #6044 üzenetére
Lehet nem jó smiley-t tettem a mondat végére? Reméltem, hogy érteni fogod a viccet. Direkt nem írtam oda kiszámolva, hogy szemmel láthatóan különbözőnek tűnjön. Na persze, ha valaki kiszámolja,... úgy nem ér!
[ 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 #90088192 #6053 üzenetére
Alapvetően azzal kell tisztában lenni, hogy az #include-okkal beszúrt fájlok az őket beinklúdoló fájlokkal együtt egy fordítási egységet (translation unit TU) képeznek. Az #include egy direktíva, a C előfordítónak szól, és egyszerűen szöveg-szinten beszúrja az inklúdolt fájlt. Tehát olyam, mintha copy-pastéval bemásolnád a fájlt. Ezért az inklúdokban nem lehet körbe hivatkozás (a.h inklúdolja b.h-t, ami inklúdolja a.h-t), és nem lehet többször inklúdolni ugyanazt a fájlt (mert ekkor keletkezik a többszörös defínició). Az utóbbi elkerülésére az ún. include guard megoldást használjuk:
Pl. egy include file így néz ki:#ifndef __include_guard_h //itt a nev include fájlonként különböző és a fáj nevére utal
#define __include_guard_h
//ide jön az include file tartalma
#endif
Ezzel azt érjük el, hogy egy TU-ban ne lehessen az include fájlt többször beszúrni. Ugyanis először az __include_guard_h makró még nincs definiálva, tehát a fájl tartalma feldolgozásra kerül, miközben a makró definiálttá válik. Következő eseleges beszúráskor a makró már definiálva lesz, de a #ifndef direktíva hamosra lesz kiértékelve, vagyis a feldolgozás az #endif után folytatódik. A körbe hivatkozások ellen az include guard nem véd, arra neked kell odafigyelni.
C forrás fájlokat tényleg nem szoktunk inklúdolni. Ha több forrás fájlból áll a projected, akkor azokat a project létrehozásakor (project fájlban) kell megadni. Ezek külön-külön fordítási egységet fognak képezni (az általuk beinklúdolt header fájlokkal együtt), amikben már újra inklúdolhatod a másik TU-ban beinklúdolt header fájlt. A külön fordítási egységekben definiált függvények és globális változók egymás közötti elérhetőségét a linkelés (linker) fogja biztosítani.
Esetenként előfordul (pl. template-ek használatakor), hogy header fájlban függvény definícót írnak, amik a különböző TU-kba való inklúdolások után a linker számára valóban többszörös defínicók lesznek, de ezt a legtöbb linker kezeli. Ettől még kerülendő ez a gyakorlat, ha nagyon kell akkor inline-ként megadható, bár azt a fordító dönti el, hogy valóban inline módon fordítja-e.„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
-
jattila48
aktív tag
válasz borisz1994 #6064 üzenetére
Ahogy többen írták, deklarációra akkor van szükség, ha egy változót, függvényt, vagy típust előbb akarsz használni, mint ahogy definiálnád. Lokális változóknál nincs különbség, ott a deklaráció egyben helyfoglalással is jár. Főleg globális változók és körbe hivatkozások használatakor kell külön deklarálni, és defniálni. Globális változó deklarálása az extern kulcsszóval történik.Valamelyik fordítási egységben ennek definiáltnak kell lenni, a többi, rá hivatkozó TU-ban pedig extern-nel deklaráltnak kell lenni. Függény deklarációjánál extern kulcsszóra nincs szükség (bár megadható). C-ben a függvények mindig globálisak (nincs lokális fv. ellentétben néhány más programozási nyelvvel). Az előre deklarálást nem tudod elkerülni (program szöveg átrendezéssel), ha körbe hivatkozás van (pl. f fv. hívja g-t,ami hívja f-et). Ilyenkor valamelyiket mindenképp előre kell deklarálni (ezt hívják fv. prototipusnak), aminek a tényleges definícióját (a fv. kódját) csak a másik fv. definíciója után tudod megadni. Fontos eset még a struktúrák előre deklarálása. Ezt is a körbehivatkozás teszi szükségessé (pl. rekurzív adatszerkezetek), hasonlóan, ahogy fv.-ek esetén is. A struktúra definíciója hivatkozik B stuktúrára, ami szintén hivatkozik A-ra. Ekkor azonban a csak előre deklarált struktúra típus nem teljes értékű (hiszen még nem ismerjük a szerkezetét), ezért csak rá mutató pointer típus deklarálható a hivatkozó struktúrában. Az ilyen típust incomplete type-nak hívják.
„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 Ereshkigal #6068 üzenetére
attól az még globális, abban az értelemben, hogy nem lokális. persze nem elérhető más tu-ból. De ha nagyon akarod, tekintsük kivételnek. A c-ben ettől még nincs lokális fv.
„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
-
jattila48
aktív tag
válasz pmonitor #6168 üzenetére
"Biztos vagyok benne, hogy a megfelelő if-ek megválasztásával ha nem is teljesen..."
De, teljesen. Csak tök fölösleges, mert csak érthetetlenebb, nehezebben karbantartható, több hibalehetőséget magában rejtő lesz a kód. Tökéletesen egyetértek dabadab-bal, hogy lehet hülyén használni a goto-t, de ezért kategorikusan megtiltani, még nagyobb hülyeség lenne. A dabadab által mutatott példa abszolút tipikus a megfelelő goto használatra, az általad mutatott elkerülése pedig tipikus antipattern. Ennyi erővel a return utasítást is száműzni kéne, mert a fv. közepéből kiugrasz a fv. törzsből (kivéve a fv. végére írt return-t; Pascalban egyébként ezért nincs is return). Remélem az ELTE-n már nem ragaszkodnak ennyire vaskalaposan a struktúrált programíráshoz (mikor én végeztem ott, akkor még igen), mert a mai objektumorientált és eseményvezérelt programok korában részben egyszerűen idejétmúlt. Persze megvan a maga létjogosultsága a józanság keretei között. Hasonlóan értelmetlen káros vaskalaposság a globális változók tiltása. Mindent meg lehet írni globális változók nélkül, csak rengeteg fölösleges paraméterátadással, hibázási lehetőséggel jár, ha eszetlenül ragaszkodunk hozzá. Ha belegondolsz, a C++ osztályok tagfüggvényei számára az adattagok lényegében globális változók.[ 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 pmonitor #6213 üzenetére
A #6179 példa valóban jó, de dabadab kritikájában is van azért igazság, annál is inkább, hogy ennél az egyszerű szerkezetű példánál sokszor bonyolultabb a vezérlésszerkezet, amit nem lehet ilyen szépen struktúrálttá alakítani.
Egyébként nem tudom mit nem értesz meg, senki nem mondta, hogy ha lehet és ésszerű, akkor ne struktúrált szerkezetet használj. Csak arról írtunk, hogy nem mindig célszerű erőltetni a dolgot. Van ahol igenis helyénvaló a goto használata (C hibakezelés), a mindenáron történő struktúrált kikerülése pedig kifejezetten antipattern. A késsel is megvághatod magad, mégis használod pl. kenyérszeletelésre, ellenben fogpiszkálónak valóban nem a legalkalmasabb. Csak erről beszéltünk. Hogy mit írt Dijkstra több mint 50 évvel ezelőtt, az csak egy dolog. Akkor még nem volt eseményvezérelt és objektumorintált programozás, nem léteztek grafikus UI-k, stb. Az akkori környezetben teljesen helyénvaló volt a szigorú struktúrált programozási elv, ami egyébként az assembly/Fortran nyelvek kényszerű használatából adódó programozási krízis megoldására született. Az általa leírt struktúrált programozási elveket/szerkezeteket automatikusan (sémaszerűen) meg lehetett valósítani assembly és fortran nyelveken természetesen goto-k használatával. Azonban a probléma ott volt, hogy (mivel a nyelvekben nem voltak struktúrált szerkezetek beépítve), sokszor elég ötletszerűen (túl intuitívan) alkalmazták a goto-t. Másrészt a memóriával is spórolni kellett, úgyhogy ha volt egy már egyszer megírt programrészlet, egyszerűen goto oda, majd vissza... Na ennek a helyzetnek a kezelésére született Dijkstra (aki egyébként kiváló tudós volt) struktúrált programozás javaslata. Azóta a helyzet sokat változott. Részben születtek struktúrált szerkezeteket támogató programozási nyelvek, részben pedig ahogy írtam, az objektumorintáltság és eseményvezéreltség is előtérbe került (ezeket nem igazán lehet tankönyvszerűen struktúrált módon kezelni). A Dijkstra féle megközelítést most is érdemes szem előtt tartani, de eszetlenül erőltetni (goto kategórikus tiltása), szerintem butaság.
Végezetül engedj meg egy személyes megjegyzést, amit egyáltalán nem bántásnak szánok. A hozzászólásaidból az jön le, hogy kezdő vagy a programozásban (ez persze egyáltalán nem baj), és nem írtál még igazán nagyobb programot. Ragaszkodsz bizonyos (túlságosan is megkövesedett) elvekhez, amit a tanáraidtól tanultál, csak a gyakorlat sajnos más, mint a tankönyvi példák. Ha majd windows (Linux) rendszeren kell nagyobb programokat írnod, rájössz, hogy szépek az elvek, de időnként érdemes testreszabni őket.[ 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 pmonitor #6217 üzenetére
Remélem nem sértődtél meg, mert nem akartalak megsérteni.
Nincsenek publikus referenciáim, mert az általam írt kódok (munkámból adódóan) kifejezetten nem publikusak. Egyébként az ELTE-n végeztem programtervező matematikusként 1988-ban. Azóta programozóként dolgozok.„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 pmonitor #6242 üzenetére
Légy szíves ne csúsztass! Nem azt mondtam, hogy az a kód jobb mint dabadabé, hanem csak annyit, hogy logikailag az is jó. Dabadab kritikája pedig jogos, csak úgy látszik túl finoman fogalmaztam. Azt próbáld megérteni, hogy senki nem mondta, hogy bizonyos esetekben a goto-t nem lehet elkerülni. Mindig el lehet kerülni, csak nem mindig célszerű. Vannak olyan helyzetek (tipikusan a dabadab által bemutatott C hibakezelés), amikor "bűn" a goto kiirtásán görcsölni. Másik eset, amit kovisoft említett, hogy ha egy régi, mások által írt (legacy) kódban kell túrkálnod, akkor a legkevesebb kárt úgy teszed, ha kényszerűen goto-kat használsz, ahelyett, hogy mások átláthatatlan struktúráiba próbálnál belepiszkálni.
Legtöbben igyekszünk elkerülni a goto használatát (ez egy javasolt gyakorlat), de nem minden áron. Én pl. igen ritkán használom, csak a dabadab által mutatott C hibakezeléskor. Akkor viszont ez az ajánlott pattern. Tényleg nem akar senki megbántani (én aztán főleg nem), de amint látod, vagyunk itt páran, akiknek szakmája a programozás, és feltehetően jóval nagyobb a tapasztalatunk mint neked. Ez persze nem ultimate érv, de hogy el se gondolkozz azon, hogy esetleg nem Te mész-e szembe az autópályán... ez bizony jókora önbizalomra vall.„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 pmonitor #6251 üzenetére
Hát már csak tudom, hogy mit írtam, és mit gondoltam! Nehogy megmagyarázd már! Most már kezdesz bosszantani!
"jattila48 is elismerte, hogy a szóban forgó kód jobb, mint a tiéd."
Márpedig én ilyet nem írtam. Nem jobb, hanem az is jó. Leglábbis logikailag. Dabadab kritkája pedig másra vonatkozott, amiben igaza is van. Remélem érted, mi a különbség. Szóval nem csúsztatsz, hanem hazudsz.
Azt ismertem el, hogy struktúrálttá alakítottátok a kódot, ami azért nem egy nagy érdem. Nem a kód szép, hanem a szépen arra vonatkozott, hogy könnyen (==szépen, egyszerűen) lehetett struktúrálttá alakítani. És ezennel egyértelműen kijelentem, hogy a struktúrált kód nem lett szép (==könnyebben értelmezhető mint a goto-s kód), főleg nem szebb, csak logikailag ekvivalens az eredetivel.
A csúsztatásokat pedig légy szíves hagyd abba! Vagy a szövegértelmezéssel vannak problémáid, vagy csak egyszerűen kötekedni akarsz.
Nem libsi újságíró vagy véletlenül? Azoknál tipikus ez az attitűd.[ 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 pmonitor #6258 üzenetére
Azta q*va! Komám, te aztán tényleg nagy mestere vagy a csúsztatásnak!
Ezt írtam: "Ennyi erővel a return utasítást is száműzni kéne, mert a fv. közepéből kiugrasz a fv. törzsből ".
Szerinted itt bajom volt a fv. törzs közepében elhelyezett return-nel? Ez pont azt jelenti, hogy ha a goto-t száműzzük, akkor a return sem kéne meghagyni, mert az is ugyanúgy megtöri a struktúrált szerkezetet, mint a goto általi hibakezelés. Vagyis egyiket sem kell száműzni. Tudod, ha nagynénédnek kerekei lennének, ő lenne a miskolci gyors...
Egyébként buherton kódjához egyáltalán nem szóltam hozzá, ha nem vetted volna észre.[ 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 pmonitor #6262 üzenetére
Nem a felmenőidet emlegettem! Ezek szerint nem ismered ezt a vicces kis mondatot, aminek tagadását formális logikai feladatnak szokták adni. Írhattam volna a saját nagynénimet. Tartalmilag értelmetlen, éppen ezért sok embernek okoz gondot a tagadása. Másrészt példa arra, hogy hamis előtagból bármi következik. Vagyis, ha száműzzük a goto-t, akkor lehet száműzni a return-t 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
-
jattila48
aktív tag
válasz #90088192 #6266 üzenetére
Tudtommal az Intel processzorok tartalmaznak transzcendens (sin, log,...) floating point műveleteket. Egyébként valószínűleg vegyesen használnak táblázat adatokat, és közelítéseket. Igen hatékony tört közelítések léteznek ezekre. A szögfüggvények hatványsorai ugyan gyorsan konvergálnak, de tudtommal nem ezeket használják. Lehet, hogy táblázatból kikeresik a legközelebbi érték sinusát, majd az akörüli Taylor sor néhány tagjából egy törtet számítanak ki. Ez csak tipp.
„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 pmonitor #6291 üzenetére
Mintha kicsit gondjaid lennének a formális logikával. Abból, hogy A-ból következik B, még B-ből nem következik A. Pedig többször ezt a sémát használod érveléseidben.
"léteznek olyan problémák, amiket ott is csak egymásba ágyazott if-ekkel lehet megoldani."
És? Senki nem állította ennek az ellenkezőjét. Abból, hogy vannak olyan problémák (C hibakezelés), amit egymásba ágyazott if-ek helyett goto-kal érdemes megcsinálni, még nem következik, hogy minden probléma ilyen. Tehát ettől lehet olyan probláma, amit egymásba ágyazott if-ekkel célszerű (vagy azzal lehet) megcsinálni. Hol itt az ellentmondás? Miért kérsz számon olyan állításokat, amit a másik fél nem mondott? Ha én azt mondom, hogy A-ból következik B, akkor miért kéred számon, hogy mért mondok olyan butaságot, hogy B-ből következik A? Én ilyet nem mondtam, meg a többi vitapartnered sem.
„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 dabadab #6334 üzenetére
Az "illene", azt úgy értettem, hogy kötelező. Nem lehet idő- és erőforrás hiányra hivatkozni, mert később az ilyen hanyagság megbosszulja magát, ami majd többszörösen elpocsékolja a szűkös időt és erőforrást.
„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 alapz@j #6345 üzenetére
Ja, hagyhattad volna. Dabadabnak válaszolva le is írtam, hogy én is arra gondoltam, mint ő. Technikailag nagyon is tisztában vagyok vele, hogy lehet ilyen hibát elkövetni. Inkább azt nem értem, hogy (valószínűleg nem kezdő) programozók production kódban hogyan követhetnek el ilyet, és hogy maradhat benne egy code review során. Egyébként évekkel ezelőtt tettem szóvá ezt: [link] . Move szemantika, lap alja, visszatérés jobbérték referenciával. A hibát elismerték, azóta is hibásan van kint. Remélem a diákok nem veszik szentírásnak az ott leírtakat. Vagy mégis? Mert akkor már értem.
„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 sztanozs #6349 üzenetére
"az új kód inkább turkál a (memória-) szemétben"
Ja, aztán valakinek eszébe jut újra buildelni új fordítóval, vagy más opciókkal (optimalizálás, stack check, debug, ...), és szószerint szemétben túrkálás lesz belőle, aztán megy a fejvakarás, hogy eddig működött, most már nem, biztos a fordító szar. Láttam már ilyet. És valóban: Time is money.„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
● olvasd el a téma összefoglalót!
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Zenelejátszó építése, a kiváló hangzásért
- Sarokba szorította a Huawei az Apple-t Kínában
- Samsung Galaxy Fit 3 - keveset, de jól
- Egyszerűsíti termékportfólióját a HP
- Milyen belső merevlemezt vegyek?
- Politika
- Xiaomi Mi 9 - egy híján
- Gitáros topic
- Autós topik látogatók beszélgetős, offolós topikja
- Jövedelem
- További aktív témák...
- 2 év gari: Olcsó DDR5 PC/I5 12400F/16GB/500GB M2/Suprim X RTX 3070/Futár is
- -70% HP EliteBook 850 G7:i7 10610U,32GB RAM,512GB SSD,15.6" FHD,vil.MAGYAR numeri.bill,WWAN 4G,Win11
- ASUS TUF Gaming GeForce RTX 4070 Ti 12GB
- Hama Ultraslim Fali konzol (TV)
- ÉRKEZETT Legújabb Bontatlan Új M2 IPAD PRO 2022 12,9 128GB - 256GB Wi-Fi Azonnal DEÁK TÉRNÉL Átvehe
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs