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

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.

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)'
        with
        [
            TYPE=CMarkup::ElemPos,
            ARG_TYPE=CMarkup::ElemPos &
        ]
d:\...\CMarkup\Markup.h(153) :
see reference to class template instantiation
'CArray<TYPE,ARG_TYPE>' being compiled
        with
        [
            TYPE=CMarkup::ElemPos,
            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?