IT-Consultant: Frederick J. Harris > Discussion

Moving TCLib Into Mainstream

<< < (2/17) > >>

James C. Fuller:
Fred,
  Good stuff. I'll look at it in the AM.

James

Patrice Terrier:
Fred

Once you are done with it, i have some good candidates to check your TCLib with VS Community 2015.

...

James C. Fuller:
Fred,
  You have UNICODE defined in your Strings.cpp file. I did not think your class was for unicode use only?
Why did you name stricmp _stricmp. All others strcpy, strcat, strcmp are defined without the underscore?

I needed this one :

--- Code: ---//=====================================================================================
//               Developed As An Addition To Matt Pietrek's LibCTiny.lib
//                            By James C. Fuller March 2016
//
//                      cl strchr.cpp /c /W3 /DWIN32_LEAN_AND_MEAN
//=====================================================================================
#include <windows.h>
#include "string.h"

char * __cdecl _strchr (const char *s, int c)
{
    do {
        if (*s == c)
        {
            return (char*)s;
        }
    } while (*s++);
    return (0);
}

wchar_t * __cdecl _wcschr (const wchar_t *s, int c)
{
    do {
        if (*s == c)
        {
            return (wchar_t*)s;
        }
    } while (*s++);
    return (0);
}

--- End code ---

I am set up at present to only use and compile 64bit unicode source with TCLib
All your demos except Demo18 I believe are in that format?
Can you do a Demo18 for unicode 64bit?

I needed to tweak a few items but first impressions are good.

James

Frederick J. Harris:
Everything should work in either asci or wide, x64 or x86, VS 2008 or VS2015, although to be honest I'm starting to slack off a bit in my testing of x86.

Yes, my String Class is set up to work with either ascii or unicode.  To use unicode the main calling *.cpp files should have #define UNICODE in them, and it should also be defined in Strings.cpp.  If its undefined in both (or multiple) places then the ascii takes over.  The reason I frequently use this construct...


--- Code: ---#ifndef UNICODE
#define UNICODE
#endif
#ifndef _UNICODE
#define _UNICODE
#endif

--- End code ---

...is because the Visual Studio IDE predefines the wide character set, so if I didn't use the #ifndef, warnings would be generated on multiple definitions of the equate.  Of course, CodeBlocks doesn't predefine wide character, and I like my sourse to be able to be compiled in both without warnings, so that's where that comes from.  Neither GCC nor VC++ predefine wide character; its just an issue with the Visual Studio IDE.

I've been fighting the whole wide character thing with C/C++ since the beginning in the late 90s.  By fighting with it I mean trying to come up with the easiest way of dealing with it.  I think the end result of that for me is to leave Strings.cpp and Strings.h coded with the tchar macros, which of course are horribly ugly, but in my other source files just do the #defines of UNICODE and _UNICODE, and use the non-tchar forms, i.e., wcslen, wcscat, wcscpy, etc.  And of course preface string literals with L.

I've had philosophical discussions of this issue at www.cplusplus.com with other coders, and that's the way I like to handle it.  Let me pose for a moment some of the issues.  And let me bring up the Forger's Win32 Tutorial (a popular C++ destination for folks learning Win32).  All the code there is quite good, but when folks try to compile it with Visual Studio, they immediately get errors due to Visual Studio pre-defining the wide character set.  For example, CreateWindowEx is used in that tutorial to create windows, and there is no specification in the code as to the character set being used.  Therefore, it will compile fine with CodeBlocks using GCC, but not with Visual Studio due to the latter's propensity to specify the wide character set. 

Of course, to solve the problem one could strictly use the tchar macros for absolutely everything as Petzold's last Win32 book does (version 5 or 6; I forget which).  But they are just so horrible!  The personal solution I have come up with is to use the #ifndef setup I first described.  That allows my code to be correct no matter what Windows compiler is used. 

Frederick J. Harris:
In terms of _stricmp, this is from my main C reference written by Peter Aitken and Bradley Jones...


--- Quote ---String comparison functions that are non-case-sensitive operate in the same format as the case sensitive function strcmp.  Most compilers have their own non-case-sensitive comparison functions.  Zortech uses the library function strcmpl().  Microsoft uses a function called _stricmp().  Borland has two functions strcmpi() and stricmp().  You need to check your library reference manual to determine which function is appropriate for your compiler...

--- End quote ---

Navigation

[0] Message Index

[#] Next page

[*] Previous page