Abubakar wrote:
Hi all,
I noticed that the lstrlen is *much* slower than strlen function. Why is it
so and does that mean i should never use the lstrlen, and if not than why is
it there anyway?
Regards,
- Abubakar.
lstrlen is mostly there for historical reasons. Back in the days of 16-bit
Windows, most applications were built using the small or medium memory models
in the interest of increasing performance and reducing size (in those memory
models, the default pointer size was 16 bits, which lead to problems for
strings (or other memory blocks) that were greater than 64KB or happened to
span a 64K boundary). lstrlen was added which used 32-bit pointers (prototype
and internally), and therefore could operate on large strings and strings that
spanned boundaries. lstrlen was later updated to perform additional validation
on the parameters and would fail rather than crash Windows on bad parameters.
Additionally, lstrlen is a Windows function (dynamic link) where strlen is a
library function (static link, unless you link in the CRT as a DLL). Static
linked functions will _always_ be faster than than an identical counterpart
that is dynamically linked.
lstrlen is also actually a macro to lstrlena or lstrlenw, which maps to the
appropriate function depending on whether or not you are building to Unicode or
not. strlen is always single-byte (SBCS), so if you want similar
functionality, you should get in the habit of using the tchar string functions
declared in tchar.h.
So, unless you have a specific need to use lstrlen (it sounds like you don't),
get in the habit of using the tchar version _tcslen().
