Здравствуйте, Shellac, Вы писали:
S>Здравствуйте, HunteX, Вы писали:
HX>>Привет! Помогите перевести строку типа QString в char*
HX>>Делаю таким образом:
HX>>
HX>>QString *qs = new QString("переведи меня в чары! :)");
HX>>QByteArray qb = qs->toUtf8();
HX>>char *ch = qb.data();
HX>>
Здравствуйте, Shellac, Вы писали:
S>Здравствуйте, HunteX, Вы писали:
HX>>Спасибо! Минутой ранее реализовал вот так:
S>Для спасибо есть кнопка специальная
Эта кнопка для кого-то актуальна?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Очень рискованно, особенно если прокинуть ctest как параметр в какую-нибудь функцию.
Потому что указатель торчит в уже освобожденную память временного объекта QByteArray.
UB в чистом виде.
Кодировка зависит от обстановки: .toAscii() / .toLocal8Bit() / .toUtf8()
Но результирующий QByteArray нужно либо копировать в локальный объект либо держать по константной ссылке.
K13>Очень рискованно, особенно если прокинуть ctest как параметр в какую-нибудь функцию. K13>Потому что указатель торчит в уже освобожденную память временного объекта QByteArray.
K13>UB в чистом виде.
получается он что так что так живет пока мы не выйдем из функции зачем было запрещать неконстантную ссылку ?
или можно ?
понимаю в таком контексте опасно неконстантную ссылку брать
хотя для студии все будет гуд
но вот при вызове то функции зачем запрещать
неконстантную ссылку объект же живет до возвращения ?
что в этом коде плохого если гарантируется что объект сдохнет только по возвращении