[英]Operator << for QString
為 QString 實現 << 是有意義的,例如:
std::ostream& operator <<(std::ostream &stream,const QString &str)
{
stream << str.toAscii().constData(); //or: stream << str.toStdString(); //??
return stream;
}
而不是寫作
stream << str.toAscii().constData();
每次都在代碼中。
但是,由於它不在標准 Qt 庫中,我假設有任何特殊原因不這樣做。 超載 << 如上所述有哪些風險/不便?
如果 Qt 庫中包含<<
運算符,則庫的每個客戶端都必須使用完全相同的實現。 但是由於 QString 的性質,這遠非這些客戶想要的。 一些在西歐編寫與遺留文件交互的軟件的人可能想要使用 Latin1() 字符,美國人可能使用 Ascii() 而更現代的軟件可能想要使用 Utf8()。
在庫中只有一個實現會限制整個庫所能做的事情,這是不可接受的。
沒有必要實現這樣的東西,只要存在這樣一個方便的解決方案,涉及QTextStream
QString s;
QTextStream out(&s);
out << "Text 1";
out << "Text 2";
out << "And so on....";
QTextStream非常強大...
我認為在Qt library
排除(也不包括)它沒有任何特殊原因。 這里可能出現的唯一問題是std::ostream
對象可能會修改傳遞給std::ostream::operator<<
函數的參數的內容。
但是,在參考文獻中明確指出,如果傳遞字符串緩沖區,此函數將修改參數 - 其他類型沒有任何內容,所以我猜(常識告訴我) operator<< 不會修改char*
參數。 此外,在此頁面上沒有關於修改傳遞對象的內容。
最后一件事:您可以使用QString::toStdString()
或qPrintable(const QString&)
宏,而不是使用QString::toAscii().constData()
。
接受的答案指出了為什么QString
沒有operator<<
函數的一些有效原因。
通過提供一些方便的功能並在特定於應用程序的namespace
維護一些狀態,可以輕松克服這些原因。
#include <iostream>
#include <QString>
namespace MyApp
{
typedef char const* (*QStringInsertFunction)(QString const& s);
char const* use_toAscii(QString const& s)
{
return s.toAscii().constData();
}
char const* use_toUtf8(QString const& s)
{
return s.toUtf8().constData();
}
char const* use_toLatin1(QString const& s)
{
return s.toLatin1().constData();
}
// Default function to use to insert a QString.
QStringInsertFunction insertFunction = use_toAscii;
std::ostream& operator<<(std::ostream& out, QStringInsertFunction fun)
{
insertFunction = fun;
return out;
}
std::ostream& operator<<(std::ostream& out, QString const& s)
{
return out << insertFunction(s);
}
};
int main()
{
using namespace MyApp;
QString testQ("test-string");
std::cout << use_toAscii << testQ << std::endl;
std::cout << use_toUtf8 << testQ << std::endl;
std::cout << use_toLatin1 << testQ << std::endl;
return 0;
}
輸出:
test-string
test-string
test-string
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.