libc regex.h

C/C++

Helló,

a tapasztalatotok kellene.

egy kollégám szerint használjak bármit, csak ne a libc regcomp / regexec -et.
Mi a véleményetek? Kollégám indoklása: "merszar", de nekem, teljesen alap szövegértelmezéshez eddig úgytünik tökéletes.
(REG_EXTENDED flaggel).
köszi,

  • 5004 megtekintés

( uid_6201 v | 2012. 06. 27., sze – 17:23 )

>> Kollégám indoklása: "merszar"

Kicsit bővebben?

Végülis attól függ, mire kell. A regexp egy univerzális cucc. Ha univerzális keresésre van szükséged, akkor az szerintem arra jó.
De ha például egy szövegben kell egy szót megkeresned, arra nem regexp-et használnék, mivel arra az strstr sokkal gyorsabb.

Tehát a feladat és a körülmények nagyban eldöntik, mit célszerű használni.

A regexp-pel általában az a baj, hogy nagyon nehéz a kivételes esetek helyes kezelése. Egy rakás gyengébb minőségű program van, ami valami regexp-es megoldásnál hasal el egy olyan bemenetre, amire a program készítője nem számított (de a specifikáció szerint értelmes lenne).

Sokkal jobb az adatok formátumát eleve úgy megtervezni, hogy a szöveges ábrázolásból egyértelmű módon valami struktúrává lehet alakítani (xml, csv, java property file, bármi, csak pontosan legyen specifikálva benne a karakter kódolás és az eszképelés mikéntje). És utána a struktúrán lekérdezni az n. elemet immáron egyszerű címzéssel.

( szniki | 2012. 06. 27., sze – 19:57 )

Ha eltekintunk attol hogy pl. Purify uninitialized memory read hibakat jelez benne hasznalat kozben, akkor lehet hasznalhato de en is inkabb tavol maradnek tole :)

( Beanie | 2012. 06. 27., sze – 22:45 )

A GNU grepben vannak arra utaló dolgok, hogy tényleg sok memóriát zabál (rlimit-et állít be a grep). Ha nem kell szigorú POSIX, akkor használj RE2-t, sokan mondták, hogy az a leggyorsabb, bár az C++. Amúgy a a komplexitásban a TRE sem rossz, bár kisebb illesztéseknél van egy kis overhead, de jól skálázódik.