实施<<对于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库中,我假设有任何特殊原因不这样做。重载的风险/不便是什么&lt;&lt;如上所述?
答案 0 :(得分:10)
如果Qt库中包含<<
运算符,则库的每个客户端都必须使用完全相同的实现。但是由于QString的性质,这是客户想要的并不明显。有些人在西欧编写与遗留文件交互的软件可能想要使用Latin1()字符,美国人可能会使用Ascii(),更多现代软件可能想要使用Utf8()。
在库中实现单个实现会限制整个库可以完成的工作。
答案 1 :(得分:5)
没有必要实现这样的事情,只要存在像这样的方便的解决方案,涉及QTextStream
QString s;
QTextStream out(&s);
s << "Text 1";
s << "Text 2";
s << "And so on....";
QTextStream非常强大......
答案 2 :(得分:1)
我认为在Qt library
中排除(也不包括)这一点并不存在任何特殊原因。只有这里可能出现的问题是std::ostream
对象可能会修改传递给std::ostream::operator<<
函数的参数的内容。
然而,在reference中明确指出,如果传递字符串缓冲区,此函数将修改参数 - 其他类型没有任何内容,所以我猜(并且常识告诉我)运算符&lt;&lt;不会修改char*
参数。此外,在this页面上没有任何关于修改传递的对象的内容。
最后一件事:您可以使用QString::toAscii().constData()
或QString::toStdString()
宏,而不是使用qPrintable(const QString&)
。
答案 3 :(得分:1)
The accepted answer指出了为什么operator<<
没有QString
功能的正当理由。
通过提供一些便利功能并在特定于应用程序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