-
GAMEPOD.hu
Új hozzászólás Aktív témák
-
axioma
veterán
válasz DopeBob #16750 üzenetére
Meg tudod nezni a korabbi eveket Tavaly Conway halala miatt a feladatok jelentos resze az eletjatekra epult. Tavalyelott me'g egy kicsit jobban egymasra epulgetes volt, parnaponkent a korabbi megoldas kodjat kellett tobb alkalommal is tovabbfejleszteni es gyakorlatilag egy specialis interpretert epitettel szep folyamatosan.
-
dabadab
titán
válasz Netszemete #16753 üzenetére
a dBase mióta programnyelv? Én úgy tudtam, az egy adatbáziskezelő.
A dBase nem csak egy adatbáziskezelő program, hanem van egy saját programnyelve is.
Egyébként a dBase III leszármazottja a FoxPro, amivel a korai kilencvenes években rengeteg ügyviteli szoftver készült, mivel az már tudott .exe-t is produkálni, szóval pont a dBase teljesen jó helyen van ott.DRM is theft
-
MODERÁTOR
válasz Netszemete #16747 üzenetére
Nagyon egyszerű feltételezésből indulok ki. A világ 3. (?) legnépszerűbb programozási nyelvének egyik alap függvényére a kolléga talált egy jobb megoldást, közel 30 (?) év után.
Valószínűtlen. De félre ne érts, nem akartam egy pillanatig sem bátani vagy akármi negatív.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
axioma
veterán
válasz DopeBob #16752 üzenetére
Ja igen, erdemes gyujteni. En mar csak azert is osszerakom evente 1 file-ba (nem hasznalt kikommentezve), mert volt hogy hasznaltam a feladatok egyiket-masikat szemleltetesre, es akkor jobb ha keznel van a megoldas, nem kell ujrairni Tavaly a 25 nap alatt python-ban, minden ujra copy-paste ami reuse volt az is, lett szumma 1751 sor, azaz atlag 70 per nap (amiben az ugyanazt az inputot fogado es jellemzoen hasonlo ket alfeladat is masolva lett, saccra inkabb 40-45 erdemi sor), es egy resze az is korabbrol masolva. Szoval szerintem nem nagyon vannak benne nehezek, talan egy-ketto masodik resz. (FYI itt pl. megbeszelhetjuk ha megis valami olyan.)
-
Atomantiii
őstag
Ha van egy programom, ami egy MySQL adatbázisból dolgozik és a saját gépemen futtatom, akkor kell neki valamilyen SQL szerver program is, hogy tudjon dolgozni az adatbázisommal.
De ha a programból készül egy exe fájl és azt egy másik gépen szeretném futtatni, akkor megtudom-e neki mondani SQL szerver nélkül is, hogy az adatbázis fájl pl a c:\adatbázis\valami.sql fájlban érhető el és csak olvasni szeretném az adatokat belőle?
[ Szerkesztve ]
-
dabadab
titán
válasz Atomantiii #16759 üzenetére
Ilyesmi felhasználásra van az SQLite. Persze ennek is megvan a saját SQL-dialektusa, szóval a queryket valószínűleg át kell egy kicsit faragni meg az on-disk formátuma nem kompatibilis, szóval mindenhol SQLite-ot kell használnod, MySQL adatbázist nem fog tudni olvasni.
DRM is theft
-
Drizzt
nagyúr
-
zsolti_20
senior tag
Sziasztok,
Írtam egy egyszerű makró programot C#-ban, amit arra szeretnék felhasználni, hogy játékokban ne kelljen mindig beírni a hosszú kódokat, vagy menükben navigálni, hanem egy gomb megnyomására végre tudja hajtani a teljes folyamatot.
Sendkeyel próbálkoztam, illetve virtuális billentyűzet szimulálásával. Notepadban és szinte bárhol nagyon jól működik. Egy gomb lenyomására képes beírni egy szöveget, vagy több gomb lenyomását megcsinálni.
De amint egy játékon belül próbálom használni egyszerűen nem működik. Kicsit utána olvasva rátaláltam a válaszra, hogy a játékok directX-et használnak amik nem tudják érzékelni ezeket a makrózásokat, illetve sok helyen tiltva is van, gondolom a csalások miatt. Nekem nem szándékom ezzel bármi előnyre szert tenni, csupán single playerben a kódok beírását szeretném felgyorsítani.
Belemerülve még jobban a dologba, Cheat Engineval lehetséges a memóricímen lévő value változtatása.
Pl. ha egy float értéket szeretnék változtatni C# segítségével a 0x68F5F0 címen, hogyan lehetséges ezt megoldani? Van erre bármiféle egyszerűbb megoldás? Találtam pár oldalt ahol írtak erről ,de a kódok nagyon hosszúak. Véleményetek szerint valóban szükséges ennyire hosszú kód hozzá? Vagy kivitelezhető egy pár sorossal is?
Csupán ennyit szeretnék megoldani:
0x68F5F0 memóriacímen a float értékét változtatni tudjam. -
nagyúr
válasz zsolti_20 #16762 üzenetére
> 0x68F5F0
C#-bol ezt nem nagyon fogod tudni megoldani, ugyanis a memoriacim, amit írsz, az szeg virtuális, nem abszolút. Egy program nem tud a másik program memoriateruletere írni, csak az OS kernel tud ilyet, szóval kernel driver kell (a cheat engine gondolom ilyen alapon működik).
while (!sleep) sheep++;
-
zsolti_20
senior tag
Sziasztok,
Ahogy egyre jobban bele merülök a memória címekbe, úgy jön elő több és több kérdés.
Ha elindítok egy szoftvert két különböző PC-n, hogy kaphat ugyan olyan memória címet? -
janos1988
addikt
https://www.youtube.com/watch?v=mkDSGbRyjz8&list=PLVJH24yGtE_w5Ke4aWmRV8erFQmqRD1dK Minden egyes új rész rátesz még egy lapáttal :-D
-
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...http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
MODERÁTOR
válasz pmonitor #16771 üzenetére
Látszik, hogy nem vagy szakmabeli. Olcsóbb a tárhely mint az ilyen alacsony szintű optimalizációra szánt idő. Amit nem tudsz szavatolni, hogy jól is és hibamentesen működik.
Egyébként ez egy csak egy általánosítás a részedről ami nem is igaz.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
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).
[ Szerkesztve ]
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
K1nG HuNp
őstag
válasz pmonitor #16775 üzenetére
ember ne általánosíts már..
van az szitu amikor a legfossáoptimalizáltabb kód kell és van a maradék 99% ahová csak haladni kell azzal ami előre viszi a businesst.
(raw_item.get("pk").unwrap().as_s().unwrap().to_string()).split("#").collect::<Vec<&str>>()[1].to_string()
-
K1nG HuNp
őstag
válasz nevemfel #16780 üzenetére
hú najó azért szegényt ne kapjuk szét ennyire sajnos nálam nem volt befrissitve az oldal és a kommentem utan lattam hogy mar 3an ugyan azt leirtak neki kb.. na mindegy, azert orulok hogy a nagytobbseg hasonlo allasponton van es nem csak en vagyok "lezser"
(raw_item.get("pk").unwrap().as_s().unwrap().to_string()).split("#").collect::<Vec<&str>>()[1].to_string()
-
dabadab
titán
válasz pmonitor #16771 üzenetére
É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).
Ja, gyorsabban lefut, csak nem működik meg baromira nem azt csinálja, amit a C szabvány (ez a draft, a végleges csak fizetős formában elérhető, de abban is ugyanez van) előír. Érdemes megnézni a szabványt meg mondjuk a GNU C lib forráskódját aztán összehasonlítani a tieddel, amiből pl. teljesen hiányzik a locale-kezelés.
Szóval igen, érdemes nem azt gondolni, hogy rajtad kívül mindenki hülye, mert kiderülhet, hogy pont fordítva van.[ Szerkesztve ]
DRM is theft
-
#25954560
törölt tag
válasz pmonitor #16771 üzenetére
mondjuk ennek egy resze az oktatasban is keresendo es/vagy abban h nagyon sok programozonak elkepzelese sincs milyen eroforras-igenye van annak, amit megir. egyaltalan, mi tortenik, amikor lefut a programja. egyaltalan mitol fut ez nem feltetlenul baj, en sem vagyok tisztaban a kulonfele oktanszamu benzinek kopogasturesevel, attol meg tudok vezetni. viszont nem is tervezem at a kocsim gyujtasat es kompresszioviszonyat
-
Ispy
veterán
Ezt a fórumot lassan át kéne nevezni pmonitorra és kész.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
Drizzt
nagyúr
válasz pmonitor #16775 üzenetére
Nagyon jol latszik, hogy dolgozni nem dolgoztal proramozokent. Ugyanis ott jellemzoen nem ezek a fontos problemak. Sokkal tobb gondot okoz az allandoan valtozo requirement lekovetese ugy, hogy a meglevo funkcionalitas erintetlen maradjon a bugfixek es uj fejlesztesek kapcsan. Illetve gyakran nagyon fontos, hogy a user minel hamarabb el tudjon kezdeni hasznalni valamit, mert akkor fog tudni rajonni, hogy mit nem gondolt vegig amikor megfogalmazta a korabbi requirementjeit.
Jobbnak gondolt programozok alapelve, hogy "avoid premature optimization". Ennek minden szava fontos. Mert nem arrol van szo, hogy ne optimalizalj, hanem arrol, hogy ne a szerint optimalizalj, hogy mi lesz szerinted gyakran hasznalt es kritikus. Ugyanis sosem tudod elore biztosan kitalalni, hogy a usernek mi lesz a fontos. Altalaban elore o maga sem tudja. Nyilvan van amit muszaj optimalizalni, de jol meg kell valasztani, hogy mit, mert aranytalanul draga.
Ha mondjuk valamit egy csapat szarraoptimalizal 1 ev alatt es amiatt fele annyi hardverkoltseg lesz eves szinten, az a megrendelonek nem igazan deal, mert egy(, nem egy csapat!) programozo eves koltsege legyen mondjuk 250000 dollar, fele akkora vm elofizetese meg mondjuk 300 dollar sporolas/honap, azaz ~4000 dollar/ev.
Sokkal fontosabb az, hogy a programozo meg tudja allapitani, hogy mi az, ami tenyleg lassu(monitoring, profiling) es azt hamar elfogadhatora optimalizalja.
Ami igazan fontos resze a lehetseges teljesitmenynek, az foleg architekturalis kerdes, abba erdemes tobb idot beletenni. Mikrooptimalizalasnak ott van ertelme, ahol az tenyleg bizonyitottan szukseges.I am having fun staying poor.
-
martonx
veterán
válasz pmonitor #16775 üzenetére
"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)."
Tessék egy link, hogy a nyelvek fejlesztőit mennyire nem érdekli a teljesítmény: [link]Mondod ezt úgy, hogy soha nem próbáltál meg PR-t beküldeni. Gratulálok
Én kérek elnézést!
-
axioma
veterán
válasz Netszemete #16790 üzenetére
Mar a szeperzekem se engedne hogy ok nelkul lassabb megoldast irjak le, mint ami szerintem jo (algoritmus szinten ertve most, nem utasitasszinten). Az ok persze lehet az hogy nem csak magadnak irod a kodot es mas nem latna at, de nagyon ritka az, hogy annyira trukkos lenne a megoldas es keves a nyereseg, hogy az egyszerubb mellett kell donteni - minden mas esetben elo kell segiteni a megertest.
-
Ispy
veterán
válasz Netszemete #16794 üzenetére
Bármin lehet töprengeni menet közben, ha végtelen idő áll rendelkezésedre, ami persze szokott is lenni. Oh, wait.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
nevemfel
senior tag
válasz Netszemete #16790 üzenetére
Én direkt lassú kódot írok, hogy az optimalizálók idegeit szétcsesszem. Nekem ez a küldetésem.
Forget your troubles, c'mon get happy
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Linux - haladóknak
- Politika
- A franciáknak elege van abból, hogy minden gyerek mobilozik
- bitpork: Balatoni autós tali 2024
- Robot fűnyírók
- Xiaomi Pad 5 - hatásos érkezés
- Házimozi haladó szinten
- HiFi műszaki szemmel - sztereó hangrendszerek
- Hogy is néznek ki a gépeink?
- Autós topik
- További aktív témák...
- Kingston FURY SO-DIMM 8 GB DDR4 3200 MHz CL20 Impact
- Hp EliteBook 650 G9 Mint az ÚJ! Ci5 12.Gen!!! FHD/IPS/SSD/512GB/16GB/Gyári Gari
- Be quiet Pure power 11 600W 80+Gold
- Félkonfig eladó! i5 9400F+Gigabyte H370 HD3+16GB Kingston HyperX+Thermaltake hűtő
- PC - XBOX360 Guitar Hero Explorer gitár vezetékes