Я кодирую задание, в котором, по сути, у меня есть связь между клиентом и сервером. Для этого я использую строковый поток на стороне сервера для обработки запросов (которые поступают в форме строк) и помощи в построении строкового ответа. На стороне сервера находится объект (FileManager), который содержит несколько объектов MultimediaFile, каждый из которых содержит информацию о себе. Эта информация может быть напечатана с помощью метода, одним из параметров которого является ostream &.
Чтобы получить запрос от клиента, поток строк работает нормально, но когда я передаю его методу, он по какой-то причине не читает содержимое (тогда как если я передаю std :: cout, он работает нормально). Я думаю, это как-то связано с тем, как stringstream использует оператор ‹< для чтения информации, но я не знаю, как это исправить.
Я знаю, что могу просто сохранить нужную мне информацию об объекте в строке или что-то в этом роде (вместо использования ostream &), но профессор хочет, чтобы метод печатал непосредственно в переданный ostream, а не возвращал строку.
Вот код:
bool processRequest(TCPServer::Cnx& cnx, const string& request, string& response)
{
bool changeData = false;
if (request == "delMedias" || request == "delGroups") changeData = true;
TCPServer::Lock lock(cnx, changeData);
cerr << "request: '" << request << "'" << endl;
string operation = "";
string filename = "";
stringstream iss;
iss.str(request); //next few lines get request info, works just fine!
if (iss.rdbuf()->in_avail() != 0)
iss >> operation;
if (iss.rdbuf()->in_avail() != 0)
iss.get();
if (iss.rdbuf()->in_avail() != 0)
getline(iss, filename);
iss.str("");
if (operation.size() == 0 || filename.size() == 0) return false;
response = "";
if (operation.compare("print") == 0)
{
filem.showFile(filename, iss); //Problem here!!!!
if (iss.rdbuf()->in_avail() != 0) //iss is always empty
{
response = iss.str();
response = "Print info: " + response;
}
else
response = "No info received!";
}
else if (operation.compare("play") == 0)
{
filem.playFile(filename);
response = "File played!";
}
else
response = "Operation not valid";
cerr << response << endl;
return true;
}
TCPServer - это класс, предоставленный профессором для упрощения работы, но в основном клиент отправляет строку request и в конце этой функции получает строку ответ от сервера. filem - это объект класса FileManager, а вот код метода showFile:
void FileManager::showFile(string name, ostream& s)
{
if (mfiles.find(name) != mfiles.end())
mfiles[name]->printFile(s);
}
mfiles - это отображение строки в MultimediaFile * (в частности, std :: shared_ptr из MultimediaFile, но в любом случае). По сути, этот код проверяет, существует ли файл с именем name, и если да, вызывает метод printFile (s), где s здесь будет струнный поток. Вот код метода:
void MultimediaFile::printFile(ostream& s) const
{
s << "File name: " << name << "\tFilepath: " << filepath << "\n";
}
name и filepath - это переменные экземпляра класса MultimediaFile. Итак, да, здесь я ожидал, что мой поток строк получит эту информацию, которая затем будет использована для построения строки response в основной части кода сразу после вызова метода. Однако это не то, что происходит, и строковый поток всегда пуст (и поскольку это работает с std :: cout, проблема не в данных в объекте MultimediaFile).
Опять же, я бы сказал, что stringstream ведет себя иначе, чем cout при получении данных с помощью оператора ‹<, но я не смог найти никакой информации, которая могла бы мне помочь в этом случае ... У кого-нибудь есть идея?
Если вам нужна другая информация, пожалуйста, дайте мне знать. И заранее спасибо!
operation.compare("print") == 0
вместоoperation == "print"
? - person Nobody moving away from SE   schedule 17.02.2016if
вshowFile
решает по-разному междуcout
иstringstream
вариантом? - person Nobody moving away from SE   schedule 17.02.2016and it goes straight to that bit of code
Какой бит? Вы должны попытаться предоставить код, воспроизводящий проблему. Учитывая текущую информацию, я (и, вероятно, другие тоже) не могу ее воссоздать. - person Nobody moving away from SE   schedule 17.02.2016