Az itt levő .rar-ban a FindFileC.exe 64 bites lett.

Jó programoz(gat)ást kívánok!

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

>A Google keresés pedig nem a te géped, vagy a Google optimalizálatlansága miatt lassú,

Miért? Szted. lassú a google keresés? Sztem. a kiírás alapján nem lassú. Éppen azért írtam az adatbázis példát, mert az ezek készítői dicsekednek azzal, hogy mennyire gyorsak. Ha nem lenne fontos a sebesség, akkor miért is dicsekednének azzal, hogy milyen gyorsan van találati lista a nagy méretű adatból is.

Itt írtam, hogy a FindFileC.exe 64 bites lett. Csak sajnos tele volt bug-al, ami abból adódott, hogy a karakterkódolást unicode-ra állítottam, viszont elég sok helyen maradt char típus a wchar_t helyett. Bár úgy látom, hogy "csak" 1 letöltés történt azóta, de nekem 1 ember is fontos. Elnézést kérek a hibáért.

Egyébként ez hasít a TC-hez képest. De találtam 1 FreeCommander programot, ami ugyebár hivatalosan is free a TC-vel ellentétben. És ránézésre nem tud kevesebbet. Csak azt nem értem, hogy az ilyen programokat miért kell telepíteni? De mind1.

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Még saját célprocesszort is terveztek a keresés gyorsítására - szerinted pascalban írták meg hozzá a kódot?

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Jaaa, hogy a Google-t pozitív példának írtad? Azért a Google keresés sebességét hasonlítani egy garázs szerveren futó SQL-éhez, szerintem nem korrekt. Ennyi erővel egy vadász repülőt is hasonlíthatsz egy normál autóhoz...
Emellett annyiban igazad van, hogy a garázs SQL-re olyan programozó dolgozik, aki egy év alatt nem keres annyit, mint a Google-nél dolgozó egy év alatt. Google-nél ilyenből van több ezer, a garázs SQL-en meg Pista bácsi egymaga bohóckodik.
Szóval igen, nem vagyunk egyformák, nem egyformák a képességeink.
Rengeteget állás interjúztatok, és nagyon gyakran ledöbbenek, hogy milyen gyenge programozók is vannak (többnyire állami szférából érkezettek a különösen fájdalmasak).

Én kérek elnézést!

Nem tudom, hogy pontosan mire gondolsz, mert a google-ról a TC-ről, és a freecommander-ről is írtam. De úgy sejtem, hogy talán a google-val kapcsolatban írtad. Ha így van, akkor sztem. nem pascal.

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

>de ez elvileg nem terápiás-, hanem szakmai topik.

Na akkor 1 kis "szakmai" probléma. Ezt kellene optimalizálni. Bármilyen kis optimalizálásnak örülnék, de az sem ártana, ha jelentős optimalizálás lenne...

...
typedef struct FAJLKERESESEREDMENYE
{
int Fajldarab;
int Mappadarab;
long long Fajlhossz;
wchar_t* Fajlok;
wchar_t* Mappak;
} FAJLKERESESEREDMENYE;

...

void search(wchar_t* sPath, wchar_t* sFileMask, FAJLKERESESEREDMENYE* pFke, char almappae, char mappae, char fajle)
{
if (!out)
{
int i = 0, n = 0;
wchar_t* aktFolders = tempFolders;
WIN32_FIND_DATA WFD;
HANDLE iSearchHandle = NULL;
int bContinue = 1;
wchar_t* sPath_1 = (wchar_t*)GlobalAlloc(LMEM_FIXED, (wcslen(sPath) + wcslen(sFileMask) + 1) * sizeof(wchar_t));
if (sPath_1 == INVALID_HANDLE_VALUE) MessageBox(0, L"memória", L"Üzenet", 0);
if (almappae)
{
wcscpy(sPath_1, sPath);
wcscat(sPath_1, L"*");
iSearchHandle = FindFirstFile(sPath_1, &WFD);
if (INVALID_HANDLE_VALUE == iSearchHandle)
{
}
else
{
while (bContinue)
{
if (wcscmp(WFD.cFileName, L".") && wcscmp(WFD.cFileName, L".."))
{
int s;
if ((WFD.dwFileAttributes & 16) == 16)
{
wcscpy(tempFolders, sPath);
wcscat(tempFolders, WFD.cFileName);
wcscat(tempFolders, L"\\\0");
s = wcslen(tempFolders);
tempFolders += s;
++tempFolders;
++n;

}
}
bContinue = FindNextFile(iSearchHandle, &WFD);
}
bContinue = FindClose(iSearchHandle);
}
}
bContinue = 1;
wcscpy(sPath_1, sPath);
wcscat(sPath_1, sFileMask);
iSearchHandle = FindFirstFile(sPath_1, &WFD);
if (INVALID_HANDLE_VALUE == iSearchHandle)
{
}
else
{
while (bContinue)
{
if (wcscmp(WFD.cFileName, L".") && wcscmp(WFD.cFileName, L".."))
{
int s;
if ((WFD.dwFileAttributes & 16) == 16)
{
if (mappae)
{
wcscat(WFD.cFileName, L"\r\n");
wcscpy(pFke->Mappak, sPath);
wcscat(pFke->Mappak, WFD.cFileName);
s = wcslen(pFke->Mappak);
pFke->Mappak += s;
++(pFke->Mappadarab);
}
}
else
{
if (fajle)
{
wcscpy(pFke->Fajlok, sPath);
wcscat(pFke->Fajlok, WFD.cFileName);
wcscat(pFke->Fajlok, L"\r\n");
s = wcslen(pFke->Fajlok);
pFke->Fajlok += s;
++(pFke->Fajldarab);
}
}
}
bContinue = FindNextFile(iSearchHandle, &WFD);
}
bContinue = FindClose(iSearchHandle);
}
GlobalFree(sPath_1);
if (almappae)
{
for (; i < n; i++, aktFolders += (1 + wcslen(aktFolders)))
{
search(aktFolders, sFileMask, pFke, almappae, mappae, fajle);
}
}
}
}

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

void search(wchar_t* sPath, wchar_t* sFileMask, FAJLKERESESEREDMENYE* pFke, char almappae, char mappae, char fajle)

Ha már állandóan az optimalizáláson pörögsz, akkor hol vannak a const módosítók azon paraméterek elől, amelyek értékét nem módosítja a kód, és emiatt a compiler optimalizáláskor figyelembe tudja venni?

wchar_t* sPath_1 = (wchar_t*)GlobalAlloc(LMEM_FIXED, (wcslen(sPath) + wcslen(sFileMask) + 1) * sizeof(wchar_t));

Először is:

Másodszor az első paraméterben szereplő LMEM_FIXED a LocalAlloc híváshoz tartozó konstans, itt a GMEM_FIXED konstanst kellene használni.

if (sPath_1 == INVALID_HANDLE_VALUE) MessageBox(0, L"memória", L"Üzenet", 0);

A dokumentáció alapján sikertelen foglalás esetében a GlobalAlloc visszatérési értéke NULL, míg az INVALID_HANDLE_VALUE értéke -1, szóval rossz a hibakezelésnél mind a feltétel, mind a kezelése, hiszen NULL pointerrel továbbengeded a futást.

És itt abbahagytam, mert feleslegesnek éreztem folytatni. Az egy pillantásra látszik, hogy tele van a kód buffer overflow aknával.

[ Szerkesztve ]

tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek

Ezek mind igazak, amit leírsz. De ebből a const módosítós javaslatod optimalizál(esetleg).

Természetesen a javaslataid így is figyelembe veszem(és köszönöm).

[ Szerkesztve ]

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Módosítottam a dolgokat.
Hogy ne kelljen mindig ezt a viszonylag hosszú kódot bemásolgatnom, ezért ide tettem fel a file részletet.

Az overflow aknákkal szándékosan nem akar(tam/ok) foglalkozni. Tegyük fel, hogy elég a lefoglalt memória...

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Ez semmit nem fog optimalizálni, de jóval áttekinthetőbbé teszi a kódod:

if (INVALID_HANDLE_VALUE == iSearchHandle)
{
}
else
{

helyett
if (INVALID_HANDLE_VALUE != iSearchHandle)

Nem kell a felesleges else.

Én kérek elnézést!

Illetve az else-n belüli if-ek is bénácskák, elseif szebb lenne.

Én kérek elnézést!

A javaslatok módosítva. C-ben nincs "elseif", csak "else if".

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Tegyük fel, hogy a program már így is eléggé optimalizált...

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

De azt is be lehet mutatni, hogy 1 szaki hogyan csinálja. A példamutatásnak nincs párja. Én nem vagyok semmi jónak az elrontója.

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Tudod, hogy én nem vagyok az optimalizáció pártján.
A helyedben az osszes wcscpy és wcscat hívást a BO-biztos _s végure cserélném.
Ráadásul az se látszik, hogy a tempFolders és a pFke hogy van definiálva példányosítva - szóval nem igazán tudok nyilatkozni. Azt sem tudom, hogy sebességre vagy RAM-ra szeretnél optimalizálni.

Amúgy nem vagyok egy C/C++ guru, de mivel ezt nem a nyelv saját fórumában beszéled meg, így nem érzem a késztetést, hogy ne mondjak véleményt.

[ Szerkesztve ]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Sztem. ez a szakasz eléggé megmutatja, hogy én hogy képzelem el ezt a fórumot. Nem muszáj pmonitor-nak nyernie(nem ez a lényeg). Látod, hogy amit javasoltak, azt módosítottam. De sztem. ezekből a hozzászólásokból/javaslatokból az esetleges olvasók is tanulhatnak.
Viszont ami ez után a szakasz után jött - na az már tényleg nem "szakmai".

[ Szerkesztve ]

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Az optimalizáltságához nem tudok hozzászólni (azért is mert C, és azért is mert ismered a véleményem az optimalizálásról), de hogy jóval áttekinthetőbb (és még rövidebb is) lett a kódod az biztos. Respect!

Én kérek elnézést!

Az overflow aknákkal szándékosan nem akar(tam/ok) foglalkozni. Tegyük fel, hogy elég a lefoglalt memória...
Ilyen hozzáállással érdemi választ vársz még itt? Mit akarsz optimalizálni egy olyan kódon, ami garantáltan buffer overflowhoz vezet?

tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek

Ha buffer overflowhoz vezet, akkor így sem, úgy sem azt csinálja amit kell, nem? Max. nem száll el a teljes program. De végeredmény attól még nem lesz.

Szerk.: De mondjuk a "nagykönyv" szerint egyértelműen neked van igazad.

[ Szerkesztve ]

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Annyit lehet csinálni, hogy ha detektálná az overflow-t, akkor kiírja, hogy "sorry, nem jutottam semmire...". De ez egyrészt hajszálvékony jég, másrészt végeredmény attól még nem lesz. Az egyetlen helyes út, ha megfelelő buffer méretet állít be a hívó függvény. 64 bites app esetén azért ez sztem. megoldható...

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

OK. Let's do it

Ha ilyen "kemény" srác vagy, akkor lám, had lássam ASM-ba (vagy akármibe), hogy:

1. Detektáld az adattároló egységeket (IDE/SAS/RAID/SATA/NVME stb stb stb) ami a gépre/gépbe van csatlakoztatva
2. az általuk használt vezértőkódokat értelmezd
3. 32 avagy 64 bites (neked kell meghatároznod, hogy melyik) címzéssel ellátott memória belapozást állítsd elő(32 bites OS esetén ún base + index (base egy lap + ezen belül offset)) címzéssel lehet elérni (ha nem védett) a 0xFFFFFFFF12345678 címéről kinyerni adatot, mint 64 bit esetén(FLAT módan, mert van még vagy 8 MEM mód)
4. az adott eszköz (1-3 pont) drivere által belapozott memóriacíméről log-old az adatokat és értelmezd

Segítség:: Ezt csak ASM-ban, vagy C/C++ lehet megvalósítani, megfelelő compiler és linker direktívák alkalmazása mellett.
Segítség2: 64 bit esetén nincs kód (CS), data (DS) és stack (verem) SP szegmens sem....

Tesó, ha ezt megoldod, akkor ennek van értelme (Én megoldottam, kb. 15 éve, szóval hajrá)

[ Szerkesztve ]

Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)

