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

[Constantin Makshin]

For ASCII-only hardcoded constant strings it's better to use
QLatin1String because of its significantly lower overhead compared to
QString (no additional memory [de]allocations and copying, it uses the
original 'const char*' as its contents).

For storing strings I'd recommend using UTF-8 because in the average
case it's more space-efficient than other [widely-used] Unicode variants
(UTF-16, UTF-32) without losing the ability to represent any character.
And it has a bonus in the form of compatibility with ASCII. :)

Text messages (warnings, errors, progress like "Trying to guess what's
going on...", etc.) tend to be relatively short, so simple appending or
formatting (QString::arg() and co.) should be OK.

Of course, all that information is just my opinion. :)

On 08/31/2013 05:26 PM, Michael Jackson wrote:
> 
> On Aug 30, 2013, at 11:42 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
>> On sexta-feira, 30 de agosto de 2013 19:47:48, Syam wrote:
>>> On 31-Aug-2013 6:28 AM, "Thiago Macieira" <thiago.macieira at intel.com> wrote:
>>>> On sexta-feira, 30 de agosto de 2013 19:17:58, Scott Aron Bloom wrote:
>>>>> I use toUtf8()... Though it wouldn't surprise me if Thiago scolds me
>>>>> for it
>>>>
>>>> If you're on Unix, that's fine. It's fine because if your Unix system
>>>> uses a
>>>> locale different from UTF-8, you *really* should be scolded :-)
>>>
>>> On Linux, whenever I need a const char* from a QString, I always do
>>> toLatin1().constData().
>>>
>>> Earlier I used toAscii(), but then some discussion on Qt5 suggested that
>>> toLatin1() is more appropriate.
>>
>> toAscii() and toLatin1() are most often the same. Except when they aren't -- 
>> that's when someone called setCodecForCStrings. And then toAscii() is no 
>> longer doing ASCII, it's doing something potentially incompatible with ASCII.
>>
>> That's why this function is deprecated in Qt 5. In Qt 5, it's documented to do 
>> US-ASCII only and it has undefined behaviour if the QString contains characters 
>> not encodable in US-ASCII.
>>
>>> Am I right here? Of course, the assumption is that the original QString is
>>> simple English text.
>>
>> Even “simple English” may contain characters not encodable in Latin 1…
>>
>> As I've just proven :-)
>>
>> -- 
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>  Software Architect - Intel Open Source Technology Center
> 
> 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.
> 
> 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.
> 
> 
> Basically I am would really like to go "All In" with Qt so our programmers can have a consistent set of APIs to use at all levels of the codes. Not what we have now which is a mix of STL & Qt and MFC (in rare cases).
> 
> 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?
> 
> Thanks
> Mike Jackson
> www.github.com/dream3d/DREAM3D

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130831/12dff5a0/attachment.sig>