- ricsi99: 6. Genes alaplap tündöklése.. kontra MS/Zintel korlátozásai.(Mehetnek a levesbe)
- sziku69: Fűzzük össze a szavakat :)
- Doky586: Adattár lemez előkészítése távlati Windows telepítéshez
- sh4d0w: Tele a hócipőm
- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- gban: Ingyen kellene, de tegnapra
- Magga: PLEX: multimédia az egész lakásban
- sellerbuyer: Te tudod, mi mennyit fogyaszt az otthonodban?
- GoodSpeed: iPadOS 26 A Liquid Glass varázsa
-
LOGOUT
Új hozzászólás Aktív témák
-
pmonitor
aktív tag
>az értelmetlen sebesség optimalizálás felesleges. Egy weboldal betöltése nem ez a kategória.
Ebben a hozzászólásodban meg ezt írtad:
>kliens oldalon tök mindegy, hogy 0.1 mp vagy 1 mp, ezért is felesleges agyonoptimalizáni bármit.
Eldönthetnéd, hogy akkor most mi is a helyzet kliens oldalon. Egyébként sztem. az első idézet a helytálló. Tehát hogy "Egy weboldal betöltése nem ez a kategória.". Éppen ezért sztem az lenne a megoldás, hogy az illetékes programozók "agyonoptimalizálnák" pl. a javascriptet(is).
De nem szeretnék túl sok rizsát itt. Majd a webhelyemen készítek egy "Ellentmondások a fórumozó programozóktól" című részt(Ha lesz rá időm).
-
pmonitor
aktív tag
válasz
pmonitor
#17191
üzenetére
Jaah! De ezt úgyis tudod. Idézet tőled:
>Annak, hogy egy programnyelv jó-e vagy rossz, egy csomó szempontja lehet, nem csak a futásidőben nyújtott teljesítmény. Hiszen, ha így lenne, akkor nem lenne feljövőben a Python, a PHP már vagy egy évtizede ki kellett volna, hogy haljon, a javascriptről nem is beszélve
Tehát saját magad is beismered, hogy a js a leglassabbak között van.
-
-
pmonitor
aktív tag
válasz
fatal`
#16995
üzenetére
#16991:
>A legtöbb helyen látni a típust a kifejezésből, tök felesleges kiírkálni. Ráadásul írhatod át, ha még a végére fűzöl valamit.Én erre a hsz-edre írtam.
Jó, mondjuk Linq esetén igazából nem nagyon van választás(végülis erre találták ki eredetileg). De az egész kód nem Linq-ból áll.
-
pmonitor
aktív tag
válasz
fatal`
#16987
üzenetére
Csak az, hogy rontja a kód olvashatóságát. Főleg így, ahogy martonx ítra:
>a legtöbb helyen a var-t a legcélszerűbb használni,Ha a legtöbb helyen var-t használ valaki, az az olvashatóságot jelentősen csökkenti. De előfordul, hogy "egymagában" is rontja az olvashatóságot. Pl.:
foreach (var item in list)Ezen csak a nagyon jól megválasztott változónév segíthet valamit, de ez hajszálvékony jég... -
-
pmonitor
aktív tag
válasz
martonx
#16983
üzenetére
Látom tényleg nincs időd Ilyenre, de fórumozásra, arra jut
Te csak használd nyugodtan a var-t majdnem mindenhol, mint rutinos .net programozó. 
De látom a mostani ON témához a "PH! megmondói" közül senki nem tud érdemben hozzászólni. Példakódot meg természetesen ne is várjon az illető, mert beletörne az igazi programozók ujja... -
pmonitor
aktív tag
válasz
K1nG HuNp
#16965
üzenetére
>hogy a fórumos vérpistikék egy csúnyább beszólás után még élőben is zaklassák? hát nem kösz
Nem kell olyant írni, hogy csúnyább beszólás legyen belőle. Inkább akkor a hallgatást választanám. És ha nincs csúnyább beszólás, akkor nincs élő zaklatás sem. Nem hiszem, hogy az általam megadott fejlesztőket bárki is zaklatná.
#16969:
Sztem. ha valakinek van ideje, akkor mindig jó egy új programnyelvet kipróbálni. Agytágítás sosem árt. -
pmonitor
aktív tag
>Ez a szabály csak azokra vonatkozik, akik igazi programozók, ő saját bevallása szerint nem az, szóval neki nem kell.
Ez pontosan így van! Gondolatolvasó vagy! Bár hozzáteszem, hogy az sem ártana, ha valamennyi programozó megtenné, hogy legalább a nevét felvállalja. De ahogy mondtad: aki elvárja, hogy programozónak nézzék, őneki sztem. kötelező lenne. Na jó, nem annyira részletesen, hogy TAJ szám, meg egyebek...
-
pmonitor
aktív tag
>A fórumról több kolléga is olyan dolgokan dolgozik / dolgozott mint valamilyen nagy magyar vállalat webshopja vagy valamelyik mobilbank applikáció és hozzá tartozó backend.
És ezt miért kell titkolni? Ők pl. titkolják, hogy hol dolgoznak?
Horpácsi Illés: Senior szoftvermérnök Evosoft
Deák Gergely: Senior developer Accenture
Romhányi Ármin: Full Stack developer En-Co Software Zrt.
Ruzsinszki Gábor: Software architect EvosoftŐk vajon miért is nem titkolják, hogy hol dolgoznak? Sztem. aki olyan helyen dolgozik/dolgozott, azt nyugodtan felvállalhatnák itt a fórumon is. Vagy vaj van a fülük mögött(rossz úton járnak), hogy nem merik megtenni? Vagy, vagy, vagy...
Én Rád teljesen másképp nézek, mint a többiekre, mióta felvállaltad magad. Mondjuk attól még nagy szakadék van a felfogásunk között, de ennek ellenére is... Mert tudom, hogy van önálló munkád, nem csak a levegőbe beszélsz(illetve írsz). Egyrészt ezért is hallgatok Rád, hogy ne kezdjünk új loopba. Na meg azért is, mert én a szubjektív véleményem le tudom írni a saját oldalamon. Bár ezt meg olyan "az emberek háta mögötti dolognak érzem", de ha szemtől-szembe nem megy, akkor más nem marad... -
pmonitor
aktív tag
válasz
K1nG HuNp
#16949
üzenetére
Ez szted. mi, ha nem alkotás? Ezekről nem is beszélve. De tegyük fel, hogy igazad van, és tényleg nem alkottam semmit. Olyan nagy baj lenne ez egy nem programozótól? Mutasd meg légyszíves, hogy te miket alkottál!
A pénz keresést meg azért hoztam szóba, mert ha vki(k) ebből gazdagodik meg, akkor sztem számon lehet kérni teljesítményt is. Mint ahogy írták:
>Ha fizetsz erte, az mas, akkor szamon kerhetsz teljesitmenytA téma lezárását nem ígérem meg, de azt igen, hogy jelentős önmegtartóztatást próbálok gyakorolni ezzel kapcsolatban. Tehát sokkal ritkábban szólok hozzá ilyenekhez. De ha ilyen butaságot ír valaki, arra ezentúl is rajzolgatok...
-
pmonitor
aktív tag
-
pmonitor
aktív tag
válasz
pmonitor
#16939
üzenetére
Ért 1 meglepetés! Ha Itt az int.TryParse()-k helyett az itt lévő Int_Parse()-t használom, akkor C#-ban jelentősen javul a sebesség(~22-ről ~18 sec-re). Tehát ~1 sec-el gyorsabb a C++-nál(mondjuk ez 60 misi string konvertálásánál nem eget verő különbség, de azért mégis...). Azért azt hozzá kell tenni, hogy a C# kód a File.ReadAllLines() metódussal olvassa be a file-ból az adatokat. Ez azonban nincs benne az időmérésben. Ha ezt is bele számoljuk, akkor máris az jön ki, hogy a C++ set<>-je és a C# HashSet<>-je sebessége majdnem ugyanaz. Viszont nem tudom, hogy a C# string -> szám konvertáló metódusait hogy szúrhatták el ennyire? Még szerencse, hogy ezt azért lehet optimalizálni. Mert pl a szám -> string konvertáló metódusok optimalizálására esély sincs C#-ban.
Majd ha több időm lesz, akkor ezt módosítom a doc_1.php-ben.
------------------------------------------
@martonx:
Azt is mondhatnám, hogy Csak Ön után! Vagy hogy hogy nem tudja 'kend ezt megcsinálni?
Még 2012-ben készítettem egy ilyen minta kódot Vb.Net-ben managed-ben! Mondjuk ez nem HTML Rendering, csak példának hoztam fel. Egyébként a managed kódot elfelejtettem az elő hsz-emben. Tehát C#-ban nem csak a .Net áll a kód mögött, hanem a managed környezet is. Szóval managed-ben is lehet viszonylag gyors kódot írni. Bár itt csalós dolog is van. Sok memóriaszemét van, amíg a GC le nem fut. Ez miatt is látszhat gyorsnak 1 C# kód. Mindenesetre nem én fogom megváltani a világot. Bár azért C-ben az itoa() és az atoi() függvényeket sikerült optimalizálnom. C#-ban csak a Parse() metódust. Sztem. ez is valami. Az, hogy nem vagyok programozó, az azt is jelenti, hogy hogy én meg tudom csinálni azt, hogy csak azzal foglalkozom, amivel szeretnék foglalkozni. A programozó meg azzal foglalkozik, amivel muszáj(mert ugye a muszáj nagy úr
). Ezért hiányolom azt, hogy akik programozóknak mondják magukat, nem hozzák nyilvánosságra, amit alkottak(mert olyan nincs, hogy egy programozó úgy lett programozó, hogy nem alkotott semmit). Cattus azt írta, hogy nem érdekli, hogy én mit várok el. Ezzel nincs is gond. De akkor az ilyenek se várják el, hogy elhiggyem/elhiggyék, hogy programozó. -
pmonitor
aktív tag
Ezeket a kódokat követtem el mostanában. A C# ebben a konkrét esetben elfogadhatóan lassabb a C++ kódnál. C++-ban a set és a pair, míg C#-ban ezek megfelelőjét, a HashSet és a KeyValuePair párost használtam.
Én mostanáig legtöbbet C#-ban programozgattam. C-ben csak a natív .dll-ek készítését végeztem el olyan dolgokhoz, amiket C#-ban nem tudtam megvalósítani. C++-ban szinte nem programozgattam(csak 1 kis "szinten tartás" volt - ujjgyakorlat -). Behatóbban nemrég kezdtem el C/C++-al foglalkozni. Igazából sajnálom, hogy a C++-al eddig nem foglalkoztam eléggé. Gyakorlatilag ugyanazok az adatstruktúrák vannak benne, mint a C#-ban, csak úgy néz ki, hogy gyorsabbak(meg persze nem kell hozzá a robosztus .Net). Meg ha valakinek van kedve, akár optimalizálhatja is ezeket "user programozóként" is. Ha nincs kedve, akkor még mindig elfogadható hatékonysággal dolgozhat benne.
-
pmonitor
aktív tag
Ezen a linken írogattam a futtatható file-ok létrehozásáról C nyelven VS-ben. Egyébként létrehoztam a Linktár-at is. Itt az előbb említett link is elérhető. A "Linktár"-ba kevesebb linket szeretnék tenni, mert terveim szerint oda tényleg csak az általam hasznosnak/érdekesnek vélt dolgok kerülnek be.
-
pmonitor
aktív tag
válasz
dabadab
#16919
üzenetére
Link. Nem ez a lényeg? Én nem klónozni szerettem volna a kódot, hanem hogy lehet-e optimalizálni. És azért határozottan lehet. De érdekes módon pl. azt az oldalt nem fikázzátok, ahonnan az algót vettem. Meg a többi atoi(...)-t és itoa(...)-t hiányosan megvalósító oldalt sem(pedig van egy-pár). Csak a pmonitor-ét(aki én lennék).
-
pmonitor
aktív tag
Megkövetlek. És nem fikázlak.
Ugyanakkor csak legalább ennyit "várnék" el az olyanoktól, aki programozónak állítja be magát. Ugye, hogy nem is volt olyan nehéz ezt megtenni?#16912:
>milyen módon minősíted azt a sok mérnököt aki ezzel foglalkozikMár ha ugyebár mérnökök(ráadásul így többes számban).
-
pmonitor
aktív tag
>Nem vagy szakmabeli és ami itt folyik demagóg
Neked pl. hol vannak a referenciáid? Mert nem vettem észre, hogy vmit. is közzé tettél volna. Én legalább valamiket letettem az asztalra. Hogy értékelhető-e, vagy nem, ahhoz nem tudok hozzászólni, de sokkal több dolgot tettem le az asztalra. Az oldalam gyakorlatilag a "Cutter" nevezetű programom végett hoztam létre. A többi csak úgy jött köré. Elsősorban régebbi programok vannak ott(amiket made in hirtelen csinosítottam). Pont az a bajom, hogy itt bárki mondhatja magát szakmabelinek, anélkül, hogy bármit is letett volna az asztalra(akár értékelhetőt, akár nem). Egyébként, ahogy látom, a programjaim töltögetik "lefelé", és nagyon bízom benne, hogy valaki(k)nek megmozgatják a szürkeállományát, és valami eszükbe jut a programjaim nézegetése közben. Valami ihletet adok Nekik. Ezért hálás köszönetem, azoknak, akik letöltötték/letöltik a programjaimat. Őket légyszíves ne s...d már le, ha megkérhetlek.
-
pmonitor
aktív tag
-
#16888
pmonitor
aktív tag
Netszemete
#16887
pmonitor
aktív tag
válasz
Netszemete
#16887
üzenetére
>a legtöbb feladatnál a sebesség másodlagos, sokadlagos tényező.
Akkor miért is kell erősebb HW-t venni, ha sokadlagos tényező? Akkor miért nem jó a legolcsóbb, lassabb HW, ha sokadlagos tényező?
Sztem. nem sokadlagos. Csak én az alkalmazások optimalizálását emelem ki, a többiek meg a szuper HW-t emlegetik.
-
pmonitor
aktív tag
válasz
martonx
#16885
üzenetére
Elég szomorú, hogy az évtizedek alatt senkinek sem jutott eszébe optimalizálni az alapvető függvényeket/metódusokat sem. Mert az alap típusok konvertálásai alapvetőek(legalábbis sztem.). Mondjuk itt valszeg. a sok függvényhívás is közrejátszik pl. a C "relative" lassúságában.
A másik meg az, hogy ez biztos, hogy egy user programozgatónak a dolga lenne? Ha van egy autóm, amiben nekem nem tetszik valami, akkor tervezzem át, küldjem be a gyártónak, és várjak, hogy elfogadják-e, mi?
-------------------------
Ettől függetlenül nem árt, ha valaki megpróbálja megérteni az általa használt függvények/metódusok működését/algoritmusát. Főleg, ha ugyanazt a funkciót gyorsabban is meg tudja valósítani.
-------------------------
Ha most lennék fiatal, és programozó szeretnék lenni, akkor én 2, esetleg 3 programnyelvet sajátítanék el nagyon. Az asm-ot, a C-t, esetleg a "mezei" C++-t(nem a VC++-t). Ezekkel mindent meg lehet csinálni, és eszközt adnak a kezembe az optimalizálásra is. -
#16880
pmonitor
aktív tag
Netszemete
#16877
pmonitor
aktív tag
válasz
Netszemete
#16877
üzenetére
>de én úgy érzem, hogy ez pont az extrém esetekről szóló téma.
Igen, az. Bár ha belegondolunk mennyi szám konvertálás történik csak ebben a kis országban is, akkor lehet, hogy kiderülne, hogy még a nem szélsőséges helyzetben is lenne létjogosultsága az optimalizálásnak. Amennyivel kevesebbet kellene használni a vasakat, az elég nagy energiamegtakarítást is jelentene sztem.
>Épeszű(!) programozó nem kezdi újraírni a glibc-t,
Ha rám gondoltál, én nem vagyok programozó. de ez a könyv is tele van az STL megvalósítás kezdeményekkel. Mondjuk az egész elég sok rizsát tartalmaz. Én mondjuk megbántam, hogy megvettem annak idején. Nem regényt szerettem volna olvasni. De most már mind1.
-
pmonitor
aktív tag
Akkor sorry...
De mennyien használnak olyan programot, ami IP címeket jelenít meg? Vagy pl. a tőzsdéken hányszor és mennyi számot kell konvertálni a valuta árfolyamoknál? Vagy akár az áru tőzsdéken? Vagy amikor a banki számlakivonatokat küldik ki? Meg amilyen felhasználásra az ember még csak nem is gondol.. -
pmonitor
aktív tag
Ezt elsősorban azért írtam, hogy pl. a C#-ban vannak olyan metódusok, amik hiába lassúak, nincs mód rá optimalizálni. Eszed/nem eszed, nem kapsz mást. Tehát itt most nem a konkrét metódus volt a lényeg. De a "sima/mezei"
ToString()metódus is ilyen lassú.
De ha jól tévedek, akkor pl. az IP címeket is konvertálják oda-vissza a feldolgozás során(a router-ek és egyebek). Na most ha jól tudtam ezt, akkor elég csak abba bele gondolni, hogy akár csak 1 óra alatt is mennyi IP cím kering a hálózatokon. Ha rosszul tudtam, akkor sorry. -
pmonitor
aktív tag
válasz
martonx
#16854
üzenetére
>mert nem atoi-t optimalizálok hehehe).
Azért próbáld optimalizálni a C# Convert.Tostring(int value, int tobase) metódusát. Ha megszakadsz sem tudod jelentősen optimalizálni, mert a C#(és mögötte a robosztus .Net) nem ad megfelelő eszközt a kezedbe.
Pedig lehetne rajt mit optimalizálni, mert a C itoa(...) függvénye ~21 sec alatt megoldja, amit a C# említett metódusa ~51 sec alatt. És C-ben még van eszközöd optimalizálni, mert le lehet vinni 10 sec. alá a futásidőt. -
pmonitor
aktív tag
Itt sztanozs nagyon jól összefoglalta a programozók általános álláspontját. Amivel nem tudok egyetérteni. Hosszabb futásidő -> több energiafogyasztás. Főleg (alkalmazás/web)szerveren.
Valóban nem tudom a leggyorsabb kódomat, hogy jól is és hibamentesen is működik. Kovisoft(aki egyébként az egyetlen konstruktív/kritikus hozzászóló volt - ezúton is köszönöm Neki) sem tudta bizonyítani az ellenkezőjét. De tettem konkrét lépést a bizonyítás felé. 200000000000-ig biztosan detektál minden túlcsordulást -> ez azért nem kis dolog. De tegyük fel, hogy ez az algó nem működik. Ez az algó biztosan működik(hiszen ha egy számot szorzunk, akkor az eredményt visszaosztva ugyanazt a számot kell visszakapnunk), és ez is gyorsabb a beépített függvénynél. Legalábbis C-ben. Mert mint írtam, a "rajzom" még nincs teljesen kész(pl. ezt C#-ban még nem próbáltam). De kovisoft valós hibákat/bug-okat írt(a legutolsó hsz-e kivételével), Veled ellentétben. Én is "rizsázom", de ezzel párhuzamosan azért valamit próbálok megcsinálni is.
Egyébként még a programozók sem értenek egyet még a stringet int-re konvertáló függvény szignatúrájában sem. C-ben ha túlcsordulás van, akkor az int-et INT_MIN/INT_MAX értékére állítja be(vagy meghatározatlan értéket ad vissza). C#-ban 0-t ír bele, és false-ot ad vissza. Sztem ez utóbbi jobb, mert a 0-nak "általában" invalid értelme van(darabszám/pénz/akármicsoda esetén). De mondjuk a programozóknak kellene "dűlőre" jutni ilyen témákban.@martonx, @Silεncε: A fejlesztők úgyis elkergetnének, hiszen a programozókat nem érdekli a sebesség, és a méret/helypazarlás(lásd az elején belinkelt sztanozs hozzászólást -- is).
-
pmonitor
aktív tag
válasz
janos1988
#16769
üzenetére
Sosem értettem a programozókat. Bármekkora tárhely áll rendelkezésre, azt hiszik, hogy azt mind meg kell tölteni... Egyébként meg sztem. nagyon sok ismétlődő függvény/metódus lehet azokban a hatalmas kódokban.
Miközben meg pl. én(egy 1-szerű hobbi programozgató), tudok olyan kódot írni a "beépített" függvényeivel szemben, ami legfeljebb fele annyi idő alatt lefut, mint a beépített. Éppen most készítem ezt a dolgot(még nincs teljesen kész). De az látszik, hogy a stringet számmá konvertáló beépített függvények C-ben ~19, míg C#-ban ~68 sec. alatt futnak le, miközben könnyedén lehet ~10 sec. körüli futásidőt elérni ugyanarra a feladatra(inputra).
Dehát ez az én külön bejáratú véleményem... -
pmonitor
aktív tag
válasz
kovisoft
#16741
üzenetére
>Ha megszorozzuk a 999999999-et 10-zel, az túlcsordul
Ha 10-el való szorzásnál túlcsordul, akkor szorozzuk először 5-el, majd 2-vel
![;]](//cdn.rios.hu/dl/s/v1.gif)
Minden szorzás után meg ellenőrizzük a túlcsordulást. Itt módosítottam is. Csak abban nem vagyok biztos, hogy a rész szorzások után is be kell-e tenni a "tempret"-be a "ret" értékét? Sztem. talán nem szükséges. -
pmonitor
aktív tag
válasz
kovisoft
#16736
üzenetére
Igen, észleltem én is a bugot(?). Módosítottam a C kódomat:
if (ret < 0 || ret < tempret)És mindig elmentem a tempret-be a ret értékét. Így már sokkal több számra működik.
>Persze most megint visszatérhetünk oda, hogy az atoi() mit is kell visszaadjon invalid inputra.
Nagyon jól látod a problémát! Biztos, hogy jó az, hogy INT_MAX, vagy INT_MIN értékét adja vissza a túlcsordulásnál? Ha jól belegondolunk, akkor ez is memóriaszemét. Viszont valid számok esetén jóval gyorsabb ez a kód, mint az eredeti atoi().
-
pmonitor
aktív tag
Mégiscsak zseni vagyok!
A humort félretéve, találtam ezt az oldalt. Átírtam C beépített assemblerbe. Száguldott az atoi(...)-hoz képest. Csak az a baj volt vele, hogy a túl kicsi, vagy túl nagy számok esetén memóriaszemetet írt ki. Átalakítottam a kódot, valamint C-ben is implementáltam. Ezek a kódok még alsóhangon is fele annyi idő alatt végeznek, mint az atoi(...). Itt vannak az új kódok. Azért sasoljátok, de sztem. ez jó.mobal #16722:
>Vergődhetünk még itt de az atoi implementációnál 99%, hogy nem csinálsz jobbat. És ez itt mindenkire is vonatkozik nem csak rád.Mégiscsak lehet sokkal jobb kódot írni, mint az atoi.
-
#16729
pmonitor
aktív tag
Netszemete
#16728
pmonitor
aktív tag
válasz
Netszemete
#16728
üzenetére
>Előfordulhat sokszor, hogy csak részfukcionalitás szükséges, és azt lényegesen gyorsabbra sikerül megírni
Én pontosan így jártam az strcmp()-vel. Nekem csak a nagyobb-e kellett volna. Ezért ezt külön írtam meg isstrgreat(...) függvénnyel.
Na meg a patoi(...) inicializálásához vezettem be egy ilyen függvényt, hogy ne kelljen ciklusonként csinálni. Meg egy olyan "trükköt" vetettem be, hogy a paraméterként átadott char* tömbben egy értéket átmenetileg megváltoztatom, majd vissza írom az eredetire.
Szóval sok mindennel lehet optimalizálni. De jó, ha az ember "tarsolyában" van 1-2 algoritmus/függvény. Ezért is írtam egyszer, hogy a C-ben lassabban megy a programozás, de aki erre szakosodott, Neki is gondolom vannak konyhakész kódjai. Ezért mégsem olyan lassú(még akkor sem, ha esetleg módosítani kell valamelyiken). -
pmonitor
aktív tag
Ebben a .c file-ban helyeztem el a(z úgy néz ki, hogy) a végleges programot. A patoi(...) függvény elvileg már ugyanarra az inputra ugyanazt az outputot adja, mint az atoi(...). Stabilan, de ugyanakkor mindig csak kevéssel gyorsabb az atoi()-nál.
@kovisoft: Köszönöm szépen a konstruktív kritikákat. Nagyon sokat segítettél.
-
pmonitor
aktív tag
De az itoa(...) esetén sikerült ~ harmadára csökkentenem a futási időt(még úgy is, hogy + funkciót tettem bele).
Mondjuk tény, hogy az atoi(..)-t többször kell használni, mint az itoa(..)-t. Ezért érthető, hogy erre sokkal jobban odafigyeltek a fejlesztők. De jobb kódot biztos, hogy nem egyszerű csinálni. Csak ki tudja, hogy az STL melyikből tartalmaz többet: olyan lassúból, mint az itoa(), vagy olyan gyorsból, mint az atoi()? Ezt ki tudja megmondani? Arról nem is beszélve, hogy én csak win-en VS-ben teszteltem ezt a 2 függvényt is.
-
pmonitor
aktív tag
Igaz.
De azért implementálni tudtam az ugyanakkora sebességet, mint az atoi(...). A kovisoft által felsorolt hibák:
1.: általánosságban nem csökkentik a sebességét a kódomnak
2.: a kódom végén található if-ekkel, és az azokban lévő tartalom módosításával orvosolhatók. Ezek csak igen speciális esetekben lassítják a kódom. INT_MIN, kisebb, mint INT_MIN, INT_MAX, nagyobb, mint INT_MAX. Tehát nem sok ilyen eset van.De aki megérti a működési elvet, Ő már tudja, hogy miért szoktam mondani, hogy "81236" == "000081236"-al, ha számokról beszélünk.
-
pmonitor
aktív tag
válasz
kovisoft
#16716
üzenetére
Azt hiszem, hogy sikerült mind a 2 pontodat kiküszöbölnöm:
int patoi(const char* str)
{
char* temp = 0, neg = 0;
int i;
while (isspace(*str)) str++;
if (*str == '-')
{
str++;
neg = 1;
}
else if (*str == '+') str++;
while (*str == '0') str++;
temp = str;
while (*temp)
{
if (!(*temp >= '0' && *temp <= '9')) break;
temp++;
}
temp--;
i = 1;
int ret = 0;
for (; temp >= str; temp--)
{
if (*temp >= '0' && *temp <= '9')
{
ret += ((*temp - '0') * i);
}
else break;
i *= 10;
}
if (ret < 0 && !neg) ret = INT_MAX;
else if (neg)
{
if (ret == INT_MAX)
{
char arr[11];
strncpy(arr, str, 10);
arr[10] = '\0';
if (!strcmp(arr, "2147483647")) ret = INT_MIN + 1;
else ret = INT_MIN;
}
else ret *= -1;
}
return ret;
}A futásidő kb. ugyanaz, mint az atoi(..)-nek. Általában kicsit gyorsabb. Mégsem lettem zseni.
De azért nézzétek át légyszi, hogy ebben találsz-e hibát. -
pmonitor
aktív tag
válasz
kovisoft
#16716
üzenetére
Szomorú vagyok.
Az 1. pontoddal még nem tudtam mit kezdeni. A 2. pontoddal igen, úgy, hogy a végén printf(...)-el kiírattam val értékét. Módosítással most kb. azonos időben futnak le(az enyém határozottan gyorsabb). Jelenleg ez a függvényem:
int patoi(const char* str)
{
char* temp = 0, neg = 0;
int i;
while (isspace(*str)) str++;
if (*str == '-')
{
str++;
neg = 1;
}
else if (*str == '+') str++;
while (*str == '0') str++;
temp = str;
while (*temp)
{
if (!(*temp >= '0' && *temp <= '9')) break;
temp++;
}
temp--;
i = 1;
int ret = 0;
for (; temp >= str; temp--)
{
if (*temp >= '0' && *temp <= '9')
{
ret += ((*temp - '0') * i);
}
else break;
i *= 10;
}
if (neg) ret *= -1;
return ret;
} -
pmonitor
aktív tag
Van ez a kód:
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>
#include <sys/timeb.h>
long timediff(struct timeb* start, struct timeb* end)
{
long seconds;
seconds = (long)(end->time - start->time);
start->millitm = end->millitm - start->millitm;
if (0 > start->millitm) {
start->millitm += 1000;
seconds--;
}
return seconds;
}
int patoi(const char* str)
{
char* temp = 0, neg = 0;
int i;
while (isspace(*str)) str++;
if (*str == '-')
{
str++;
neg = 1;
}
else if (*str == '+') str++;
while (*str == '0') str++;
temp = str;
while (*temp)
{
if (!(*temp >= '0' && *temp <= '9')) break;
temp++;
}
temp--;
i = pow(10, temp - str);
int ret = 0;
for (; temp >= str; str++)
{
if (*str >= '0' && *str <= '9')
{
ret += ((*str - '0') * i);
}
else break;
i /= 10;
}
if (neg) ret *= -1;
return ret;
}
int main()
{
char str[] = "+16258156";
int val = 0, db = 0;
struct timeb start, end;
long seconds, seconds2;
int militm, militm2;
size_t i = 0;
ftime(&start);
for (i = 0; i < 1000000000; i++)
{
val = atoi(str);
//printf("%d\n", val);
//break;
}
ftime(&end);
seconds = timediff(&start, &end);
militm = start.millitm;
ftime(&start);
for (i = 0; i < 1000000000; i++)
{
val = patoi(str);
//printf("%d\n", val);
//break;
}
ftime(&end);
seconds2 = timediff(&start, &end);
militm2 = start.millitm;
printf("Eltelt ido: %ld.%03d masodperc\n", seconds, militm);
printf("Eltelt ido: %ld.%03d masodperc\n", seconds2, militm2);
return 0;
}Itt az atoi(...) stabilan 18 sec. körül, az általam készített patoi(...) stabilan 3 sec. alatt fut le. Létezik ez? Ha igen, akkor benéztem valamit? Ahogy néztem, azonos inputra azonos kimenetet ad. Vagy én lennék ilyen zseni??
-
pmonitor
aktív tag
válasz
pmonitor
#16670
üzenetére
>az itoa()-nak a visszatérési értéke lehetne olyan mutató, ami a karakterláncot lezáró '\0' karakter utánra mutat.
Ezt itt meg is valósítottam. A függvény hívása/használata:
int main()
{
char str[128]; //arra figyelni kell, hogy elegendő helyet foglaljunk le
char *str_1 = pitoa(-2138, str, 10); //itt str_1 az str[6]-ra mutat(ha jól számolok)
char *str_2= pitoa(21526, str_1, 10);
char* str_3 = pitoa(568712, str_2, 10);
printf("%s\n%s\n%s\n", str, str_1, str_2);
return 0;
}Sztem. hasznos egy ilyen funkció.
-
#16670
pmonitor
aktív tag
böng ész ő
#16665
pmonitor
aktív tag
válasz
böng ész ő
#16665
üzenetére
Sztem. ilyen nincs. A stackoverflow-n vannak néha jó dolgok, de ebben sem lehet megbízni. Ami még jobban bosszant, hogy a könyv(ek)-ben sem lehet megbízni. Gyakorlatilag nincs 1 hiteles forrás nemhogy magyarul, de még angolul sem. Ha elakadsz valamiben, akkor:
1.: a probléma átgondolása(gondolkodás)
2.: google, könyv, jegyzet
3.: az adott témában gyakorlás, gondolkodás, gyakorlás...
4.: ha ezek nem vezetnek eredményre, akkor vissza az 1. pontra.Nézd meg. Én itt jó pár témáról 'rajzolgattam, de mindenki csak az utolsó mondatomra reagált. Pl. arra, hogy ezt hogy lehet C-ben megoldani, arra senki sem:
push_chars :
xor edx, edx
mov ecx, base
div ecx
add edx, 0x30
push edx
inc ebx
test eax, eax
jnz push_chars
pop_chars :
pop eax
stosb
dec ebx
cmp ebx, 0
jg pop_charsDe ebben a hozzászólásomban a kezdő témámra sem reagált senki.
--------------------------------------------
Itt a függvény szignatúrákról jutott eszembe, hogy pl. az itoa()-nak a visszatérési értéke lehetne olyan mutató, ami a karakterláncot lezáró '\0' karakter utánra mutat. strcat() esetén meg a karakterláncot lezáró '\0'-ra. Sztem ez is hasznos dolog lenne/lehetne...
-
pmonitor
aktív tag
válasz
sztanozs
#16528
üzenetére
Készítettem én is egy 300000-es futtatást olyan szisztémával, mint ahogy Te csináltad. Tehát hogy az "A" program írta file-ba az adatokat. Ez lett az output. Nálam mondjuk mások az egyedi adatok:
Egyedi PID: 241955
Egyedi HWND: 286085
a 300000-ből.
Olyan eset nem volt, hogy mindkettő megegyezett volna. A program leírása itt található meg.@Silεncε:
Ugye milyen jó, hogy nem fogadtál?
Az itoa() szignatúrája:char * itoa ( int value, char * str, int base );Az én függvényem szignatúrája:
char* int_ToStringC(int i, char* s, int base)
Nincs többfajta input.@sztanozs:
Pl. ilyen teszt programok esetén is elég so'xor kell integert konvertálni. Ahányszor meghívom a PidAndHwndA.exe-t, mindannyiszor 2 számot konvertál(a pid-et és a hwnd-t).
Vagy másik példa a feledatkezelő. Ott is nagyon so'xor kell számot konvertálni. Mondjuk egyik esetben sem kell 30 misiszer konvertálni, de azért látszik, hogy akad 1-2 eset, amikor jó sokszor.@dabadab:
Ugye, hogy nem veri meg ezt az assembly kódot!?@dabadab:
Itt azt írtad, hogy:
>A C az gyakorlatilag hordozható assembler, ennek megfelelően kell hozzáállni, aki ott azt mondaná, hogy a JMP használatát el kell kerülni, azt kiröhögnék.Szerintem a C nem hordozható assembler. Közel sem!!! Ilyent hogy írsz meg C-ben?
push_chars :
xor edx, edx
mov ecx, base
div ecx
add edx, 0x30
push edx
inc ebx
test eax, eax
jnz push_chars
pop_chars :
pop eax
stosb
dec ebx
cmp ebx, 0
jg pop_charsEzt én úgy írtam meg, hogy char tömböt használtam, és a végén "megfordítottam". De ez a megoldás nagyon nem ugyanaz, mint az asm esetén használt push-ok és pop-ok használata. A C közel sem hordozható assembler!
@böng ész ő:
>Ha elakadsz valamivel
Egy programozó is el tud akadni valamivel? Én azt hittem, hogy azért tanultak olyan sokat, hogy a szakterületükön ne akadjanak el semmivel. De lehet, hogy tévedek/tévedtem.
-
pmonitor
aktív tag
A Cutter_1.0.0.1 program funkcióját bővítettem. Mostantól ha leállítjuk a keresést, akkor is kiírja az addigi legjobb eredményt a középső szövegmezőbe(ezt eddig nem tette). Ezzel már használható úgy is, hogy egy nagy számot állítunk be a "Próbák száma" részben, és akkor állítjuk le a keresést, amikor csak akarjuk.
-
pmonitor
aktív tag
-
pmonitor
aktív tag
válasz
sztanozs
#16612
üzenetére
>a felhasználói programok nagy részében a műveletek végrehajtási idejének nagy részét az IO-ra való várakozás tölti ki, nem a kalkuláció.
Van a következő kód:
#include <stdio.h>
#include <Windows.h>
#include <time.h>
#include <sys/timeb.h>
long timediff(struct timeb* start, struct timeb* end)
{
long seconds;
seconds = (long)(end->time - start->time);
start->millitm = end->millitm - start->millitm;
if (0 > start->millitm) {
start->millitm += 1000;
seconds--;
}
return seconds;
}
int main()
{
struct timeb start, end;
long seconds, seconds_1, seconds_2;
int militm, militm_1, militm_2;
int i, j;
char ch[] = "abcdefghijklmnopqrstuvvxywz";
DWORD sizewrit;
BOOL ret;
ftime(&start);
for (i = 0; i < 10000; i++)
{
FILE* fp = fopen("d:\\b.txt", "w");
for (j = 0; j < 100; j++)
{
fwrite(ch, sizeof(ch[0]), 27, fp);
}
fclose(fp);
remove("d:\\b.txt");
}
ftime(&end);
seconds = timediff(&start, &end);
militm = start.millitm;
ftime(&start);
for (i = 0; i < 10000; i++)
{
HANDLE FileH = CreateFileA("d:\\a.txt", GENERIC_WRITE, 0, 0, CREATE_NEW, FILE_ATTRIBUTE_ARCHIVE, 0);
for (j = 0; j < 100; j++)
{
WriteFile(FileH, ch, 27, &sizewrit, 0);
}
CloseHandle(FileH);
DeleteFileA("d:\\a.txt");
}
ftime(&end);
seconds_1 = timediff(&start, &end);
militm_1 = start.millitm;
printf("Eltelt ido(fwrite()): %ld.%03d masodperc\n", seconds, militm);
printf("Eltelt ido(CreateFileA()): %ld.%03d masodperc\n", seconds_1, militm_1);
return 0;
}Itt pl. a C library jelentősen gyorsabb, mint a win api hívások. Pedig mindegyik a HW-n végez műveleteket. Az állításod szerint elvileg mindegy lenne, hogy melyik algó a gyorsabb/lassabb. De itt nem így van. Pedig a disk sebessége ugyanaz. A C függvények mégis "folyékonyabban beszélik a nyelvét".
Mostanában a szabadidőmben elég sokat foglalkoztam a sebességgel. Arra jutottam, hogy egyáltalán nem lehet általánosságban kategorikusan kijelenteni vmit. Ha csak a C-t, és a library-t nézzük, akkor sem. Az egyiknél jelentősen gyorsabb, mint egy egyedi implementáció, másik esetben meg fordítva van. Ki tudja megmondani, hogy melyik van többségben?
@Ispy #16621:
Azért a játéknál többet érnek ezek a példák. Én pl. sokat tanultam belőlük. Talán a legfontosabb, hogy a mostanra majdnem NULL ASM tudásomat frissítettem. Ez önmagában is elég lenne. Ezen kívül megtudtam, hogy a C library-ban is vannak nagyon lassú megvalósítások(bár hogy mennyi, azt nem tudom) is. És még sok mindent...
Ráadásul több esetben megtudtam, hogy bizonyos esetben melyik a hatékonyabb. Ezeket sztem. nem felejtem el, ugyanakkor "elmentettem". Így ha valamikor a hatékonyabb algóra van szükség, akkor elő tudom venni a tarsolyomból. Szóval számos gyakorlatban használható eredménye is volt.@sztanozs #16625:
Kimondottan C területről nem tudok. De pl. a(z) (alkalmazás) szervereken elég sok számot kell konvertálni. És egy sűrün látogatott oldalon ez sokat jelenthet. -
pmonitor
aktív tag
válasz
sztanozs
#16618
üzenetére
Kb. 30-40 milliószor. De azt sem szabad figyelmen kívül hagyni, hogy ha több ilyen alacsony hatékonyságú függvény van az STL-ben, azok természetesen összeadódnak. Még szerencse, hogy a legnagyobb különbség a bináris számrendszerben van. Ott az itoa() 200!!!, míg az int_ToStringC() 25 sec. körül végez(8-ad része alatt). Ez azért szerencse, mert a bináris formátumot ritkán kell tömegesen használni. Azért azt senki nem mondhatja, hogy a 200, és a 25 másodperc között jelentéktelen a különbség.
Ki tudja mennyi ilyen függvény van az STL-ben, és nagyságrendi különbség van-e egy programozó implementációjával szemben? Egy példa:
A FindFile.exe(C#), és a FindFileC.exe(C) programom is rekurzióval hívom meg, de úgy, hogy egyszerre csak 1 findfirstfile()-al megnyitott handle van. Ez jóval gyorsabb, mint a "szokásos" rekurzió, amelyben sokkal több handle van egyszerre nyitva. Viszont a módszerem hátránya, hogy memóriazabáló(de hát valamit valamiért). -
pmonitor
aktív tag
válasz
pmonitor
#16614
üzenetére
Viszont most megnéztem winen a Code:: Blocks+Mingw kombóval. Itt meg az itoa() minimálisan gyorsabb(de ugyanazzal a kóddal mindegyik 15 és 19 sec. között fut le). Ez azonban a VS középértékének felel meg. A fordítótól is nagyon sokat függ.
@martonx:
Igazából a sebesség akkor számít, ha valamit ciklusban és sokszor hívunk(addig nem érdekes). De sztem. az elég sokszor előfordul, hogy tömegesen kell számokat szövegre konvertálni. -
pmonitor
aktív tag
Köszi a forrás útvonalát.
Az lehet, hogy a stabilitásra optimalizálják a library-kat, de a sebességgel ennyire nem foglalkoznak!? Mert itt nem 1-2 %-ról beszélek. Az adott kód futásideje nagyságrendileg egyharmadára csökken(illetve lehet csökkenteni). Ez sztem. nem nagyon fér bele abba, hogy "lehetőleg jó sebességgel tegyék".
>Te nyújtottál egy implementációt x86-ra
Sztem félreértetted. Amelyik hozzászólásomra válaszoltál, az már nem az általam assemblyben írt kódról szólt. Ez már arról szólt, hogy C-ben könnyen lehet jelentősen gyorsabb kódot írni pl. az itoa() esetében. A C kód meg minden támogatott architektúrán és rendszeren jó. Az zavarhatott meg, hogy az elején az általam asm-ben írt kódról volt szó.
De mind1. Már ezt is tudom, hogy a C library függvényei sem a sebességükről híresek. Ez van.
-
pmonitor
aktív tag
válasz
kovisoft
#16602
üzenetére
Módosítottam itt a mintakódokat, valamint bemásoltam azok eredményeit. Csak azt nem értem, hogy a standard könyvtárbeli itoa() függvénye miért ennyire lassú. Pedig ezt is programozó(k) készített(e/ék). Azt én már biztosnak veszem, hogy sebesség szempontjából minden nyelvben az alkalmazott algoritmusnak van nagy jelentősége. Ha az algoritmus jó, akkor már csak kevésbé lehet optimalizálni. Legalábbis, ha a nagyságrendet nézzük.
De egyébként úgy látom, hogy Rád lehet hallgatni. Nagyot nem tévedsz. -
pmonitor
aktív tag
válasz
kovisoft
#16602
üzenetére
Értem amit írsz, és igazad van, C-re visszafordítva sokkal gyorsabb. Bár még csak a 10-es számrendszert tudja. De aki otthon van az ASM programozásban, lehet, hogy a C kódnál is tud még gyorsabb kódot írni ASM-ben.
De azt is figyelembe kellene venni, hogy ha van egy itoa() függvény, akkor miért kell a user-nek(mármint a programozónak) újra implementálnia, hogy az itoa()(vagy mondhatnám bármelyik függvényt) idejét 100%-nak nézve kb. 30% alatt fusson le?
És ugyanezt mondhatnám bármelyik nyelvre is. Hogy csak a C#-ot emeljem ki. Ott is csak úgy lehet gyors kódot írni, ha:
1.: Az ember teljesen felrúgja az OOP alapelveit(tehát áttér a C stílusú kódolásra)
2.: Unsafe kódot használ.
3.: Ha nem algoritmusos/matematikai probléma, akkor áttér a win api használatára.Nem tudom, hogy érted-e, hogy mi a mondanivalóm lényege. Ha megvalósítottak vmit. az adott programnyelven, akkor miért kódolja le a user még egyszer ugyanazt, hogy jelentősen gyorsabb legyen?
-
pmonitor
aktív tag
válasz
pmonitor
#16585
üzenetére
Az ittenke lévő kódom már tudja a bináris, oktális, és a hexadecimális számrendszer kiírását is. Ugyanakkor még így is jóval gyorsabb, mint az itoa(...)
Hát hiába, az ASM nem hazudik! Főleg, ha egy olyan tud hatékonyabb kódot írni az enyémnél, aki keni-vágja a témát. Mert nekem össze kellett szednem magam, hogy ezt kiizzadjam magamból.
-
pmonitor
aktív tag
A ciklus módosításával:
for (i = 0; i < 1000000000; i++)
{
//sprintf(str, "%d", -2138);
itoa(-2138, str, 10);
//printf(str);
}Itt egy 0-t tettem a végére, úgyhogy azt a másik ciklusba is oda kell tenni. Így az itoa() kb. 22 sec., az int_ToString() kb. 14 sec. alatt fut le. Ez már lényegesen jobb, de azért egyértelműen gyorsabb ennél is az asm.
@dabadab:
>mondjuk lehet, hogy azért így is megverné ezt az assembly kódotNem haragszom meg, ha csinálsz jobb asm kódot.
-
pmonitor
aktív tag
válasz
Silεncε
#16576
üzenetére
Idézet Innen:
Nem azt mondom, hogy lehetetlen gyorsabb assembly kódot írni, mint amit egy C fordító gyárt, csak azt, hogy nagyon nehéz, és az is csak valamivel lesz gyorsabb, de messze nem a "min. 15 éves gépeken is pont úgy menne egy mai/2021-es játék, mint a mai erőműveken" kategória lesz.
-
#16575
pmonitor
aktív tag
Fire/SOUL/CD
#16427
pmonitor
aktív tag
válasz
Fire/SOUL/CD
#16427
üzenetére
Még azt mondják, hogy nem lehet assemblyvel gyorsabb kódot írni! Az olyanoknak ajánlom ezt a példakódot a figyelmébe:
#pragma once
#define _CRT_SECURE_NO_WARNINGS
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <sys/timeb.h>
int int_ToString(int num, char* dest);
char str[12];
long timediff(struct timeb* start, struct timeb* end)
{
long seconds;
seconds = (long)(end->time - start->time);
start->millitm = end->millitm - start->millitm;
if (0 > start->millitm) {
start->millitm += 1000;
seconds--;
}
return seconds;
}
int main(void)
{
struct timeb start, end;
long seconds, seconds_1;
int militm, militm_1;
int i;
ftime(&start);
for (i = 0; i < 100000000; i++)
{
sprintf(str, "%d", -2138);
//printf(str);
}
ftime(&end);
seconds = timediff(&start, &end);
militm = start.millitm;
ftime(&start);
for (i = 0; i < 100000000; i++)
{
int_ToString(-2138, str);
//printf(str);
}
ftime(&end);
seconds_1 = timediff(&start, &end);
militm_1 = start.millitm;
printf("Eltelt ido(sprintf()): %ld.%03d masodperc\n", seconds, militm);
printf("Eltelt ido(assembly): %ld.%03d masodperc\n", seconds_1, militm_1);
}
int int_ToString(int num, char* dest)
{
__asm
{
mov edi, dest
mov eax, num
xor edx, edx
cmp eax, edx
jge nemnegativ
mov ecx, -1
imul ecx
push eax
mov eax, '-'
stosb
pop eax
nemnegativ :
xor ebx, ebx
push_chars :
xor edx, edx
mov ecx, 10
div ecx
add edx, 0x30
push edx
inc ebx
test eax, eax
jnz push_chars
pop_chars :
pop eax
stosb
dec ebx
cmp ebx, 0
jg pop_chars
mov eax, 0x0a
stosb
}
}Nálam itt az sprintf(...) stabilan 6 sec felett, az assembly kód stabilan 2 sec. alatt teljesített. Csupán kevesebb, mint az egyharmada alatt fut le az ASM kód.
-
-
pmonitor
aktív tag
>A fejlesztőeszköz munkaeszköz
Mondjuk ezért nem értem pontosan, hogy ez miért off téma?>Az a fejlesztő, aki HDD-re telepíti a
Ez elírás volt. Bocsi. De a disk I/O így is a szűk keresztmetszet a RAM-al szemben.
Az én vasam egyébként 2019-ben volt a felső kategória alsó határán(nem mintha ez valamit is jelentene). De sosem voltam híve az erőforrás pazarlásnak. Talán ezért zavar engem ennyire.@Ispy #16568: nekem 250 giga partíció van a rendszernek, és ennek kb. a 35%-át használom.
-
pmonitor
aktív tag
válasz
fatal`
#16564
üzenetére
A mobilos példád igaz. De egy mobilba is soknak tartom az app-ok helyfoglalását. Éppen nemrég kérdezte tőlem egy idős néni, hogy az akcióban pár ezerért kapható 8 gigás tárhellyel rendelkező okostelót érdemes-e megvennie, mert Ő csak arra szeretné használni, hogy a tesco-ban az akciókat megnézze rajt. Mondtam Neki, hogy az sztem. nagyon kevés tárhely, mert az alkalmazások túl nagy helyet foglalnak.
De olyan aspektusa is van a dolognak, hogy hiába lett gyorsabb a HW, azért még mindig az a legszűkebb keresztmetszet. Így viszont hiába van 1 terrás HDD, azt mégsem lehet csak a VS-nek elfoglalnia. Méghozzá azért, mert így is egy közepes erősségű vason is nagyon lassan indul(főleg, ha töredezett a meghajtó).@dabadab: Gondolom azért, mert kevés komponenst telepítettél. Azért írtam, hogy alsóhangon 5-6 giga. 1-2 gigát tévedtem.
-
pmonitor
aktív tag
válasz
pmonitor
#16458
üzenetére
A FindFileC.exe programot frissítettem, valamint a forrása is megtalálható a .rar fájlban. A forráson még bőven lenne mit csiszolni, de működőképes. Ha valaki működést érintő bug-ot talál benne, akkor megköszönném, ha jelezné. Tényleg jó lenne, ha lenne egy ilyen win32-es topik, ami csak ilyenekkel foglalkozna. De ahhoz az kellene, hogy lenne több olyan, aki keni-vágja ezt a témát. Még az is lehet, hogy én is kérdeznék
Pl. hogy miért nem működik az sprintf(...) win32-ben? "Error LNK2001 unresolved external symbol __imp____stdio_common_vsprintf" hibaüzit ad. Mindenesetre suszter módszerrel megoldottam a helyettesítését a FindFileC-ben. ------------------------------------------------------------------------
Egy másik téma egy olyan témakörből, ami lehet, hogy többször előjön nálam, mert engem eléggé irritál a(z) (erőforrás)pazarlás. Szóval a régi szép időben az IDE megvolt pár megából. Most a VS alsóhangon is 5-6 giga, de inkább 10-nél kezdődik(régebben egy egész winchi volt 2 giga körül!). Hová jutunk, ha ez a "fejlődés" így megy tovább? Az oké, hogy a VS többet tud, de azért mégis...
-
pmonitor
aktív tag
válasz
pmonitor
#16549
üzenetére
Ezt nagyon benéztem. Egy következtetésem volt jó: Ki érti ezt'et?
Mert az igaz, hogy gyakorlatilag ahány alkalmazás, annyiféle eredmény. De a részletekbe belebonyolódtam. 1.: C#-ban find(first/next)file-t használva.
2: C-ben find(first/next)file-t használva.
3.: TC-benHa a C:\windows\system32-t listázom ki, akkor a 2. esetben az "aadcloudap.dll"-t nem találja meg. Az 1. és a 3. esetben megtalálja.
Viszont ha ugyanezt a mappát almappákkal listázom ki, akkor az 1. és a 3. eset is eltérő eredményt ad(a TC több mappát/file-t talál a C#-nál).
De a különbségek nálam csak a c: rendszermeghajtón jönnek ki. Pl. a D:\ meghajtó teljes listázásánál mindegyik ugyanazt az eredményt adja(persze a D: meghajtón nincsenek "különleges attribútumú" mappák/állományok.)
A különleges attribútumú mappák/állományok listázása esetén talán a TC találja meg a legtöbbet. Utána a C#, majd a végén a C.Szóval az összevisszaság megvan. De azért az előző hsz-emben lévő hamis kijelentésemért elnézést kérek.
-
pmonitor
aktív tag
Egy érdekesség.
Állomány listázásáról van szó. Azon belül is 3 esetről:1.: C-ben(VS-ben), ha a következő beállítást használom:
Project jobb klikk -> Properties -> Configuration Properties -> Advanced -> Character Set
Itt "Use Unicode Character Set" beállítás mellett FindFirstFileW-t használva.
2.: C-ben(VS-ben) az előző helyen "Not Set" beállítás mellett FindFirstFileA-t használva
3.: TC-ben.Ezek közül mindegyik állomány listázásnak más az eredménye. Ja, és a parancssor dir parancsáról nem is beszéltem.
Pl. ha C:\windows\system32-t listázom ki, akkor a 2. esetben az "aadcloudap.dll"-t nem találja meg. Az 1. és a 3. esetben megtalálja, de van amiben azok is különböznek.
Ki érti ezt'et? -
pmonitor
aktív tag
válasz
sztanozs
#16528
üzenetére
Készítettem tesztprogramot C-ben, csak nem tudom, hogy mikor tudom hosszasan futtatni. pidtesztA:
#include <windows.h>
HINSTANCE hInstance = NULL;
char* AppName = "PID teszt \"A\"";
char* WindowClassName = "pidtesztA";
HWND AppHwnd = NULL;
LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam);
int main()
{
WNDCLASSEX wc;
MSG msg;
hInstance = GetModuleHandle(NULL);
wc.cbSize = sizeof(WNDCLASSEX);
wc.style = CS_HREDRAW | CS_VREDRAW;
wc.lpfnWndProc = WindowProc;
wc.hbrBackground = COLOR_BTNFACE + 1;
wc.hInstance = hInstance;
wc.lpszMenuName = NULL;
wc.lpszClassName = WindowClassName;
wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wc.hCursor = LoadCursor(0, IDC_ARROW);
RegisterClassEx(&wc);
AppHwnd = CreateWindowEx(0, WindowClassName, AppName, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 1200, 900, 0, 0, hInstance, 0);
ShowWindow(AppHwnd, SW_SHOWDEFAULT);
UpdateWindow(AppHwnd);
while (GetMessage(&msg, 0, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
case WM_CREATE:
ShowWindow(AppHwnd, SW_NORMAL);
break;
case WM_COMMAND:
break;
case WM_SIZE:
{
break;
}
case WM_SHOWWINDOW:
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hwnd, uMsg, wParam, lParam);
break;
}
}pidtesztB:
#include <stdio.h>
#include <stdlib.h>
#include <Windows.h>
STARTUPINFOA SI;
PROCESS_INFORMATION PI;
HWND Pids[400000000];
int PidsP = 0;
int waitmsec = 500;
int appStart(char name[])
{
if (!CreateProcessA(NULL, name, NULL, NULL, FALSE, 0, NULL, NULL, &SI, &PI))
{
printf("A %s file-t nem lehet megnyitni...\n", name);
return -1;
}
WaitForSingleObject(PI.hProcess, waitmsec);
return 0;
}
int main(int argc, char* argv[])
{
DWORD procid = 0, hwndid;
ZeroMemory(&SI, sizeof(SI));
SI.cb = sizeof(SI);
ZeroMemory(&PI, sizeof(PI));
if (argc == 3) waitmsec = atoi(argv[2]);
char appA[50] = "pidtesztA.exe";
char appAClass[50] = "pidtesztA";
if (!appStart(appA))
{
HWND hwnd = FindWindowExA(NULL, NULL, appAClass, NULL);
while (hwnd)
{
int pidact = 0;
int tid = GetWindowThreadProcessId(hwnd, &pidact);
Pids[PidsP] = pidact;
PidsP++;
hwnd = FindWindowExA(NULL, hwnd, appAClass, NULL);
}
TerminateProcess(PI.hProcess, 0);
}
HWND prochwnd;
int i, out = 0, imax = 500;
if (argc >= 2) imax = atoi(argv[1]);
for (i = 0; i < imax; i++)
{
ZeroMemory(&SI, sizeof(SI));
SI.cb = sizeof(SI);
ZeroMemory(&PI, sizeof(PI));
if (!appStart(appA))
{
HWND hwnd = FindWindowExA(NULL, NULL, appAClass, NULL);
while (hwnd)
{
int pidact = 0;
int tid = GetWindowThreadProcessId(hwnd, &pidact);
int j = 0;
while (j < PidsP)
{
if (Pids[j] == pidact)
{
printf("Pid egyezik!\n");
out = 1;
break;
}
j++;
}
if (out) break;
Pids[PidsP] = pidact;
PidsP++;
hwnd = FindWindowExA(NULL, hwnd, appAClass, NULL);
}
TerminateProcess(PI.hProcess, 0);
if (out) break;
}
}
printf("i: %d\n", i);
return 0;
}Mint látható az "A" egy standard window. A "B" console. Az indítási intervallum, és a waitforsingleobject() ideje is alapból 500, de parancssorból változtatható, mint az a kódból is látható. A szám adatok validitását nem ellenőriztem le, csak egyből konvertál(legalábbis megpróbál
).
Még nem tudtam hosszan futtatni. Ha vki. működésbeli hibát vesz észre, Ő kérem jelezze. -
pmonitor
aktív tag
Jó. Ha így állsz hozzá...
Ettől függetlenül, ha lesz időm, írok egy ilyen programot, amit max. 1-2 napig futtatok, mert én tényleg kíváncsi vagyok rá(fogadástól függetlenül). Az biztos, hogy a programkódot közzéteszem majd, és beszámolok az eredményről(mondjuk ez biztos nem holnap lesz).
-
pmonitor
aktív tag
>Ilyen nincs, ez komolytalan. Szedd elo, es mehet. ....... mert anelkul mi lesz? Polgari per?
Ha ügyvéd biztosít, hogy megkapod a lóvét, akkor mire írod, hogy komolytalan? Meg aztán... itt a fórumon is itt van/lesz a nyoma, hogy bevállaltuk. Szóval, ha vesztenék(rossz esetben), akkor mit gondolnának rólam a többiek? És az olvasók? Szóval azért az nem csak úgy megy, hogy polgári per lesz belőle...
Viszont azok tények, amit leírtam. Az is tény, hogy a dqdb-vel történő irományunk sec-ekről/min-ekről szólt. És az is tény, hogy egy évet emlegetsz, mert meg akarod nyerni. Ebből látszik, hogy mennyire távol áll a valóságtól, amit dqdb írt.
Összesítve: a 10M nélkülözhető lóvé nincs meg, de garancia, hogy megkapod, ha nyersz, az ügyvéd(és a fórum résztvevői által) meglesz.
-
pmonitor
aktív tag
Nem tudom, hogy a fogadásból lesz-e valami, de valami egyértelműen látszik: mégpedig az, hogy milyen kicsi a valószínűsége a "jó eset" bekövetkezésének. Te is írtad, hogy "Ha 1 masodpercenkent tudok nyitni/zarni egy ablakot, akkot 50% eselyem van ra, hogy masfel nap alatt talalok utkozest". Ezzel szemben mégis egy éves futásidőt emlegetsz. Na erre mondtam én, hogy lehetetlen. Mert az eredeti példánkban(amiről dqdb-vel írogattunk) pár sec/min alatt kellene bekövetkeznie ennek az esetnek "véletlenül". De látod, amikor tétje van a dolognak, akkor már hónapokról/évről beszélgetünk. Mondjuk én is kockáztatok, mert csak 1 window-t kell ellenőrizni a "B" programnak. Szóval azért arra is van esély, hogy év alatt talán beletrafál egy ütközésbe. Ki tudja ezt?
-
pmonitor
aktív tag
A 10M-t nem tudom letétbe helyezni, de biztosítékot tudok rá adni(a vagyonom több, csak a vesztésem esetén kell egy kis idő, hogy meg tudjam adni, de nincs vele gond).
>Ha 1 masodpercenkent tudok nyitni/zarni egy ablakot, akkot 50% eselyem van ra, hogy masfel nap alatt talalok utkozest.
De azt is bele számoltad, hogy a több megnyitással a számítási idő is növekszik(tehát amíg ellenőrzöd az ütközést)?
-
pmonitor
aktív tag
Ügyvéd előtt is beleállok. Már csak a "bizonyíthaóan"-ban kell megegyeznünk a részemről(meg valszeg a "B" program max. futásidejéről(bár ezt meghatározhatjuk úgy is, hogy "mi döntjük el, hogy mikor állítjuk le"). De ezek már csak részletkérdések.
Egyébként sztem a PID is 32 bites.
-
-
pmonitor
aktív tag
>tehat elojon egy olyan [PID,HWND], ami mar szerepelt
Nem elég, hogy csak előjöjjenek ugyanazok, hanem hogy ugyanolyan típusú alkalmazás jöjjön létre ezekkel a jellemzőkkel. Tehát:
1.: nyitsz egy X típusú alkalmazást(ebben megegyezhetünk, hogy mi legyen ez. Lehet pl. egy notepad is.)
2.: Feljegyegyzed ennek az alkalmazásnak a PID-jét és az elsődleges window Handle-jét(notepad esetén pl. annak a windownak, aminek az "class" tulajdága "Notepad").
3.: Nyitsz/zársz alkalmazásokat(köztük X típusúakat is).
4.: Ha a nyitott alkalmazás X típusú(a példámban notepad), és a PID-je és az elsődleges window Handle-je ugyanaz, mint amit az elején feljegyeztél, akkor nyertél. -
pmonitor
aktív tag
Nekem még olyant sem sikerült előidéznem, hogy azonos PID legyen. Mondjuk nem is csodálkozom rajt, hiszen a feltétel szerint nem elég, hogy csak egyszerűen ugyanaz legyen a PID, hanem még az is, hogy annak is pontosan X típusú programnak/alkalmazásnak kell lennie. Úgyhogy sztem. már ehhez is nagy véletlen kell, hogy teljesüljön. És akkor még nem esett szó az elsődleges window Handle-jéről.
Lehet, hogy elég csak a PID rögzítése. Ha vki. biztosabbra akar menni, akkor az elsődleges window Handle-t is rögzítheti. Ha valakinek még ez sem elég, Ő a Window Thread rögzítésével aztán sztem. túlbiztosíthatja magát. De ehhez sztem. paranoias-nak kell lenni.
-
pmonitor
aktív tag
> olyat, hogy a kicsi valószínűsége, nem lehet kijelenteni és építeni sem lehet arra, hogy kicsi a valószínűsége.
Szóval szted. ez bekövetkezik:
1.: Indítasz egy X típusú alkalmazást, aminek Y a PID-je, és Z az elsődleges window HWND-je.
2.: Bezárod ezt az alkalmazást.
3.: Indítasz egy következő X típusú alkalmazást, S idő múlva.
4.: Ennek az X típusú alkalmazásnak ugyanúgy Y a PID-je, és Z az elsődleges window HWND-je.Erre azt mondod, hogy "gyakorlatilag be fog következni."?
Sztem. még az is majdnem lehetetlen, hogy Y lesz a PID-je ÉS Z lesz VALAMELYIK window HWND-je. És gondolj bele: ez még mindig nem ugyanaz az eset, mert ugye a Z HWND-vel az ELSŐDLEGES window-nak kell rendelkeznie(nem valami button-nak, vagy textbox-nak).
Na én erre azt mondom, hogy lehetetlen! Attól függetlenül, hogy nem tudom, hogy a Microsoft "milyen algoritmus szerint osztogatja a handle-öket és PID-eket Windowsban". -
-
pmonitor
aktív tag
válasz
sztanozs
#16483
üzenetére
Igaz, hogy említettem a PID-et, de ha megnézed, akkor a példakódban a Fő form Handle-jét(HWND-t) nézem. És annak küldök üzenetet. Bár elvileg a HWND is lehetne ugyanaz ismételten, de nem hiszem, hogy sűrű jelenség lenne az ilyen. De lehet a PID-et és a Me.Handle-t is rögzíteni, akkor még biztonságosabb. Olyan tényleg nagyon ritkán van(ha van egyáltalán), hogy a egy új alkalmazás úgy jön létre, hogy az előtte nemrég bezárt alkalmazással azonos a Fő form HWND-je is és a PID-je is. Ez sztem. szinte lehetetlen.
-
pmonitor
aktív tag
válasz
lenkei83
#16474
üzenetére
Ez esetben a belépésnél el kell küldened a PID-et, vagy a Fő form Handle-jét, és rögzíted az adatbázisban, ha nincs benne. Én a fő form Handle-jét küldeném el, mert ebből is utána lehet nézni a PID-nek. A következő lépés attól függ, hogy mit rögzítesz az adatbázisban. Ha a Fő form Handle-jének WM_DESTROY üzenetet küldesz a SendMessage-el, akkor ugyanazt éred el, mint az application.exit-el(ez "mindent visz"). Ha WM_CLOSE üzenetet küldesz neki, akkor lefut pl. a form Form_Closing eseménye(ebből akár meg is akadályozhatod, hogy bezáródjon a form). Példaként megcsinálhatod a következőt(ha 64 bites wined van). Letöltöd innen a Processx64.rar-t.
Ezután készítesz egy winform alkalmazást, amire rádobsz egy textbox-ot, egy button-t, és egy combobox-ot. Design nézetben elrendezed őket úgy, ahogy akarod. A Form1.vb-ben lévő dolgokat lecseréled erre:Imports System.Runtime.InteropServices
Public Class Form1
Const WM_CLOSE = &H10
Const WM_DESTROY = &H2
Const WM_GETTEXTLENGTH = &HE
<DllImport("user32.dll", CharSet:=CharSet.Auto)>
Public Shared Function SendMessage(ByVal hWnd As IntPtr, ByVal Msg As Integer, ByVal wParam As Integer, ByVal lParam As IntPtr) As IntPtr
End Function
Private Sub Form1_Shown(sender As Object, e As EventArgs) Handles MyBase.Shown
Button1.Text = "Bezárás"
ComboBox1.Items.AddRange(New Object() {"WM_CLOSE", "WM_DESTROY"})
ComboBox1.DropDownStyle = ComboBoxStyle.DropDownList
ComboBox1.SelectedIndex = 0
End Sub
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
If IsNumeric(TextBox1.Text) Then
Dim WM As Integer
If SendMessage(TextBox1.Text, WM_GETTEXTLENGTH, 0, IntPtr.Zero) Then
If ComboBox1.SelectedIndex = 0 Then
WM = WM_CLOSE
Else
WM = WM_DESTROY
End If
SendMessage(TextBox1.Text, WM, 0, IntPtr.Zero)
Else
MsgBox("Az ablaknak nincs címe!")
End If
End If
End Sub
End ClassEzt lefordítod. Ha minden jól megy akkor le is fordul. Majd megnyitsz egy notepad-ot, és írsz bele valamit. Megnyitod a Processx64.rar-ban lévő .exe-t és megkeresed azt a notepad-ot. Jobb klikk->Ablakok kiválasztása. A megnyíló ablakban megkeresed a Class mezőben a "Notepad"-ot. Ebben a sorban a Hwnd-t átmásolod a lefordított programod textbox-ába. Kiválasztod a combobox-ban a műveletet, majd klikk a button-ra. Itt láthatod a különbséget a WM_CLOSE és a WM_DESTROY között.
Neked ugyanezt kellene csinálnod, csak az adatbázisban tárolt Handle-nek küldeni ezeket.
-
pmonitor
aktív tag
válasz
K1nG HuNp
#16433
üzenetére
>semmi koze a nyelv szintjének a gyorsasághoz
Kivételesen egyetértek. És még hozzá tenném, hogy ha pontosak akarunk lenni, akkor még a nyelvnek sincs semmi köze a gyorsasághoz. Pl. biztos teljesen más a VS 20XX C-jének a sebessége, mint a Code:
locks+mingw által alkotott bináris. És még lehetne példákat hozni. Tehát igazából amikor nyelvek gyorsaságát hasonlítjuk össze, akkor is eléggé pontatlanul fogalmazunk. De sztem. nem olyan eget verő pontatlanság.Igazából magas szintű nyelv is lehetne elvben gyors. Csak a gond ott van, hogy bizonyos dolgokat ezerféleképpen meg lehet gépi kódban valósítani. És az adott magas szintű programnyelv nem biztos, hogy az optimális kódra fordít.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
). Ezért hiányolom azt, hogy akik programozóknak mondják magukat, nem hozzák nyilvánosságra, amit alkottak(mert olyan nincs, hogy egy programozó úgy lett programozó, hogy nem alkotott semmit). Cattus azt írta, hogy nem érdekli, hogy én mit várok el. Ezzel nincs is gond. De akkor az ilyenek se várják el, hogy elhiggyem/elhiggyék, hogy programozó.
Ugyanakkor csak legalább ennyit "várnék" el az olyanoktól, aki programozónak állítja be magát. Ugye, hogy nem is volt olyan nehéz ezt megtenni?
Pedig lehetne rajt mit optimalizálni, mert a C itoa(...) függvénye ~21 sec alatt megoldja, amit a C# említett metódusa ~51 sec alatt. És C-ben még van eszközöd optimalizálni, mert le lehet vinni 10 sec. alá a futásidőt.
Pl. hogy miért nem működik az sprintf(...) win32-ben? "Error LNK2001 unresolved external symbol __imp____stdio_common_vsprintf" hibaüzit ad. Mindenesetre suszter módszerrel megoldottam a helyettesítését a FindFileC-ben. 
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- 0PERCES BOSE QuietComfort Ultra Headphones, zajszűrős, Bluetooth fejhallgató! Fekete, Fehér!
- Új Lenovo IdeaPad Slim 5i Prémium Ultrabook Laptop 14" -30% Ultra 7-155H 16/1TB FHD+ OLED
- IPhone 15 Pro 128GB gyári független 2026.12.15.Apple jótállás
- SAPPHIRE Radeon RX 7800 XT PULSE 16GB
- Lenovo Thinkpad T490 Core i5 8365U 16GB RAM 256GB NVME SSD Magyar Bill Gar
- Keresünk dokkolókat
- GYÖNYÖRŰ iPhone 15 Pro Max 256GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3496, 90% Akkumulátor
- iKing.Hu - Motorola G86 5G Dark Blue Használt, karcmentes állapotban 8 GB RAM / 256 GB tárhely
- ÚJ Dell Latitude 15 5550 - 15.6"FullHD IPS - Ultra 5 135U - 16GB - 512GB SSD - Win11 - 2,5+ év gari
- Lenovo ThinkPad P1 Gen2 intel i7-9850H 16GB RAM 512GB SSD 15,6" 4K OLED TOUCH 1 év garancia
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest