Still Need Help With Unicode IO

[Mike Pliam]

Attempting to port code from VS 2010 to VS 2017 I have found that a single code method is breaking my newly ported apps. This was originally a daunting problem in VS 2010, but you gurus helped me to sort it out. For reference please see: http://www.codeguru.com/forum/showthread.php?t=511113

Now VS 2017 breaks after the read or write method completes it's task. My rather amateur debugging skills have failed to elucidate the problem and once again I turn to you for help.

// writes a map<wstring, wstring> to disk where:
int CFuncMap::write_map(wstring wsFilepath)
{
	wchar_t wbuf[256];
	wchar_t wch = 0x0002;
	wstring wsmapsize = _T("");
	wstring wsfuncnam =  _T("");
	wstring wsfunc =  _T("");

	size_t mapsize = m_table.size();
	swprintf_s(wbuf, _T("%d"), mapsize);
	wsmapsize = wstring(wbuf);

	if (mapsize == 0) { _RPT0(0, "map is empty\n"); }

	//fstream f;
	//f.open(wsfilepath.c_str(), ios::out|ios::binary);

	wfstream wf;
    codecvt_utf16<wchar_t, 0x10ffff, little_endian> ccvt(1);
    locale wloc(wf.getloc(), &ccvt);
    wf.imbue(wloc);

	wf.open(wsFilepath.c_str(), ios::out | ios::binary);
	if(!wf) { swprintf_s(wbuf, 256, _T("Unable to open file %s"), wsFilepath.c_str()); CError::SetCustomError(  wbuf );  return 0; }
 
	wf.write(&wch, (streamsize) 1);
	wf.write((wchar_t *) wsmapsize.c_str(), (streamsize)(wsmapsize.size()));

	for(ii=m_table.begin(); ii!=m_table.end(); ++ii)
	{
		wsfuncnam = (*ii).first; 
		wf.write(&wch, (streamsize) 1);
		wf.write((wchar_t *) wsfuncnam.c_str(), (streamsize)wsfuncnam.size());
		wsfunc = (*ii).second;
		wf.write(&wch, (streamsize) 1);
		wf.write((wchar_t *) wsfunc.c_str(), (streamsize)wsfunc.size());

	}
	wf.close();

	return 1;

}// write_map(wstring wsFilepath)

The break is inserted at the end of the method, after 'return 1;'. What is happening here ? Any help greatly appreciated. Thanks.

[Arjay]

Are you compiling for UNICODE or MBCS?

[Mike Pliam]

Thanks, Arjay. Turns out there are two projects in the solution, one a dll (Unicode), the other an MFC (char set not defined). Suspecting that may be the problem, since the dll compiles without problems, I changed the old MFC project to Unicode in all configurations (which I should have done long ago but was too lazy). I am now confronted with 280 compilation errors. I'll get back to you after I've sorted through these.