 |
|
 |
Thank you man, you saved me a lot of time.
|
|
|
|
 |
|
 |
Hi
there's no doubt that these functions are not part of the CRT
I was looking for similar functionality for a program I was writing recently
anyway, i think that your _tcsistr won't work properly for multibyte code pages. To advance to the next character you should use CharNext instead of string++; that's the only way you can ensure you'll be on the correct start of any generic character
this won't show unless a trully multibyte system is tested
|
|
|
|
 |
|
 |
I have tested these functions with ANSI and Unicode (UTF-16) apps and they work fine. I have not tested with non-UTF-16 multi-byte apps - those requiring more than two bytes per character.
|
|
|
|
 |
|
 |
I didn't see an advantage of using this functions instead of the crt. Can you explain it?
And why not using TCHARs nor _UNICODE?
|
|
|
|
 |
|
 |
I agree, there are no advantages that I can see. But also, why even use C string functions when STL has a string class? Surely that would be less prone to bugs and has more functionality like proper search functions with iterators.
|
|
|
|
 |
|
 |
René Greiner wrote:
I didn't see an advantage of using this functions instead of the crt
If you had taken the time to check, you would have found that none of these functions are in the crt.
René Greiner wrote:
And why not using TCHARs nor _UNICODE
The mem* functions don't use TCHAR because they are byte-oriented and deal with values in memory. The _tcsistr function uses LPTSTR and LPCTSTR. Last time I looked, this was correct usage for Unicode.
OTOH, I may be missing something. Does your crt include these functions? Do your mem* functions deal with TCHARs? If so, please post the function prototypes here - I'd like to see them.
|
|
|
|
 |
|
 |
What if I want to find the 2nd matching char in a string? I can't do that with your functions, unless I do some pointer arithmetic.
There appear to be quite a few functions in the crt that do what your code does already: _lfind, strspn, strpbrk, etc, etc.
|
|
|
|
 |
|
 |
dog_spawn wrote:
quite a few functions
That might be true. but none of the functions that you list do that.
Specifically:
- _lfind - requires a user-supplied compare routine and is NOT Unicode aware (unlike _tcsistr, which is Unicode-aware)
- strspn - returns the index of the first character in string that does not belong to the set of characters in strCharSet. Which of the four functions listed in the article are you comparing strspn with?
- strpbrk - returns a pointer to the first occurrence of a character in string that belongs to the set of characters in strCharSet. Again, what are you comparing this to?
It really doesn't make sense to compare any of the functions in your list to the four functions in the article. I suspect that you have never really used crt functions like strstr, or memchr, or you would not be making such ridiculous and irrelevant comparisons.
I look at these functions as something that probably should have been in the crt, but were never added. I noticed in reading some Linux docs that some of these have been included in the latest Linux release, so maybe in time they will find their way into the MS crt. Until then, you can use _tcsistr or your _lfind, but check your facts first.
|
|
|
|
 |
|
|
 |
|
 |
Thank you for sharing your excellent code, sir. I was having trouble searching for a string content delimiter in an IP stream stored in char buffer - needless to say, full with '\0' chars inside - which makes use of strstr a bit hard. For my app, I couldn't use _lfind, since I couldn't really solve the class relationship so that the compare function could be properly cast. The memmem worked like a charm!
Just one note, in my app I had a problem
fatal error C1010: unexpected end of file while looking for precompiled header directive
it got solved by including "stdafx.h" as first in XMemString.cpp, as described here: http://www.tek-tips.com/viewthread.cfm?qid=1109224&page=1[^]
|
|
|
|
 |
|
 |
Thank you for the kind words.
junksmi wrote:
Just one note, in my app I had a problem
fatal error C1010: unexpected end of file while looking for precompiled header directiv
As the article says, If you include XMemString in project that uses precompiled headers, you must change C/C++ Precompiled Headers settings to Not using precompiled headers for XMemString.cpp.
|
|
|
|
 |