CMarkup STL Platforms
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
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.
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.
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
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
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
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
strnicmp is not available in your build, you probably have an alternative function name such as
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
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
See also UNICODE ATL CMarkup - Without MFC for another way of avoiding MFC in a wide string build.
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