buffer overflow-ról volt szó, nem stack overflow( ) -ról. Ezt azért simán meg lehetne oldani. Csak az említett okok miatt nem érdemes. Sztem. legalábbis. Én hagyom, hogy false adatot írjon ki, vagy elszálljon a program...

@sztanozs:
>szóval fogalmam sincs, honnan vagy (vagy nem vagy) kitiltva

Ezt 2lem. De ha teljesen őszintén írtad, akkor én meg teljesen őszintén elnézést kérek tőled...
De akár tudtad, akár nem, ez is azt mutatja, hogy semmiképpen nem jó, ha egyes topikokbó véglegesen kitiltanak valakit. Mert semmi nem jelzi ezt. Esetleg abban a speciális esetben, ha lejjebb lapoztál volna, akkor láthattad volna, hogy a nick-em szürke...

[ Szerkesztve ]

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Buffer overflow esetén, ha a program nem száll el, akkor lehet a kód lassulása nélkül is detektálni az overflow-t, mégpedig a hívó(buffer-nek memóriát foglaló függvényben). Iteráció esetén, ha mindegyik bufferben max. a bufferek végéig találok L'\0' -t, akkor tuti, hogy nincs overflow, egyébként tuti, hogy van. Ezzel ki tudnám szűrni a #17829 - dabadab által említett viccben emlegetett hibát. Valamint még olyant is lehet csinálni, hogy lehetőséget adok a bufferek méretének manuális megadására. Pl. parancssori paraméterekkel... Ha a program elszáll, akkor esetleg ezek beállításával lehet módosítani...
Több használható 5letem nincs.

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

> biztos tudsz nyitni egy "C/CPP optimalizálás sebességre" topikot

Nem ilyen topic-ot hoztam létre, hanem A WIN API haszálata címűt. Örömmel várok oda kritikákat/kiegészítéseket. És persze az sem lenne baj, ha vki. szaki is írna példakódo(ka)t, mert azért én mégiscsak hobbiból kódolok/programozom.

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Ne kérdezzé' old meg, 15 éve megoldottam, hajrá...

[ Szerkesztve ]

Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)

Neked meg (me' tisztelek és szvsz matekot imádod és vágod, akko'), hogy lehet a 5. prímet meghatározni az ELSŐDLEGES (és egyetlen) halmazban (véletlen számosságú halmazban)
Ha ezt megoldod, akkor nem lenne PHD-M 15 ÉVE...

UI (PS)
Robogunk hazafelé, Somogyba... Hákunámátátá...

[ Szerkesztve ]

Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)

Nem itt, de szoktál ilyen feladványokat linkelni/adni....

Mondok "egyet"...

0 to 2^64-1 - ig írjuk ki az összes PRÍMET egy fájlba, 64 bites formátumba
Mindegy milyen nyelven (programozási nyelven), a lényeg hogy legyen a leggyorsabb...
Mivel sok lesz, legyen fájlba mentve (MÉGEGYSZER MONDOM 2^64-1 PRÍM)

Sok lesz bammeg(1 nap min.)... (Na majd most megmutasszuk az ASM erejét (max 2 óra)...

[ Szerkesztve ]

Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)

