Maybe... I'd just consider using the 1st way if you would encounter different encodings in the future. Maybe you'd just roll your own conversion layer that then can host either 'wcstombs*()' or 'WideCharToMultiByte()', depending on your future requirement. Just Something like 'MyProjectUtils::ConvertoANSI()'.
Hopefully this is a one time thing for a special requirement. I am a report writer who happens to be able to write code. The last serious programming I did was in 2001 in VB6.
mlmcc
sarabande
a little remark apart from this question:
if using visual c++ compiler for the dll you may consider to passing std::wstring to the dll and handle the strings in the dll. most report libraries for windows can handle wide strings (utf16/ms unicode) same as (or even better than) ansi strings. also if you want to return strings from dll, you could avoid a reverse conversion (with possible issues, for example if utf-8 characters are involved).