The string representation remains the same, which is a std::string
between C++ clients. It is the *transmission* of the std::string on the
wire between the client and the server that transforms the string from
0-255 byte values to UTF-8.
So it should be transparent to the user. Your example should still work
when encoded to UTF-8, transmitted on the wire, and decoded back into a
character string (ie. treat 0xC4 as one character and 0x84 as the
subsequent character in the std::string).
Unless of course you are talking about a Java client transmitting a
character value greater than 255 across the wire to a C++ client. Then
of course, this will not work. It would not have worked in previous
versions either.
rainy3 said the following on 9/1/2009 8:52 AM:
The CMS API doesn't currently have methods for dealing with multibyte C++
strings so strings are expected to be encoded with values from 0-255.
So, with new ActiveMQcpp C++ consumer won't be able to reconvert a text
message with UTF-8 char for example 0xC484 (this char stays for one letter
which looks like 'A,'). It's kinda sad cause old consumer was able to deal
with this (it was using iconv to reconvert text message from UTF-8 to proper
charset and it was working like a charm). Now, i guess, only way to make
this still possible is to rewrite both producer and consumer to use binary
messages. Maybe, in a future releases of ActiveMQcpp, there would be a
chance for some kind system dependend compilation to allow linux/unix
systems with native iconv support to deal with those kind of text messages?