Egyreszt nekem nincs phd-m.
Masreszt nem ertem a fogalmakat amit hasznalsz, pedig lehet hogy jo a problema.
Primek: en me'g elso egyetemista eveim egyikeben irtam egy primek (lancolt(!)) listajaval, es tovabb nem cipelt maradekokkal dolgozo megoldast pascalban egy egyesuleti otletelgetesre (mondhatnam verseny de abbol nagyon kilogtam, ott valoban asm-mel tolta'k profik). ramdisk-en futtattak, es nekem az mar eleg volt hogy volt nalam lassabb program Talan 1M-ig kellettek a primek, es az asm szita nyert, de a futasi ido nagy resze a kiiras miatti konverziora ment el.
Itt most a max. 64 bites uint-ek erdekelnek gondolom, mert a zarojelben meg a 2^64-1 darab prim ertheto ki.
Nagy szamoknal sztem wikipedia, Miller-Rabin, es az alabbi (masok altal mar kiszamolt) feltetel: if n < 18,446,744,073,709,551,616 = 2^64, it is enough to test a = 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, and 37.
Mondjuk lehet elvi szinten jobb nagyordos algo, de nem csak a szita nem fer el hanem barmi "csak" korabbi primeket ta'rolo megoldas, igy ez lenne az elso otletem (pontosabban a masodik, az elso hogy megkeresek egy letezo algot vagy programot ... ). Mondjuk persze ez is csak elmeleti, mert 8 byte per prim, azok lesznek vagy 10^15 darab korul igy exhas meg wolframalpha, 8ezer terrabyte jol saccolok? Ha adod a disk-et amire mentsem, irom a programot

[ Szerkesztve ]

Én nem vagyok programozó, így ezt nem valószínű, hogy meg tudnám oldani.
Nem véletlenül írtam ittenke:
>Azt hiszem, hogy régebben már írtam, hogy ha most kezdenék programozni desktop-ra, akkor az ASM, C, C++ nyelvekre állnék rá nagyon.

De ha nem értetted meg, akkor szívesen lefordítom.

Nekem ilyen tapasztalataim vannak, ha nem a webprogramozást nézzük: Kevés ASM, C++, Pascal, közepes Vb6/Vba, C, viszonylag sok Vb.net, C#.
Ez helyett, ha most kezdenék, akkor sztem. ez lenne az ideális: Nagyon sok ASM és C, erősen közepes C++.

Ez tehát azt jelenti, hogy sajnos nem tudok annyira ASm-ul, C-ül.C++-ul főleg nem. De ha neked nagyon megy, akkor példakódnak elfogadnám. Sőt, azt hiszem, hogy más nevében is írhatom, hogy elfogadnánk. Tudomásom szerint ASM topic meg nincs is(vagy ha van is, akkor sem aktív).

Egyébként C-t azért közepesen használtam, mert Vb.net/C# -ban van amit vagy nem lehet megoldani, vagy meg lehet ugyan, de nagyon lassú. Ezért muszáj volt néhány esetben C-ben natív .dll-t írnom. De ezért is bántam meg, hogy nem sok C-vel kezdtem. Ugyanis így megtanultam a C#-ot, viszont a C-re is szükségem volt. De akkor minek tanultam ilyen szinten C#-ot, ha nem tudom/tudtam a C-t kikerülni. Miért nem foglalkoztam majdnemhogy kizárólag C-vel.

De egyetértek azzal, amit ittenke írtál:
>Segítség:: Ezt csak ASM-ban, vagy C/C++ lehet megvalósítani

Pontosan ezért bántam meg, hogy nem ezekre álltam rá...

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

"Csak" kb. 4*10^17 prímszám van 2^64-ig. Ha megvan a diszk, legyen aztán meg a kiírás max 2 óra alatt!

Ha viszont csak a legnagyobb prímet keressük, akkor Fermat-prímteszt.

BME MSc elvégzése után nekem egészen benne van a pakliban, hogy külföldön vállalok munkát. Aki csinált már ilyet hol kezdte? Nézzek egy magyar céget amelynek van külföldön is irodája és cégen belül próbáljak meg kijutni? Vagy relocationnel hírdetett pozikra adjam be és hátha összejön? Budapestről, remote végzett meló is igazából szóba jöhet a zsírosabb fizuért de őszintén csak ki akarok takarodni pár évre végre saját bőrömön átélni mindazt amit a hanyatló nyugat nyujthat és majd meglátni, hogy vissza akarok-e még jönni.

Tudom, hogy ez annyira nem prog téma de ti vagytok a legközelebb a kérdése témájához. Köszi előre is.

(raw_item.get("pk").unwrap().as_s().unwrap().to_string()).split("#").collect::<Vec<&str>>()[1].to_string()