On Tue, Sep 9, 2008 at 4:01 PM, Emanuel Rumpf <[EMAIL PROTECTED]> wrote:
> today, filesystems use utf8 too
Yes, but not all of them. The local 8-bit encoding is not always
going to be utf-8.
> Now ... .toStdString() does not work here.
> ("error: 'const class QString' has no member named 'toStdString'")
It's a pity, because toStdString is the obvious best function for many
situations and I use it in all my other Qt4 code. I've never had a
problem with it in the past (and fwiw, I use the Ubuntu packaged Qt4
normally). However, if it doesn't work for you and it isn't obvious
to you why not, then I guess it won't be obvious to other people
either, so perhaps we should avoid it.
> Do I miss a compiler option?
The lines you just printed looked OK to me.
> If it's related to QT3_SUPPORT, then I guess toStdString() will
> disappear soon too.
No, it isn't anything to do with Qt3. It's a current, recommended
function. It should be the right function.
Oh well.
btw, it's wise to be wary of lifecycle issues when using things like
.toLocal8Bit().data(). The C-style string pointer returned will be
invalidated when the temporary object returned by toLocal8Bit is
deleted, which will usually be at the end of the same line of code.
This is therefore only suitable for use when the pointer is being
passed in to a function like a system call that uses it only within
the scope of the function, or when constructing something l ike a
std::string from it (which copies the data).
Of course, the same would apply when calling toStdString().c_str()
(the std::string is a temporary that will be deleted at the end of the
line, invalidating the C-style string as well).
> Now we know the target encoding.
> But what is the source encoding ?
> With QString I think we don't have to think about it, but
> if we converted std:string to QString, we had to do
> something like QString.fromUtf8( stdStr ) , in case stdStr was utf8 encoded.
Our std::strings that we pass around and store (e.g. in events) are
intended to be always utf8. The encoding should be preserved when
they are converted back and forth using qstrtostr and strtoqstr. The
vast majority of our string handling falls into this category -- it
works, it's right already and it shouldn't need fixing so long as
qstrtostr and strtoqstr remain correct.
The exceptional cases are those in which std::string or a C-style
string are created from QString in order to write to the console
directly or pass to a system call. In these cases we ought to convert
to local 8-bit encoding when converting from QString. We also have
some rather ugly situations in which a string is thrown directly as an
exception -- I'm not keen on that style anyway, but utf8 is probably
as good as any other encoding there.
I'm not sure whether there are any cases in which we convert from
std::string to QString but the std::string is not utf8 already?
Chris
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
