I am using the wxWidgets libraries, so I am interested in the support for the wxString class, which seems to be already (partially) implemented. I currently don't quite understand, why the library doesn't consequently use the existing string abstraction (Cpp8BitString/Cpp16BitString/CppString), but hard-wires std:string at some places. This causes problems, when using the ULXR_WXSTRING define, since this introduces unnecessary string conversions.
Wouldn't it be possible to use Cpp8BitString instead of std::string (which defaults to std::string)? Or is there another reason for the code as it is?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the only reason is having forgotton about it :-) The original intention was exactly what you wrote.
I will do a quick search-replace.
I am currently trying to port the smem class to unix. There remains mainly one problem.
From my understanding the following code fragments do the same (except from thread safety)
If you want to have your code included, you should download from svn and send me patches, for example using "svn diff". A diff against a previous version should work in most cases, too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>the only reason is having forgotton about it :-) The original intention was exactly what you wrote.
>I will do a quick search-replace.
Great, however, you missed a couple of places. Also in the contrib section, the replace must be against 'ulxr::Cpp8BitString'. Here is a patch against the latest SVN that corrects these issues and also fixes the wxString support.
I have no idea what happend, but a lot of changes to std::string have gone (or were not applied). For that reason the patches were not all applied automatically but I had to do myself. But I think I managed to apply everything :-)
There remains only one issue which is probably based on a misunderstanding:
In 8bit mode all strings are expected to have the correct encoding. Be it utf8 or latin1 or some win codepage. So no changes are allowed within the lib. This differs from very early versions before 2005, see ChangeLog and http://ulxmlrpcpp.sourceforge.net/handbook/unicode.html. Please let me know if the docs are unclear.
greets
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The misunderstanding comes from the fact that I didn't RTFM ;-), at least not completely.
Sorry.
I have prepared another patch against the latest SVN with some remaining issues. The patch is against the source directory, i.e. against trunk/ulxmlrpc/ulxmlrpc.
in ulxr_value.cpp I had to add some (char) casts for some tokens, needed for the wxString configuration.
in va1_client.cpp I had to work around a bug in wxString.
in contrib some Cpp8BitString missed the namespace ulxr::.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using the wxWidgets libraries, so I am interested in the support for the wxString class, which seems to be already (partially) implemented. I currently don't quite understand, why the library doesn't consequently use the existing string abstraction (Cpp8BitString/Cpp16BitString/CppString), but hard-wires std:string at some places. This causes problems, when using the ULXR_WXSTRING define, since this introduces unnecessary string conversions.
Wouldn't it be possible to use Cpp8BitString instead of std::string (which defaults to std::string)? Or is there another reason for the code as it is?
Hello,
the only reason is having forgotton about it :-) The original intention was exactly what you wrote.
I will do a quick search-replace.
I am currently trying to port the smem class to unix. There remains mainly one problem.
From my understanding the following code fragments do the same (except from thread safety)
if ( InterlockedCompareExchange ( &m_pBuf->m_WriteStart, nextIndex, blockIndex ) == blockIndex )
return pBlock;
const bool eq = m_pBuf->m_WriteStart == blockIndex;
if (eq)
{
m_pBuf->m_WriteStart = nextIndex;
return pBlock;
}
If you want to have your code included, you should download from svn and send me patches, for example using "svn diff". A diff against a previous version should work in most cases, too.
>the only reason is having forgotton about it :-) The original intention was exactly what you wrote.
>I will do a quick search-replace.
Great, however, you missed a couple of places. Also in the contrib section, the replace must be against 'ulxr::Cpp8BitString'. Here is a patch against the latest SVN that corrects these issues and also fixes the wxString support.
http://www.elementec.de/download/code/wxString-Support.patch
Your version of InterlockedCompareExchange is correct, just needs to be protected as critical section to be fully equivalent.
Hello,
I have no idea what happend, but a lot of changes to std::string have gone (or were not applied). For that reason the patches were not all applied automatically but I had to do myself. But I think I managed to apply everything :-)
There remains only one issue which is probably based on a misunderstanding:
- getConnection()->write(xml.c_str(), xml.length());
+ Cpp8BitString utf = asciiToUtf8(xml);
+ getConnection()->write(utf.c_str(), utf.length());
In 8bit mode all strings are expected to have the correct encoding. Be it utf8 or latin1 or some win codepage. So no changes are allowed within the lib. This differs from very early versions before 2005, see ChangeLog and http://ulxmlrpcpp.sourceforge.net/handbook/unicode.html. Please let me know if the docs are unclear.
greets
Ok, I got it.
The misunderstanding comes from the fact that I didn't RTFM ;-), at least not completely.
Sorry.
I have prepared another patch against the latest SVN with some remaining issues. The patch is against the source directory, i.e. against trunk/ulxmlrpc/ulxmlrpc.
http://www.elementec.de/download/code/wxString-Support-2.patch
in ulxr_value.cpp I had to add some (char) casts for some tokens, needed for the wxString configuration.
in va1_client.cpp I had to work around a bug in wxString.
in contrib some Cpp8BitString missed the namespace ulxr::.