- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Modern monitorokra köthető 3dfx Voodoo kártya a fészerből
- Gaming notebook topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen alaplapot vegyek?
- VR topik (Oculus Rift, stb.)
- Micro Four Thirds
- Milyen videókártyát?
- Épített vízhűtés (nem kompakt) topic
- Vezetékes FEJhallgatók
Hirdetés
-
Megjelenési dátumot kapott a Star Wars: Hunters
gp A tervek szerint június elején végre befut a teljes kiadás mobilokra/tabletekre és Nintendo Switch-re.
-
Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
ph A Kereskedelmi Minisztérium egyelőre csak felméri a helyzetet, egyelőre nem látni, hogy tudnak-e bármit is tenni.
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
Új hozzászólás Aktív témák
-
nagyúr
válasz kicsitomi88 #48 üzenetére
Regen en is igy gondoltam, de nem feltetlen szukseges a matektudas a programozashoz, ez a helyzet. Rengeteg programozasi feladat van, ahol az uzleti tudas joval fontosabb. (uzleti = domen specifikus)
Szerk.: bazz, beneztem a datumot
[ Szerkesztve ]
while (!sleep) sheep++;
-
nagyúr
while (!sleep) sheep++;
-
nagyúr
Akinek a ternary operator bántja a szemét, az szerintem menjen el kapálni
while (!sleep) sheep++;
-
nagyúr
válasz Pttypang #5105 üzenetére
Van a neten csomofele leiras, erdemes rakeresni, de probaljuk meg itt is.
Ugyebar C-ben (es mas imperativ prog. nyelvekben is) vannak valtozoink, vagy nevezzuk oket inkabb ertekeknek, mert az tokmindegy, hogy valtoznak-e vagy sem. A forditonak megprobaljuk megmondani, hogy milyen tipusu az az ertek, amit letrehozunk. (A tovabbiakban tegyuk fel, hogy sima 32 bites arhichitekturan vagyunk). Pl.:
double a = 1;
Egy valtozorol mindig ket dolgot tudunk: mekkora helyen fer el (hany bitnyi hosszu), es hogyan ertelmezzuk. Azt, hogy hogyan/minek ertelmezzuk, szoktak tipusnak is nevezni.
Most 'a'-rol a kovetkezoket tudjuk:
- 64 bitnyi informacionk van
- ezt egy elojellel rendelkezo lebegopontos szamkent ertelmezzukHa van egy ilyenunk:
double * a;
.. akkor errol az tudjuk, hogy
- 32 bitnyi informacionk van
- ez egy egesz szam, es ugy ertelmezzuk, mint egy memoriacimet. A memoriacimen pedig egy 64 bit hosszu lebegopontos szamot talalunk.Tehat a pointer egy jellemzoen 32 vagy 64 bitnyi informaciot tartalmazo szam. A memoria szepen be van szamozva 0-tol 2^32 vagy 2^64-ig. Ha ahhoz a memoriarekeszhez mesz, aminek a szama megegyezik a pointer ertekevel, akkor ott egy olyan erteket talalsz, aminek a tipusa a pointer tipusaban jelezve is van.
A pointert a * jelzi altalaban. Ha van pl. egy
double ** a;akkor az a kovetkezo jelenti, analog modon:
- van egy 32 bites ertekunk
- ez egy egesz szam, es ugy ertelmezzuk, mint egy memoriacimet. A memoriacimen pedig egy 32 bit hosszu egesz szamot talalunk, amit ugy ertelmezunk, mint egy 32 bites erteket, amit ugy ertelmezzunk, mint egy memoriacimet. A memoriacimen pedig egy 64 bit hosszu lebegopontos szamot talalunk.Ez idaig vilagos?
(Tobbieknek: szandekosan vagyok pontatlan az int, double, etc. meretevel kapcsolatban.)
while (!sleep) sheep++;
-
nagyúr
válasz Pttypang #5110 üzenetére
Vegulis ezen kivul nincs tul sok dolog. Par aprosag:
- az operatorok probalnak okosak lenni, ezert ha pl. inkrementalsz egy pointert (ami ugye egy sima elojel nelkuli egesz szam) akkor az nem feltetlen egyet ugrik, hanem annyit, amekkora annak a tipusnak a merete, amire mutat. Tehat pl. egy 64 bites double-ra mutato pointer egy 32 bites architekturan 8 bajttal novekszik, ha inkrementalod.
double ertek = 5;
double * a = &ertek;
printf("%p\n", a);
a++;
printf("%p", a);>> 09FFB28
>> 09FFB30
Ketto kulonbsege: 8- a tomb az nem mas, mint a tomb kezdetere mutato pointer
.. most jo lenne, ha konkret dolgokat kerdeznel
while (!sleep) sheep++;
-
nagyúr
válasz Pttypang #5112 üzenetére
Erre is jo, de alapvetoen ez nagyon szuk resze a pointerek felhasznalasi modjanak. Azt gondold vegig, hogy imperativ programozasi nyelvekben (pl. C) megkulonboztetunk ket dolgot:
- ertek
- identitasTehat ha van ket valtozonk:
int a = 5;
int b = 5;.. akkor az ertekuk megegyezik, az identitasuk nem. A pointer arra jo, hogy ne erteket kezelj, hanem identitast. Ha atadom egy fuggvenynek a 'b' valtozo erteket, akkor az 5-ost adom at. Az eredeti b-vel (az identitassal) nem tud a hivott fuggveny semmit sem kezdeni, hiszen arrol nem tud, o csak az erteket (5) latja. Ha a b-re mutato pointert adom at (&b), akkor a hivott fuggveny az identitasrol tud, meg tudja valtoztatni b erteket, ha akarja.
Kepzelj el pl. egy fuggvenyt, ami kicsereli ket valtozo erteket. Ezt nem lehet megcsinalni csak ertekek atadasaval -- a 'csere' fuggveny bemenete ket _identitas_, hiszen ertekeket nem lehet megcserelni, azok ugyanugy ertekek maradnanak.
Funkcionalis nyelvekben (pl. Lisp, ML-leszarmazottak) nincs szukseg ilyesmire, mert ott csak ertekek vannak, identitas nincs. (Illetve van, csak sokkal jobban kezbentartott modon kezeljuk.)
[ Szerkesztve ]
while (!sleep) sheep++;
-
nagyúr
válasz Pttypang #5114 üzenetére
- a 'kerulet' valtozot inicializalni kene (0-ra)
- a tomboket (es kb. mindent C-ben) 0-tol kezdodoen indexalunk, tehat az elso elem indexe 0, az n. elem indexe n-1, tehat a lehet_e_haromszog-ben az indexeket csokkentsd eggyel
- if (lehetvagynem = 1)
nagyon tipikus C/C++ hiba: a '=' operator ERTEKADAS, nem pedig egyenloseg-ellenorzes. Az ertekadas eredmenye az ertek. C-ben az if utan kovetkezhet szam is, nem csak boolean ertek (ha nem nulla, akkor igaznak szamit), tehat
if (a = 5) {
// ez itt mindig vegrehajtodik, mert erteket adtal a-nak, es az nem nulla
}Szoval if (lehetvagynem == 1) a helyes.
Te meg az elejen vagy, szoval ha lehet, szokd meg, hogy ugy tesztelunk egyenloseget, hogy bal oldalon van a konstans. Ergo:
if (1 == lehetvagynem) { }
.. ugyanis ha veletlenul elgepeled, akkor szolni fog a fordito.
[ Szerkesztve ]
while (!sleep) sheep++;
-
nagyúr
válasz DrojDtroll #5144 üzenetére
Egy rekurziv megoldas lehet, pszeudokodban:
szavak_listaja = ures_lista;
fuggveny generalj_szot(szotoredek, rendelkezesre_allo_a, rendelkezesre_allo_b) {
ha szotoredek hossza = x akkor add hozza a szavak_listaja-hoz szotoredeket;
egyebkent
{
ha rendelkezesre_allo_a > 0 akkor generalj_szot(szotoredek+"a", rendelkezesre_allo_a-1, rendelkezesre_allo_b);
ha rendelkezesre_allo_b > 0 akkor generalj_szot(szotoredek+"b", rendelkezesre_allo_a, rendelkezesre_allo_b-1);
}
}Ezt at lehet alakitani rekurzio nelkulire, ha ugy tartja kedved.
while (!sleep) sheep++;
-
nagyúr
válasz EQMontoya #5198 üzenetére
Konkretan elkezdtem ezt irni, de aztan ugy gondoltam, hogy nem trollkodok ennyire bele a forumba Ezzel annyi lehet a gond C-ben, hogy ha az eredeti matrixot megvaltoztatjak, miutan visszaadtad a fvptr-t, akkor esetleg problema lehet. Rendes funkcionalis stilusban ez az alapmegoldas egyebkent, es ott meg azzal sincs gond, hogy valaki kirantja alolad a szonyeget (ill. az eredeti erteket).
while (!sleep) sheep++;
-
nagyúr
válasz Jester01 #5200 üzenetére
> "Bizonyos mennyiség fölött garantáltan sokkal lassabb lesz, mintha ténylegesen transzponáltad volna."
Algoritmustol fugg. Ha kevesszer transzponalsz, de sokszor olvasol, akkor igen. Ha sokszor transzponalsz, es kevesszer olvasol, akkor a te megoldasod lehet drasztikusan lassabb. Ha pl. marha nagy matrixokkal dolgozol, de a transzponalt matrixot felhasznalo fel minden matrixbol csak nehany elemet vesz ki, akkor a lazy megoldas a jobb.
while (!sleep) sheep++;
-
-
nagyúr
válasz #36268800 #5237 üzenetére
Fuggvenybe olyan funkcionalitast celszeru kiszervezni, amiket a kod tobb pontjan is hasznalsz. Az, hogy feldarabolsz egy adott funkciot tobb reszre, eleg ertelmetlen (bar sokan azt valljak, hogy egy fuggveny ne legyen hosszabb X sornal, de ez szerintem butasag).
while (!sleep) sheep++;
-
nagyúr
válasz dabadab #5241 üzenetére
Tehat vegulis az ok, amiert szet akarod szedni, az a konnyebb navigacio. Ennek a megkonnyitese szerintem az IDE dolga lenne, nem a programszervezese, es a modern IDEk mar szoktak tudni fold/collapse funkciot C++-ra is, ha jol gondolom. .Net-ben ott a #region pragma, ami pont erre valo; Java-ban a sok patternhuszar ugyis haromsoros classokba szervez mindent ( ), funkc. nyelvek meg altalaban tul tomorek ahhoz, hogy ilyen hosszu fuggvenyeket irjon az ember.
while (!sleep) sheep++;
-
nagyúr
válasz dabadab #5247 üzenetére
C/C++-ban tenyleg nem (amikor azzal dolgoztam, akkor maniakus overengineering ment a fejlesztes soran, es az kod nagy resze pure virtual osztalyokbol epult fel ), mas nyelvekben lattam hasonlot, de nem volt extra szenvedes, ez teny. (Es 40 agas switch/case szerkezetekkel se sokat talalkoztam, ez is teny; nem tudom, hogy ez szerencse, vagy tapasztalatlansag .)
Mondjuk azert masrol beszelunk. En azt mondtam, hogy onmagaban a fuggveny hossza nem problemas, te meg azzal jossz, hogy ha nagyon bonyolult switch/case szerkezetek vannak, vagy a valtozok deklaracioja/ertekadasa es felhasznalasa kozott van 40 kepernyonyi kod, az problemas. Ezt elfogadom/elhiszem, de ugye itt nem a kod hosszaval van a gond -- a kod hossza az kovetkezmenye a problemanak, de nem az oka.
APL(-szeru) nyelven neztem bazi hosszu, teljesen strukturalatlan kodokat - ott ugye nem jellemzoek a fuggvenyek, viszont az sem, hogy regesreg krealt ertekeket hasznalsz sokkal-sokkal kesobb; inkabb sok-sok egymas utan kovetkezo es egymasra epulo lepest irnak le. Peldaul ilyen esetben semmi problema nincs a hosszu koddal.
De tenyleg nem tudok az erveddel vitatkozni
while (!sleep) sheep++;
-
nagyúr
válasz dabadab #5250 üzenetére
A k/q write only, akarhogy strukturalsz
Ha meg van code folding, akkor
#region Do something complex
do_something_simple();
do_something_even_simpler();
#endregionDe ha sima C-rol van szo, akkor igazabol nincs gyakorlati tapasztalatom real life, szoval elfogadom, ami mondasz.
while (!sleep) sheep++;
-
nagyúr
válasz Jester01 #5256 üzenetére
Ahogy irtam, generalt kod(kent indult).
Egyebkent meg a goto-val az a baj, hogy nagyon konnyu rosszul hasznalni. Maga a goto utasitas nem egy bun, alapvetoen. [link] (Egyebkent meg a compiler okossagatol fuggoen a while-continue lehet egy utasitassal lassabb, mint a goto..)
[ Szerkesztve ]
while (!sleep) sheep++;
-
nagyúr
válasz alapz@j #5690 üzenetére
Az egyik elv az, hogy csak akkor valtoztatnak meg szabalyokat/mintakat, amikor arra kifejezetten jo ok van. Tehat ha idaig jo volt az ANSI, es az ujabb feladatokat is meg lehet oldani igy, akkor nem tesznek a fejlesztokre extra mentalis terhet azzal, hogy varialnak.
A C++ (Scala, etc.) egyik fo problemaja, hogy nagyon sok modszerrel meg lehet csinalni ugyanazt. C++-ban irhatsz proceduralis, OO, funkcionalis, etc. programot, ami egyreszt meno+kenyelmes, masreszt sokkal nehezebb megakadalyozni, hogy egy nagyobb projektnel divergaljon a stilus/megkozelitest. A sokfele megkozelites meg azt eredmenyezi, hogy a projekt reszvevoinek 1) allandoan el kell donteni, hogy melyiket alkalmazzak 2) nehezebb ertelmezni a masik kodjat.
Pl. a Java ezert is olyan sikeres -- egy Java kodot _barki_ el tud olvasni. (Ott a komplexitast attoltak a frameworkok szintjere.)
while (!sleep) sheep++;
Ú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!
- League of Legends
- Ukrajnai háború
- Call of Duty: Modern Warfare III (2023)
- Eredeti játékok OFF topik
- Szevam: Érzelmi magabiztosság/biztonság - miért megyünk sokan külföldre valójában?
- DIGI kábel TV
- Helldivers 2 (PC, PS5)
- Az USA nem akarja visszafogni Kína növekedését
- Huawei Mate 10 Pro - mestersége az intelligencia
- Elektromos rásegítésű kerékpárok
- További aktív témák...
- Új Hp Pavilion 15-eh Fémházas Szuper Laptop 15,6" -30% AMD Ryzen 7 5700U 8Mag 16/1TB FHD MATT
- ATI RADEON RX 480 -8 gb DDR5 256 bit videokártya
- Geforce GTX 460-1 gb DDR5 256 bit videokártya
- Geforce G 210 -1 gb videokártya
- Díszdobozos Lenovo Yoga Slim 7i Pro "Kis Gamer" Ultrabook 14" -40% i5-11300H 16/512 QHD+ 2,8K OLED