> Yes, something like that. The least "expensive" (from manhours POV) is to
use ostringstream. I have found that in most cases when I would need that
spec. string looks exactly like the above case of yours, which is
equvivalent to this:
ostringstream ostr();
out << "Hello world." << 123;
string str(ostr.str();
Give a library using COW strings, this is just as efficient (or inefficient
in MT :-)) as using that special wrapper-thing.
What are the COW strings??
I solved it this way: (but it's not what I needed/wanted)
/////////////
#include <iostream>
#include <sstream>
#include <string>
class xostream : public std::ostringstream {
protected:
std::string & str_;
public:
xostream (std::string & s) :
str_(s),
std::ostringstream(s,std::ios::ate|std::ios::app)
{ }
~xostream ()
{ str_ = str(); }
};
// and then:
using namespace std;
int main(int,char*[]){
string data = "Hello1";
{
xostream file(data);
file << "\nHello2"
<< "\nInt: " << 12
<< "\nFloat: " << 123.3456 << std::endl;
}
std::cout << data << std::endl; //produces unbelievable result !!
return 0;
}
////////
But there seems to be a bug in libraries - it produces different
output when compiled by different compilers:
Microsoft Visual C++ .NET 2002 / VC 6.0 (Incorrect):
Hello2
Int: 12
Float: 123.346
Microsoft Visual C++ 2005 (Correct):
Hello1
Hello2
Int: 12
Float: 123.346
Looks like there are problems with ostringstream in older versions.
to avoid problem:
xostream::xostream (std::string & s) : str_(s),
std::ostringstream(std::ios::ate|std::ios::app)
{ *this << s; }
/**/
as to the "The least "expensive" (from manhours POV)" - It's not work
or anything - it's my own idea (unrelated to job). So, I'm not looking
for easy ways :)
Originally it was to create a virtual filesystem for a small my
private project.
It stored "files" in a std::map<string,string> and there was also an
ebedded Javascript interpreter to run scripts that would have access
to these files. I wanted to provide standart fstream interface to
these virtual files (stored in std::strings) so that they would be
manipulated directly without any unnecessary copying or buffering (and
using this interface, manipulate these files from JS, or from external
modules). So the interface should be based on standard classes...
That's why I posted my question here - someone might have had
implemented something like this and will share ideas/info.
In some articles/tutorials I saw examples using input_iterator , maybe
it could help me??
Thanks.
