Преобразовать символ из QChar в char

[BRE]

хм, ну вот скока себя помню - всегда работала подобная конструкция
(const char *ptrStr = str.toAscii().constData()

Это скорее удача, хотя нужно смотреть код, что там компилятор "нагенерил".

естественно, что возвращать ptrStr не стоит но в локальном методе все ок.
QByteArray то живет до очистки стека.

Эту конструкцию (const char *ptrStr = str.toAscii().constData() можно записать так:

Код

C++ (Qt)
const char *ptrStr;
{
     QByteArray tmp = str.toAscii();
     ptrStr = tmp.constData();
}
 

Вот если бы деструктор QByteArray занулял бы свою область, то вопросов бы не возникало.

[Racheengel]

Наскольно мне известно, в С++ областью "жизни" локального объекта является блок скобок {...}. Таким образом, два вышеприведенных варианта аналогичны, за исключением того, что в первом создается неименованный экземпляр QByteArray для локального доступа, а во втором он получает имя tmp. Прибиты же оба должны быть при выходе из блока, т.е. после первой всреченной }.
Однако согласен, что все может зависеть от реализации компилятора. Могу только сказать, что по крайней мере я не встречал компиляторов, которые бы некорректно отрабатывали данную ситуацию (но это, как про суслика - его можно не видеть, хотя он есть - ДМБ).

[Rcus]

/** sigh, \image html facepalm.jpg, \ref Valgrind-free-fill-proof */

[BRE]

Наскольно мне известно, в С++ областью "жизни" локального объекта является блок скобок {...}. Таким образом, два вышеприведенных варианта аналогичны, за исключением того, что в первом создается неименованный экземпляр QByteArray для локального доступа, а во втором он получает имя tmp. Прибиты же оба должны быть при выходе из блока, т.е. после первой всреченной }.

Ну да, а использовать указатель на tmp, ты будешь после }.

Вариант 1

Код

C++ (Qt)
const char *ptrStr;
{
     QByteArray tmp = str.toAscii();
     ptrStr = tmp.constData();
}
 
// Использование
char ch = ptrStr[ 20 ];
 

Вариант 2

Код

C++ (Qt)
const char *ptrStr = str.toAscii().constData()
 
// Использование
char ch = ptrStr[ 20 ];
 

В обоих случаях объект на который указывает ptrStr уже разрушен.

[Racheengel]

В 1 случае - однозначно, во 2 - depends on compiler.
Стандарт С++ не утверждает, что локальный объект должен уничтожаться в этом случае.

[BRE]

во 2 - depends on compiler.
Стандарт С++ не утверждает, что локальный объект должен уничтожаться в этом случае.

По стандарту утверждать не буду, не владею информацией....
Но во избежании, лучше не использовать.
А то может получиться сегодня работает, вышла новая версия компилятора и программа умирает. Можно долго голову ломать, а потом долго все вычищать.
Все IMHO. 

[spirit]

во 2 - depends on compiler.
Стандарт С++ не утверждает, что локальный объект должен уничтожаться в этом случае.

По стандарту утверждать не буду, не владею информацией....
Но во избежании, лучше не использовать.
А то может получиться сегодня работает, вышла новая версия компилятора и программа умирает. Можно долго голову ломать, а потом долго все вычищать.
Все IMHO. 

+1, зачем использовать заведомо нестабильный код.

[pastor]

во 2 - depends on compiler.

Невстречал такого. Валится прога и на GCC и на MSVC и на ICC по одной и тойже причине - указатель невалиден в виду того что разрущается объект QByteArray. И это не зависит от компилятора или платформы. Для интереса провери ряд тестов, с разными компиляторами, платформами.

ЗЫ: Повторюсь еще раз, загляните в исходники самой Qt на предмет использования таких вот конструкций.

[BRE]

Невстречал такого. Валится прога и на GCC и на MSVC и на ICC по одной и тойже причине - указатель невалиден в виду того что разрущается объект QByteArray

Скорее всего, срабатывает то, что деструктор вызван, но данные лежат в стеке ничем не затертые. Вот если бы деструктор QByteArray занулял свои данные, такие номера скорее всего не проходили бы.

[pastor]

Стандарт С++ не утверждает, что локальный объект должен уничтожаться в этом случае.

Непонял. А почему он недолжен разрушатся?

У нас отработал комплекс функций str.toAscii().constData(). Локальный объекты умерли, память освободилась, но указатель на эти данные мы сохранили. На что будет указывать этот указатель?

А вот в таких ситуациях будет все ок:

Код

C++ (Qt)
qWarning("%s", str.toAscii().constData());

или

...

Код

C++ (Qt)
some_function(str.toAscii().constData());
....
 
void some_function(const char *str)
{
    //do something with str
}

[Racheengel]

А вот тут поподробнее плиз...
Почему тогда будет все ок, если компиль прибьет локальный объект?

[BRE]

А вот тут поподробнее плиз...
Почему тогда будет все ок, если компиль прибьет локальный объект?

Локальный объект создается, указатель передается в функцию, функция отрабатывает, при выходе из функции локальный объект уничтожается.

[Racheengel]

У нас отработал комплекс функций str.toAscii().constData(). Локальный объекты умерли, память освободилась

Вот, собственно, почему они должны умереть? Стандарт не говорит об этом.

[pastor]

А вот тут поподробнее плиз...
Почему тогда будет все ок, если компиль прибьет локальный объект?

Указатель, переданный в some_function будет оставаться валидным до её завершения, так как временный экземпляр QByteArray остаётся жить в стеке и будет уничтожен сразу же при выходе из этой функции

[Racheengel]

ну ок, в случае с функцией это да.
А вот такой код -

Код:

{
...
const char *ptrStr = str.toAscii().constData();
...
doSomething(ptrStr);
...
}

очень часто употребляем, и реально я не вижу причин, по которому бы временный экземпляр QByteArray был бы прибит до }. По крайней мере, согласно стандарту. (хотя создатели компилятора могут думать по другому)