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.macie...@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.macie...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
