How to convert QString to LPCSTR??

[Gokulnathvc]

if (Status == DEVICESTATUS_DOWNLOAD_PROGRESS) {
        QString out;
        out.sprintf(("Downloading....  %d Sectors"), (unsigned int) Param);
        pThis->HlpSetStatus((LPCSTR)out.utf16());

if (Status == DEVICESTATUS_DOWNLOAD_PROGRESS) {
        QString out;
        out.sprintf(("Downloading....  %d Sectors"), (unsigned int) Param);
        pThis->HlpSetStatus((LPCSTR)out.utf16());

To copy to clipboard, switch view to plain text mode 

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

[ChrisW67]

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]

Still, I cannot understand this. Please help with my code

[squidge]

Your trying to squeeze a 16-bit array into an 8-bit array - it's not going to fit particularly well.

[Gokulnathvc]

Thanks for your co-operation. I have solved it

[ComaWhite]

if (Status == DEVICESTATUS_DOWNLOAD_PROGRESS) {
        QString out;
        out.sprintf(("Downloading....  %d Sectors"), (unsigned int) Param);
        pThis->HlpSetStatus((LPCSTR)out.utf16());

if (Status == DEVICESTATUS_DOWNLOAD_PROGRESS) {
        QString out;
        out.sprintf(("Downloading....  %d Sectors"), (unsigned int) Param);
        pThis->HlpSetStatus((LPCSTR)out.utf16());

To copy to clipboard, switch view to plain text mode 

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]

how did you solve this issue

[SixDegrees]

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]

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]

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]

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.