Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
A char is not a "character in the stream sense" if you want to output it
to a 4 byte wide stream.
Look e.g. at this code from insetnote.C:
ostringstream ss;
ss << "[";
InsetText::plaintext(buf, ss, runparams);
ss << "]";
Here you need to widen '[' and ']' if ss becomes an ucs4 stringstream.
Here "[" is used instead of '[', but the principle is the same.
Ah but you are talking about ostringstream here not ostream. This is a
different problem: if ss was an ostream, ss << "]" would really output a
single one-bite char and that's what we want.
I do not make any difference between ofstream and ostringstream. No
operator<< knows the exact type of stream. It is simply a stream derived
from ostream, and it does not matter whether it is connected to a file or a
string buffer.
Indeed. But I think you are mixing the output. ostreams are for char
based output. You should not mix that with a new
basic_ostream<boost::uint32>. If there is a need for string
manipulation, it should not be done at the same place.
So, IIUC, you want to use the same method (plaintext()) for
ostringstream or ostream output types... if so, now I see the problem.
Not exactly. I want to convert the plaintext() method to use an ucs4
ostream.
I think this is where I disagree.
This is needed because plaintext() is used in some places to
produce a string,
Could we not correct that instead?
and we do not want to convert to utf8 in plaintext(),
Why not? More exactly, the << operator will do it.
output to a 1byte wide ostream and then convert back to ucs4.
I got your point but I am not convinced... yet ;-)
But I you look a bit more at this code, you don't really need the
ostringstream here, this code below:
ostringstream ss;
ss << "[";
InsetText::plaintext(buf, ss, runparams);
ss << "]";
string const str = ss.str();
os << str;
could be reduced to that:
os << "[";
InsetText::plaintext(buf, os, runparams);
os << "]";
No it could not. I snipped something:
string const str = ss.str();
os << str;
// Return how many newlines we issued.
return int(lyx::count(str.begin(), str.end(),'\n'));
Hum, this is easily fixable:
os << "[";
int N = InsetText::plaintext(buf, os, runparams);
os << "]";
// Return how many newlines we issued.
return N;
But of course InsetText::plaintext() should be fixed first:
int InsetText::plaintext(Buffer const & buf, ostream & os,
OutputParams const & runparams) const
{
...
// FIXME: Give the total numbers of lines
return 1;
}
And the nice thing about it is that you don't need to do any widening on
the ] and [ characters if os stays an std::ostream.
But it will not. Yes, this example is for plaintext output that finally goes
to a file, but I have seen others (don't find them at the moment) where a
string is constructed using an ostringstream that will become a ucs4
ostringstream.
Those occurrences of ostringstream shall be replaced with our shiny new
odocstringstream. But these are docstring manipulations, they should not
be mixed with ostream output which are char based (typically files with
ofstream).
I think you misunderstood me, I don't deny the need for this
odocstringstream (aka basic_string<boost::uint32>). I am just saying
that we don't have to use anything else but std::ostream for file output
and that we shall draw a clear line between what is internal from what
is external.
Thanks for the explanation. I hope I am not wasting your time.
I hope you will be able to help with the conversion. If yes, then that time
is well invested ;-)
I am slowly but surely getting there... :-)
Abdel.
