[Interest] Converting std::string.c_str() code to use QString methods

[Thiago Macieira]

On sábado, 31 de agosto de 2013 09:26:23, Michael Jackson wrote:
> As the original poster, thanks everyone for their input. Let me add some
> more context to where these "strings" maybe coming from.
> 
> 1) We have constants defined in headers using US ASCII Only Characters such
> as the following: 
>     const QString VoxelData("VoxelData");
>     const QString H5DataContainerPath("/DataContainer/VoxelDataContainer");
> 
> 2) We can get Strings from a user interface widget such as a QTextField
> which can be something they type in or gotten from a Open/Save File Dialog
> box.

Those you should consider to possibly have the full range of Unicode 
characters. Do not assume it's restricted to US-ASCII or Latin 1.

> 3) We use the HDF5 (www.hdfgroup.org) to store files. The entire interface
> is "C" and uses char* to get strings into and out the file when needed. Of
> all the discussion going on this is the part that worries me the most. Do I
> use "toAscii().data()" or toLatin().data()? We are still using Qt 4.8.4 but
> in the next year will probably move to Qt 5. I don't want to rewrite 500
> source files with APIs that are going to be deprecated in what we move up
> to. I'd only like to do this transition once.

Let's split in two:

1) file names

The correct thing to do is to use QString and *never* convert your file names 
to 8-bit. All the Qt API supports file names in this form, including QFile.

If you must convert to a non-Qt type, the best type is const char16_t*:

	some_function(reinterpret_cast<const char16_t *>(string.utf16());

Otherwise, you can use const wchar_t* (by using toWCharArray()).

If you must convert to 8-bit, you should use QFile::encodeName(). That's 
equivalent to .toLocal8Bit() on all systems today. Having anything that differs 
is a major headache.

2) user text that is not a file name

Again, keeping it in QString is the best solution. Otherwise, if your other 
library has Unicode entry points, you should use them (toUtf8, utf16(), 
toUcs4(), toWCharArray()).

If the interface only supports local 8-bit, you should throw the library away 
for being too limited.

> And not to hijack my own thread but we used std::stringstream in lots of
> places to build up error messages and progress messages. I started
> replacing all of that with QTextStream backed by a QString. Is this the
> right move or should I just have used QString and its various append
> methods?

To build error messages, you should use:

	tr("Some %1 with replacements: %2").arg("text").arg(otherVariable);

This also makes your application translatable.

> 
> Thanks
> Mike Jackson
> www.github.com/dream3d/DREAM3D
> 
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130831/386073a3/attachment.sig>