Update September 27, 2008: With CMarkup release 10.0 things have gotten simpler than ever. Using STL strings in Visual C++ has been streamlined, and for other compilers CMarkup defaults to STL strings so you don't need to do anything but add CMarkup to your project and go. See Unified CMarkup for STL and MFC.
Pass STL string variables directly into the constant string (MCD_CSTR) arguments of the CMarkup methods, no need to explicitly add the c_str() method.
CMarkup with STL has been tested on Dev-C++, OSX XCode, and Visual C++ Express 2005 and 2008.
Using CMarkup with STL
Just copy Markup.cpp and Markup.h into your C++ project. In Visual C++ the are a couple of additional steps to be aware of. To use STL strings in VC++, you must put MARKUP_STL in your project defines. For VC++ projects that use precompiled headers you will need to turn off precompiled headers individually for Markup.cpp (see Pre-compiled Header Issue).
For STL users moving to release 9.0 from previous releases, use the "CMarkup" class name instead of "CMarkupSTL" and include Markup.cpp/.h in your project, not MarkupSTL.cpp/.h!
STL stands for Standard Template Library, a set of C++ classes standardized across a number of C++ compilers for different platforms. There are often small inconsistencies in the various implementations of STL, so you cannot assume your source code will immediately compile with every STL implementation. As on any platform, CMarkup has no warranty and in any project it is the responsibility of the developer who uses it.
All of the sample code and documentation about CMarkup applies equally to both MFC and STL usage except where noted. Although most of the CMarkup examples use CString, they will also work equally with std::string. What follows are some experiences with the STL version on various platforms and other STL specific information.
Yes you can. Use STL strings and put MARKUP_STL in your project defines. The STL std::string class comes with most C++ compilers, and Markup.h will #include <string> if you define MARKUP_STL.
In Visual Studio, CMarkup defaults to use CString and tries to link in its dependencies. To use STL std::string instead please define MARKUP_STL in your preprocessor definitions as mentioned above.
Archived experiences before release 9.0
Notes on previous versions of CMarkup remain here in case they can illuminate current issues that arise such as with additional new compilers.
All fixes to CMarkupSTL prior to release 9.0, have been brought forward into the STL version of CMarkup in release 9.0.
CMarkupSTL release 6.0 compiled on Borland C++ Builder 5 (in Windows ME) after a couple of tweaks in MarkupSTL.cpp. These tweaks were brought into subsequent releases of CMarkup.
In CMarkup release 6.0 and earlier, you have to remove the #include "stdafx.h" (it is gone in release 6.1). Then, cast the first argument in the strchr call to char* because Borland apparently doesn't have a strchr(const char*,int) version of this function. There were about 6 warnings due to the STL size type being unsigned in Borland and signed in Microsoft. Casting the complaining string methods and members to int in MarkupSTL.cpp quieted the warnings: e.g. (int)string::npos and (int)m_strDoc.length().
In release 6.2 and before, CMarkupSTL used the itoa function which is not available on some platforms. In release 6.3 and later, sprintf is used instead.
According to Dharmesh and other testing by Tobias, CMarkupSTL works on Linux. Prior to release 6.4 you needed to add #include <stdio.h> to the top of MarkupSTL.cpp, but it has since been included.
On this Palm OS platform int is only a 16 bit integer, so it is recommended you change all occurences of int to long. Especially in the Developer version's DecodeBase64 function where it was causing an overrun resulting in a 00 every 2 bytes.
It turns out that strnicmp (like stricmp, ignore case string comparison) is not part of standard C and in different compilers is made available with different names. Unix and Mac compilers (and even Borland C++ Builder for Windows) seem to have strnicmp, while Turbo C and Watcom C have strncmpi.
Microsoft seems to be the only one that has _strnicmp with an underscore. But the strnicmp function without underscore is available in Visual C++ unless __STDC__ is defined or you don't link with oldnames.lib. The test builds for CMarkupSTL in Visual Studio 6.0 and .Net work without the underscore so this issue was not discovered before 8.0 was released. Prior to release 8.0 this was unlikely to be encountered because ignoring case was not a runtime option and very few users compiled with MARKUP_IGNORECASE defined.
If strnicmp is not available in your build, you probably have an alternative function name such as _strnicmp or strncmpi with the exact same arguments. You can probably define it in your project preprocessor definitions (i.e. -Dstrnicmp=_strnicmp), or above where you include MarkupSTL.h using one of these forms:
#define strnicmp _strnicmp
#define strnicmp(s1,s2,n) _strnicmp((s1),(s2),(n))
Or just replace the function call itself inside MarkupSTL.h.
If by "pure" C++ you mean to include STL strings then the STL version should be adequate.
Update April 1, 2007: Beginning with CMarkup release 9.0, for the STL version you use Markup.cpp/.h (not MarkupSTL.cpp/.h) and define MARKUP_STL.
Update April 1, 2007: CMarkup release 9.0 introduces support for STL/UNICODE, for Visual C++ out of the box, and for other C++ compilers as well by setting some defines.
I'm guessing you want to use STL with Visual C++ but without MFC, so you want to use the VC++ wide string functions and defines. This is supported in release 9.0.
Update April 1, 2007: CMarkup release 9.0 introduces UNICODE support for the STL version of CMarkup.
See also UNICODE ATL CMarkup - Without MFC for another way of avoiding MFC in a wide string build.
Unresolved external symbol __endthreadex
zhuzl 28-Jun-2007
I am a student of BUAA; our lab uses Linux. Can I use CMarkup in Linux?