comment posted ATL UNICODE No MFC

John Xu 2-Jul-2004

Currently my project is Non MFC with Unicode (ATL). I am using CMarkupSTL. But looks like CMarkupSTL doesn't have the Unicode support.

Update April 1, 2007: CMarkup release 9.0 introduces UNICODE support for the STL version of CMarkup.

If you are using Visual Studio 7.0 (VS.NET), you can use CString without MFC (CAtlString). Release 7.0 of CMarkup only uses CString and no other MFC classes, and it has been tested with ATL (non MFC). Just add Markup.cpp and Markup.h to your ATL project and make the following changes:
In Markup.cpp, remove #define new DEBUG_NEW
In Markup.h, add #include <atlstr.h>


comment posted CMarkup and ATL

Peter Weyzen 27-Jun-2003

I am interested in CMarkup -- is there a non-MFC version? Is that the same as the STL version? Does the STL version work perfectly on VS.NET2003? I am evaluating the addition of XML support to a server product... Do you think your product is appropriate for that?

What about UNICODE and STL together. I downloaded and attempted to install the evaluation version, but there's no UNICODE support in the STL version... I guess I could wrap it in class which downgrades all of the strings to MBCS...?

Have you considered a "ATL" version? In VS.NET 2003, they introduced a CString like class available via the ATL classes. If you're not MFC, CString redirects into CAtlString. CAtlString is my new friend -- great string class with UNICODE in it... API compatible to CString. How dependent on MFC is the code? Is there much more than CString? Or does the MSXML want MFC?

Solution: ...changed CString to CAtlString and CMap to CAtlMap. All compiles, no MFC.

Update April 1, 2007: CMarkup release 9.0 introduces UNICODE support for the STL version of CMarkup.

This question was asked for CMarkup release 6.5. CMarkup release 7.0 has been tested in an ATL UNICODE build with a couple of small changes. Note also:

  • Release 7.0 has eliminated dependence on foundation class (MFC or STL) array and map classes.
  • Prior to release 9.0, the CMarkupSTL class did not support a UNICODE wide char build but CMarkup 9.0 can be compiled for STL UNICODE.
  • The MSXML-based version called CMarkupMSXML compiles in UNICODE and it uses only the MFC CString, no CArray or CMap. MSXML itself does not require MFC.

    comment posted Warnings when compiling CMarkup Release 6.5 with MS VC++ .NET 2003

    Tony Nancarrow 04-Jun-2003

    I have just started using Visual C++ .NET 2003. I notice that a few warnings are generated when compiling CMarkup.cpp.

    d:\...\CMarkup\Markup.cpp(793) :
    warning C4244: '=' : conversion from '__w64 int' to 'int',
    possible loss of data
    d:\...\CMarkup\Markup.cpp(1060) :
    warning C4244: '=' : conversion from '__w64 unsigned int' to 'int',
    possible loss of data
    l:\...\Vc7\atlmfc\include\afxtempl.h(398) :
    warning C4244: 'initializing' : conversion from '__w64 int' to 'size_t',
    possible loss of data
    l:\...\Vc7\atlmfc\include\atlsimpstr.h(387) :
    while compiling class-template member function
    'void CArray<TYPE,ARG_TYPE>::SetSize(INT_PTR,INT_PTR)'
                ARG_TYPE=CMarkup::ElemPos &
    d:\...\CMarkup\Markup.h(153) :
    see reference to class template instantiation
    'CArray<TYPE,ARG_TYPE>' being compiled
                ARG_TYPE=CMarkup::ElemPos &

    The workaround to eliminate the warnings seems to be to switch off the option "Detect 64-bit portability issues" (/Wp64) on the C/C++ General page of the Project Properties. This option is on by default. For most projects (including my own) these warnings are harmless and can safely be ignored. They would only be an issue if somebody wanted to port their code to a 64-bit platform at a later date.

    It may be worth mentioning this on your Web Site in case anybody is worried by these warnings. Maybe the code can be changed slightly to avoid these warnings in the next release?

    Code that was generating warnings was fixed in release 7.0 Markup.cpp and release 7.1 MarkupSTL.cpp.