Russian Qt Forum

Всегда, даже если можно обойтись const char *:

C++ (Qt)
void anotherFunc(const QString &)
{
    ...
}
 
void func()
{
    QString a;
 
    if(...)
        a = "action1";
    else if(...)
        a = "action2";
    else
        a = "action3";
 
    anotherFunc(a);    
}
 

Не всегда, если можно обойтись const char *, и это безопасно:

C++ (Qt)
void anotherFunc(const QString &)
{
    ...
}
 
void func()
{
    const char *a;
 
    if(...)
        a = "action1";
    else if(...)
        a = "action2";
    else
        a = "action3";
 
    anotherFunc(a);    
}
 

Можно, только зачем?
Какие плюсы у второго куска, по сравнению с первым?

Если будет хороший объем текста - то очень существенные

C++ (Qt)
void anotherFunc(const QString &)
{
    ...
}
 
void func()
{
    const char *a;
 
    if(...)
        a = "action1";
    else if(...)
        a = "action2";
    else
        a = "action3";
 
    anotherFunc(QLatin1String(a));    
}
 

fxd

Где в приведенном примере хороший объем текста?
Понятное дело, что массив чаров быстрее чем QString. Но в большинстве случаев эта разница не существенна.
И что такое существенные? 32 секунды вместо 35?

Больших сравнений текста вообще нужно избегать, таким образом по крайней мере :)

Экономим на спичках?
Покажите мне код, в котором QString является узкой частью.

Имхо, QString - лучший класс строки, который есть для C++. Очень жаль, что его нельзя использовать не в Qt проектах.
по идее, он должен быть быстрее, чем std::vector, т.к. использует механизм copy-on-write.

А что вы предлагаете делать с char *?? Его даже сравнить нормально нельзя.Использовать  strcmp? (кстати, в стандарте C++ даже нет функции сравнения без учета регистра!! ). Да и вообще, сырые указатели - это не модно и не безопасно.

QtXml. Только и делает, что гоняет utf-8 (или другую 8битную кодировку внутри xml) в utf-16 и обратно.

Ну это понятно.
В общем я за повсеместный QString, кроме случаев, когда это очень критично по производительности.
Но тогда зачем вообще qt использовать?
Меня лично бесит, когда в проекте то QString, то char *.

По-моему неудачный пример.
раз гоняет, значит нужно. как раз экономия на спичках.
Храни данные в PlainText и читай их сишными функциями, и будет тебе очень производительно.

в qt-проектах смысла нет в char *.

Очень удачный. Тролли теперь страдают, что ничего с этим модулем сделать не могут, тк написали его через жопу, а совместимость не дает ничего изменить. И это не мои выдумки, это проверенная инфа.

Да, яхз зачем использовать char* если есть QByteArray.

поверю на слово.
Но в любом случае, получается, что проблема не собственно в QString, а в том, что написано через жопу.
Не QString же виноват, что QtXml его туда-сюда гоняет?)

andrew.k
Просто надо думать, когда пишите. В очень многих случаях можно обойтись батареем. Пример - QObject::objectName нафиг не нужен кустринг, достаточно батарея. Покажите мне извращенца, к-ый дает объектам в программе локализованные имена.

Дело не в локализованности.
Можно, например, имена использовать динамически.
Например, в калькуляторе PushButton0, PushButton1, PushButton2, ..., PushButton9
И выделять из имени последний символ в единственной для всех кнопок функции обработчике.
Тут же QString и пригодится.
И таких примеров можно массу придумать.

Батарей всё это позволяет. Можно вспомнить, что значение символа - это его код - '0'.
Для более сложных случаев гораздо более адекватно засовывать данные в проперти (а еще у некоторых классов есть спец userData), а не в имя.

В qt3 name был как раз батареем, если мне не изменяет память, но в 4 стал уже QString.
objectName() используется частенько в qt-проектах. Поэтому совершенно логично его было проапргейдить до QString.

У QPushButton я не нашел что-то UserData.

C++ (Qt)
{
  QList<QPushButton *> list = this->findChild<QPushButton *>( QRegExp( "PushButton" ) );
  foreach ( QPushButton * pb, list )
     connect( pb, SIGNAL( clicked() ), SLOT( someSlot() ) );
}
 
someSlot()
{
  // проверить sender()!
  input += sender()->objectName().right(1);
}
 
 

Что может быть элегантнее?

С кучей однотипных элементов иногда удобнее работать по имени, чем где-то еще данные для них хранить.

andrew.k
В qt3 не было нормального батарея; обжект нейм там был тупо char*, с к-оторым ничего действительно сделать нельзя. В 4ке же было повальное увлечение делать все подряд QString'ом не думая.
Обжект нейм _не_предназначен_ для того, чтобы хранить данные. Обжект нейм _не_предназначен_ для перевода на другие языки. Следовательно QString здесь излишен.

Элегантнее может быть только код, который сторонний человек может понять, а не гадать, какого хрена вы выцепляете из имени объекта последний символ, и чем этот символ так значим. Метод через проперти ему удовлетворяет. Еще _специально_ для таких вещей есть сигнал мапппер.
А в 1й функции вам еще придется следить за тем, чтобы _другие_ кнопки не подпадали под регэксп. Удачной отладки через годик.
Ну и напоследок - метод sender()

В неэлегантности убедил.
По сабжу не убедил.

Порадовал)

Задач в которых эти спички измеряются порядками не так уж мало. Напр при разборе текстовика хотя бы метров 10 разница уже будет видна невооруженным глазом.

std::string использует copy-on-write. QString использует implicit sharing. Это не одно и то же.

Конечно QString безумно удобен, но за это приходится платить. Мое мнение: если человек не умеет работать с char * значит он не знает языка, сколько бы чужих классов он не выучил  :)

Разработчики Qt с вами не согласны: "QString uses implicit sharing (copy-on-write) to reduce memory usage and to avoid the needless copying of data... " copy-on-write является более общим определением, вот и все.