PDA

View Full Version : How to convert QString to LPCSTR??



Gokulnathvc
25th March 2011, 06:12
if (Status == DEVICESTATUS_DOWNLOAD_PROGRESS) {
QString out;
out.sprintf(("Downloading.... %d Sectors"), (unsigned int) Param);
pThis->HlpSetStatus((LPCSTR)out.utf16());

Am using this code but the status just displays only "D".. Please help me to resolve this issue.

ChrisW67
25th March 2011, 07:22
You are casting a "const ushort *" from QString::utf16() to a "const char *" (i.e. Long Pointer Constant STRing). Can you see the obvious disconnect here?

Perhaps you wanted QString::toAscii(), QString::toLocal8Bit() or QString::toLatin1() combined with the const form of QByteArray::data()

Gokulnathvc
25th March 2011, 07:26
Still, I cannot understand this. Please help with my code

squidge
25th March 2011, 07:38
Your trying to squeeze a 16-bit array into an 8-bit array - it's not going to fit particularly well.

Gokulnathvc
25th March 2011, 07:50
Thanks for your co-operation. I have solved it

ComaWhite
26th March 2011, 02:47
if (Status == DEVICESTATUS_DOWNLOAD_PROGRESS) {
QString out;
out.sprintf(("Downloading.... %d Sectors"), (unsigned int) Param);
pThis->HlpSetStatus((LPCSTR)out.utf16());

Am using this code but the status just displays only "D".. Please help me to resolve this issue.

Btw you shouldn't be using sprintf(). What's wrong with QString str = QString("Foo %1").arg(QString::number(param)) or QString str = "Foo " + QString::number(param)?
Also, I recommend you use C++ reinterpret_cast, etc as C style casting will not warn you and you will have trouble finding the problem in the end.

Joshy Abraham
31st March 2011, 07:33
how did you solve this issue

SixDegrees
31st March 2011, 07:54
Btw you shouldn't be using sprintf(). What's wrong with QString str = QString("Foo %1").arg(QString::number(param)) or QString str = "Foo " + QString::number(param)?
Also, I recommend you use C++ reinterpret_cast, etc as C style casting will not warn you and you will have trouble finding the problem in the end.

There's nothing wrong with sprintf; it's perfectly valid C and C++ code. It has the further advantage - uncovered on a recent multi-platform project - of being considerably more stable than the STL equivalent stringstream classes, which insisted on producing different output on different machines while sprintf produced exactly the same, clearly documented output.

There's no reason not to use it, and in some cases you'll be better off. Just because something is shiny and new doesn't necessarily mean it's better, or that it even works.

ComaWhite
3rd April 2011, 19:24
There's nothing wrong with sprintf; it's perfectly valid C and C++ code. It has the further advantage - uncovered on a recent multi-platform project - of being considerably more stable than the STL equivalent stringstream classes, which insisted on producing different output on different machines while sprintf produced exactly the same, clearly documented output.

There's no reason not to use it, and in some cases you'll be better off. Just because something is shiny and new doesn't necessarily mean it's better, or that it even works.



Warning: We do not recommend using QString::sprintf() in new Qt code. Instead, consider using QTextStream or arg(), both of which support Unicode strings seamlessly and are type-safe. Here's an example that uses QTextStream:


Read the documentation on it.

squidge
3rd April 2011, 22:22
The problem with any method which uses varargs (not just sprintf) is that the parameters are not type safe. If the format list does not match the parameters exactly, you can be using a %s and accidentally pass it an integer causing no compiler errors*, but a segmentation fault or access violation at runtime. This is typically more of a problem when you come back later to modify code and forget about changing one or the other. It also makes things more difficult to translate into multiple languages.

If your coming from a C background, then using the arg method may seem strange, so its perfectly natural to expect people to want to stick with methods they are more familiar with, such as sprintf. Once they have had a few such calls spit out garbage or crash there application, they'll search for a better alternative. Don't try and force such new things on them.

* - some compilers can actually match your format specifier to the argument list and warn you if they don't match (eg passing an integer to a string specifier)

SixDegrees
3rd April 2011, 23:22
Again, the problem we had was different formatting on different platforms, produced by the same code. sprintf may not conform to OO, encapsulated design, but it is standardized and has been through the wringer of testing for several decades now. Output was rock-solid across all the platforms we were required to deliver to, and all others we tested.

Theory is all very nice, but results are what matter in practice.