-
Take a look at the XmlRpcClient constructor documentation:
//! Construct a client to connect to the server at the specified host:port address
//! @param host The name of the remote machine hosting the server, eg "myserver.mycompany.com"
//! @param port The port on the remote machine where the server is listening
//! @param uri An optional string to be sent a.
2008-10-08 05:15:21 UTC in XmlRpc++
-
As you say, maybe the compiler would like an explicit temporary.
VC 6 is broken in many ways. Given that vc++ 2005 and 2008 are free to download and use, maintaining vc 6 compatibility doesn't seem very important.
But you are not understanding swap if you think it will double the memory use. It does not copy the memory, it simply exchanges the pointer values of the internal char* buffers.
2008-08-21 13:57:22 UTC in XmlRpc++
-
If there is interest, I could package a release of the current cvs code which cleans up bugs and compiler issues, adds support for win64 and (untested) openssl support if there is interest. I have not gone any further with the multithreaded server code though, so that is not ready.
I haven't compiled on linux in a while, so I should give that a shot before releasing anything.
2008-08-21 03:24:40 UTC in XmlRpc++
-
How about just adding the values to the iterators directly rather than iteratively:
...
std::string::const_iterator startIt = valueXml.begin() + *valueOffset;
std::string::const_iterator endIt = valueXml.begin() + valueEnd;
...
Regarding your second point in the first message, the typical idiom for releasing memory from std::strings and std::vectors is to use swap with a temporary...
2008-08-21 03:20:01 UTC in XmlRpc++
-
> Is there a new 'official' release being planned anytime in the future?
Yes. I recently started a project that will (probably) use xmlrpc++ and that prompted me to check in some of the accumulated bug fixes and portability fixes. There are a couple more bug fixes that need to get in, then I will make a new release.
2008-06-19 20:09:22 UTC in XmlRpc++
-
As far as I can tell, the xml rpc spec doesn't talk about encoding. Although an earlier version specified that strings were ascii, that wording has been removed but not replaced with anything else, letting the issue be handled by the xml encoding attribute.
This link has some useful info: http://effbot.org/zone/xmlrpc-errata.htm
I think what I will do is:
1. Make UTF-8 encoding the defaul.
2008-06-17 14:13:50 UTC in XmlRpc++
-
The changes I suggested were not for the xmlrpc++ code, that compiles fine on linux (usually).
The changes were intended for his code, which used a mix of xmlrpc++ and winsock calls.
2008-06-17 13:53:52 UTC in XmlRpc++
-
You need to remove or conditionally compile the Windows specific code, and in some places replace it with the equivalent linux code.
For example, replace the lines:
WSAData wsaData;
SOCKET sd;
with:
#if defined(_MSC_VER) // The next lines will only be compiled under MSVC++
WSAData wsaData;
SOCKET sd;
#else // The next lines will not be compiled under MSVC++
i.
2008-06-13 22:38:19 UTC in XmlRpc++
-
I don't understand what the goal is here.
The only situation where encoding comes into play is the handling of strings.
If the library provided a hook to specify the content encoding header (and also changed the default encoding to utf8 since that is most common), the app programmer can provide strings in whatever encoding they want. std::string is just a vector of bytes, it doesn't impose.
2008-06-13 17:20:07 UTC in XmlRpc++
-
Just make your response value an array or struct.
2008-06-13 16:47:53 UTC in XmlRpc++
