- TCL LCD és LED TV-k
- Adatmentés - HDD - SSD - Flash
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen cserélhető objektíves gépet?
- Gaming notebook topik
- Azonnali VGA-s kérdések órája
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Azonnali fotós kérdések órája
- Házimozi haladó szinten
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
-
PROHARDVER!
Új hozzászólás Aktív témák
-
#16796
nevemfel
senior tag
Netszemete
#16790
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.
-
#16795
Ispy
nagyúr
Netszemete
#16794
Ispy
nagyúr
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.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#16792
axioma
veterán
Netszemete
#16790
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.
-
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
-
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. -
#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 -
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. -
K1nG HuNp
őstag
-
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... -
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).
-
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.
-
#16761
Drizzt
nagyúr
Atomantiii
#16759
Drizzt
nagyúr
válasz
Atomantiii
#16759
üzenetére
-
#16760
dabadab
titán
Atomantiii
#16759
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.
-
#16759
Atomantiii
addikt
Atomantiii
addikt
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?
-
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.) -
#16756
mobal
nagyúr
Netszemete
#16747
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.
-
#16754
dabadab
titán
Netszemete
#16753
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. -
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. -
kovisoft
őstag
válasz
pmonitor
#16744
üzenetére
Ha ellenpélda kell, csak oldjuk meg az 5*x-2^32>x, 2*(5*x-2^32)<2^32 egyenlőtlenségeket, és máris találunk pl. egy x=1073741825 megoldást, aminél az 5*x túlcsordul és 1073741829 lesz, ami nagyobb x-nél, ennek 2-szerese már nem csordul túl. Tehát ha a végére teszünk még egy digitet és az input pl. 10737418250, akkor ennek a túlcsordulását nem fogja detektálni.
-
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
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. -
#16739
kovisoft
őstag
Netszemete
#16738
kovisoft
őstag
válasz
Netszemete
#16738
üzenetére
Windows-on is?
-
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().
-
kovisoft
őstag
válasz
pmonitor
#16733
üzenetére
Ezzel szerintem megint az lesz a baj, mint a korábbiakkal, azaz hogy a túl nagy vagy túl kicsi számokra is visszaad valami látszólag értelmes integert. Persze most megint visszatérhetünk oda, hogy az atoi() mit is kell visszaadjon invalid inputra. De a kódban látom az igyekezetet, hogy észrevegye a túlcsordulást. Ugyanakkor ezt úgy próbálja megtenni, hogy azt nézi, hogy az aktuális részösszeg 10-zel szorozva negatív lesz-e. De mi van pl. a 999999999x esetén? Az utolsó előtti számjegynél a részösszeg 999999999, ez 10-zel szorozva ugyan túlcsordul, de a túlcsordult érték pozitív lesz. Tehát nem veszi észre a túlcsordulást és visszaad valami random integert.
-
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.
-
axioma
veterán
válasz
dabadab
#16731
üzenetére
Nekem forditva, a fizikai kalendariumrol jutott eszembe hogy adventofcode
(eddig oitm-eztem, pont vege, erre megint lesz program melo utanra)
De amugy ja, miutan rajottem hogy megvan a tavalyi leaderboard, mar figyelemfelhivo cellal nem toroltem az egesz hsz-t hanem hagytam itt, hatha leszunk kicsit tobben iden... -
#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.
-
#16726
kovisoft
őstag
Netszemete
#16725
kovisoft
őstag
válasz
Netszemete
#16725
üzenetére
Lehet, hogy igazad van, én a legelső google találatot néztem, ott ezt írják:
"This function returns the converted integral number as an int value. If no valid conversion could be performed, it returns zero."
-
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.
-
kovisoft
őstag
válasz
pmonitor
#16718
üzenetére
Csak gyorsan átfutottam, úgyhogy nem biztos, hogy igazam van, de szerintem INT_MAX-nál nagyobb vagy INT_MIN-nél kisebb számokra továbbra is vissza tud adni valami szemetet. Az i 10-zel szorozgatva ilyenkor egyszercsak túlcsordul, aztán akármi is előállhat a ret-ben.
Az INT_MIN esetet most nem látom teljesen át, gondolom, kipróbáltad. A kódból nekem úgy tűnik, hogy INT_MIN esetén (mivel nemnegatív számokkal dolgozol, ezért) túlcsordul, de lehet, hogy aztán valahogy lekezeled ezt a túlcsordulást.
Azért az az
strcmp(arr, "2147483647")eléggé feltételezi, hogy 32 bites intjeid vannak... -
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??
-
Ispy
nagyúr
válasz
zsolti_20
#16706
üzenetére
Időzítő?
Azért a minden másodpercet meggondolnám, hogy jó ötlet-e.
De ahogy nézem van konyhakész megoldás is rá: FileSystemWatcher Class
Gugli első találat.
Ha már igazi programozó nem vagyok és nem vágom séróból a .net keretrendszert, legalább keresni még tudok. 
-
zsolti_20
senior tag
Sziasztok,
Egy egyszerű programon dolgozok C#-ban, ahol egy filet másolok egyik mappából a másikba. Ehhez szeretnék egy időzítőt használni.
Véleményetek szerint milyen megoldással lehet a legelegánsabb? Igazából csak annyira van szükségem, hogy egy végtelen ciklusba kerüljön be, és hajtsa végre a benne lévő utasításokat minden másodpercben.
-
#16705
Ispy
nagyúr
Netszemete
#16703
Ispy
nagyúr
válasz
Netszemete
#16703
üzenetére
Nézd, nem én írtam be a programozás topikba, hogy eltüntahozzászólásom, szarredit, sohatöbbet, énsokkaljobbatcsinálnék.
-
#16704
dabadab
titán
Netszemete
#16703
válasz
Netszemete
#16703
üzenetére
Hogy a "hiszti" szót használod egy egyébként szakmai témában, az csak téged minősít.
Szerintem nem szakmai témában használta, hanem az általad itt rendezett... hisztit nevezte meg.
-
#16702
Silεncε
őstag
Netszemete
#16700
Silεncε
őstag
válasz
Netszemete
#16700
üzenetére
Ezeket a botokat ki készíti?
Bárki, akár te is. API documentation: [link]
Ki tervezte ilyenre a redditet?
Nyilván az üzemeltetői. Az viszont, hogy a moderáció pl hogy működik (egy bizonyos ponton túl) nem sok közük van.
-
#16701
Ispy
nagyúr
Netszemete
#16700
Ispy
nagyúr
válasz
Netszemete
#16700
üzenetére
Nézd, ha ezek után sem érted, hogy miért így megy ahogy, akkor tényleg nem kell redditelned.
De most tényleg ezen hisztizel, hogy eltűnt egy hozzászólásod? Nagyon alacsonyan van az ingerküszöböd...ha ilyeneken kiakadnék, akkor már rég elmentem volna inkább péknek vagy egy gyárba a futószalag mellé.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
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 
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"
C esetén például 
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- Huawei Watch GS 3, Újszerű, 1 Év Garanciával
- MacBook Air 2020 13" Retina I3-1000NG4 1 8GB/256G SSD, HUN BIll, 100% akku, üzletből, garanciával
- Eladó Intel NUC8i5BEK mini PC
- Eladó AM5 DDR5 Konfig Ryzen 5 8400F 16GB DDR5 512GB SSD RX5700XT 8GB!
- iPad Pro 12.9" 3.Gen 2018 512GB Space Gray Wifi cellular, Tökéletes , Garanciával, üzletből
- Konzol felvásárlás!! Playstation 5, Playstation 5 Pro
- Villámgyors teljesítmény és 10 év nyugalom!
- Eladó szép állapotban levő Samsung S22 8/128GB / 12 hó jótállással
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Azonnali készpénzes nVidia RTX 5000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
Állásajánlatok
Cég: FOTC
Város: Budapest