[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with std::codecvt::out()
From: |
JH Trauntvein |
Subject: |
Re: Problem with std::codecvt::out() |
Date: |
5 Dec 2005 10:58:00 -0800 |
User-agent: |
G2/0.2 |
JH Trauntvein wrote:
> In the folloiwng code fragment, I am attempting to convert a multi-byte
> string into a wide string using the std::codecvt::out() function. I
> have found that when I do so, the compiler complains that it cannot
> find a match but then proceeds to list an exact match as the one and
> only candidate.
>
>
> using namespace std;
> String rtn;
> char temp[MB_LEN_MAX];
> wchar_t val = static_cast<wchar_t>(m_c);
> mbstate_t state = { 0 };
> wchar_t *next1;
> char *next2;
> int result;
>
> result = use_facet<codecvt<wchar_t, char, mbstate_t> >(locale).out(
> state,
> &val,
> &val + 1,
> next1,
> &(temp[0]),
> temp + sizeof(temp),
> next2);
> if(result != codecvt_base::error)
> rtn = String(temp,next2);
> return rtn;
>
> Here is a copy of the compiler error message:
>
> /home/jon/work/cora/coratools/advxml/Elements.cpp: In member function
> 'virtual AdvXMLParser::String AdvXMLParser::CharRef::GetData()
> const':
> /home/jon/work/cora/coratools/advxml/Elements.cpp:471: error: no
> matching function for call to 'std::codecvt<wchar_t, char,
> mbstate_t>::out(mbstate_t&, wchar_t*, wchar_t*, wchar_t*&, char*,
> char*, char*&) const'
> /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/codecvt.h:121:
> note: candidates are: std::codecvt_base::result
> std::__codecvt_abstract_base<_InternT, _ExternT,
> _StateT>::out(_StateT&, const _InternT*, const _InternT*, const
> _InternT*&, _ExternT*, _ExternT*, _ExternT*&) const [with _InternT =
> wchar_t, _ExternT = char, _StateT = mbstate_t]
>
> Regards,
>
> Jon Trauntvein
I should say that my code is rather trying to convert a wide character
into an appropriate multi-byte sequence for the given locale. I git
confused because I have other code that performs the opposite
conversion. I would also point out that the compiler does not seem to
have a similar problem when I invoke codecvt::in()
Regards,
Jon Trauntvein