Platform-Specific Notes

In this topic:

Windows platform with Microsoft compilers

Str Library will run unmodified ("out-of-the-box") when incorporated in a Windows application or DLL project, compiled with Microsoft Visual Studio versions 6.0, 2002 and 2003

The library will configure itself for the Windows environment with the STR_WIN32 conditional define, which the Wizard will add to your configuration file automatically.

Under Windows, the library can support either only ANSI strings, or ANSI and Unicode strings. The default string mode will be determined by the Microsoft-standard defines but can also be overridden with STR_ANSI and STR_UNICODE

Str Library can run either as the only string handling class in your application, or alongside STL's basic_string<> or MFC/ATL's CString. Of course, the best performance improvements will be realized when using predominantly Str Library.

Windows platform with Borland C++ Builder

Str Library will run unmodified when added to a Windows application or DLL built with Borland C++ Builder v6 or later. The library will automatically detect the Borland compiler environment and adjust accordingly.

One of the library classes - Char - is renamed under Borland C++ to prevent conflicts with the Borland VCL. See details .

Windows CE platform with Embedded Visual Studio 4.0

Str Library can be used in Windows CE applications and DLLs built with Microsoft Embedded Visual C++ version 4.0 (earlier versions are not officially supported)

Running the Wizard and specifying a Windows CE target will cause the Wizard to copy a "customized" version of the library to your EVC project tree. The only customizations are the "commenting out" of several #include directives which are not normally needed anyway. The EVC compiler and linker have a bug whereby they will erroneously report a warning in the following situation:

#ifdef SYMBOL_THAT_IS_NOT_DEFINED
#include "will_be_reported.h"
#endif

The Wizard will prevent these spurious errors by commenting out the appropriate lines.

Windows CE only natively supports the Unicode character set. Thus, the native build mode of the library will always be Unicode.

By default, newly created Windows CE projects have support for exception handling turned off, which will cause Str Library to refuse to compile. There are two solutions to this problem:

Instruct the library to avoid using exception handling by defining STR_NO_EXCEPTIONS. Note that in this mode, you won't be able to access extended library features such as the StrArray class and regular expressions
Turn on exception handling support in your CE project by adding the /GX switch in the compiler options dialog for all appropriate configurations. Note that early releases of EVC combined with certain targets will refuse to link a project with /GX turned on; you need to add an additional object module to the linker specification. Further information is available on the Internet.

Linux, FreeBSD and other platforms supporting gcc

Str Library is compatible with gcc versions 3.1 and later (and even with gcc 2.95 with a special flag ). When compiling for Linux, FreeBSD or any other supported *x environment, the conditional define STR_LINUX should be declared (Add Str Wizard will do this automatically, if you are using the Wizard)

Str Library supports both ANSI and Unicode encoding in these environments. However, when compiling in Unicode mode, every character will occupy 32 bits of storage - unlike all Windows and Windows CE platforms where, by convention, Unicode characters use 16 bits.

There is no support for multithreading within a single Unix process in these environments. Clients must ensure thread safety if they are using the multithreading support in recent Linux kernels and accessing Str objects from different threads simultaneously.