Почему std:: setw и std::hex не соответствуют приведенному ниже коду?

Я видел фрагмент кода от кого-то, как показано ниже:
прежде чем изменилось:

  void pal::type3_message::debug_print(std::ostream & out) const
     {
       out << "### type3_message:" << '\n'
           << pal::as_hex_dump(as_bytes())
           << "lm_response = " << pal::as_hex_string(lm_response_)
           << "\nnt_response = " << pal::as_hex_string(nt_response_)
           << "\ndomain = " << domain_
           << "\nuser = "   << user_
           << "\nworkstation = " << workstation_
           << "\nsession_key = " << pal::as_hex_string(session_key_)
           << std::hex << std::setw(8) << std::setfill('0')
           <<"\nssp_flags = " << ssp_flags_;
     }

после изменения:

std::string pal::type3_message::debug_print() const
{
   std::ostringstream buf;
   buf << "### type3_message:" << '\n'
       << pal::as_hex_dump(as_bytes())
       << "lm_response = " << pal::as_hex_string(lm_response_)
       << "\nnt_response = " << pal::as_hex_string(nt_response_)
       << "\ndomain = " << domain_
       << "\nuser = "   << user_
       << "\nworkstation = " << workstation_
       << "\nsession_key = " << pal::as_hex_string(session_key_)
       << std::hex << std::setw(8) << std::setfill('0')
       <<"\nssp_flags = " << ssp_flags_;
    return buf.str();
}

Я не очень уверен в вышеизложенном изменении, кто-нибудь может сказать мне, как это должно было произойти и его глубокое значение? с нетерпением ждем ответа и ценим это.

Источник

2 ответа

Я не совсем уверен, что вы спрашиваете, поэтому я просто объясняю, что делает пример кода и в чем заключается основное различие между обеими функциями:

void pal::type3_message::debug_print(std::ostream & out) const

Эта функция записывает сообщение в выходной поток, на который ссылается out параметр. У него нет возвращаемого значения.

std::string pal::type3_message::debug_print() const

Кажется, эта функция выводит то же сообщение, но вместо записи в поток она сохраняет сообщение в виде строки. Эта строка возвращается функцией.

Реализация обеих функций выглядит очень похоже, потому что вторая функция использует временный std::ostringstream внутренне. Это поток, который существует только в памяти. Напротив, вы могли бы передать поток файла, как std::ofstream до 1-й функции.

Пожалуйста, уточните свой вопрос, если вы хотите узнать больше.

Источник

можете мне сказать, как это должно происходить и каково это?

Первый метод получает параметр std::ostream& и передает в него более 10 различных фрагментов текста.

Второй метод передает те же 10 фрагментов текста в локально созданный (автоматический var) std::ostringstream. Это объединяет фрагменты перед возвратом строки.

Возможные примеры использования (для достижения того же результата на std::cout):

pal::type3_message::debug_print(std::cout);
std::cout << std::endl;

а также

std::cout << pal::type3_message::debug_print() << std::endl;

Я предпочитаю подход std::stringstream, но я использовал оба.

В первом методе поток может быть "прерван" в большем количестве мест (между 10), что может повлиять на работу не частного потока. Это вызывает проблему? Я не расследовал на рабочем столе.

Второй метод завершает конкатенацию, затем возвращает строку. Все предыдущие точки прерывания все еще существуют, но ни одна из них не влияет на доставку в std::cout, назначение общего потока. Обратите внимание, что в этом пути еще есть 1 (или, возможно, 2) место прерываний (для добавления строки). Тем не менее, это, вероятно, менее вероятно, приведет к видимым проблемам.

Во встроенной системе, над которой я когда-то работал, благодаря драйверам второй метод был явно лучше (с точки зрения прерывания потоков во время использования) и, по-видимому, не нуждался в защите мьютекса на выходном канале.

В Ubuntu я добавил мьютекс-охранник для доступа к std::cout ..., чтобы избежать "смешанного" текста, хотя я не подтвердил, что описанного в этом посте изменения могло быть достаточно.

У меня есть in-ram-log с циклическим буферным буфером, и этот общий ресурс имеет защиту мьютекса. Никогда не возникает проблем с несколькими потоками, вносящими вклад в один и тот же журнал.

Примечание. В ответе на вопрос "Вопрос" я не вижу различий ни в потоке, ни в std::hex или std::setw, оба используются одинаково.

обновление от 2 июля, комментарий

Я согласен, что "после" это то, что я предпочитаю.

Я не узнаю фразу "не связывайся с заимствованными вещами". Я посмотрел и решил, что отчет Google по этой фразе не имеет никакого отношения к программному обеспечению.

Но это напомнило мне о возможной связанной осторожности, которую я слышал, "код похож на лук". Парень, который повторял это мне (одержимо), сопротивлялся "исправлению" вещей (например, краху), потому что, я полагаю, он беспокоился, что любые изменения могут нарушить "поведение" необнаружимым образом. Таким образом, он прорабатывал "все луковые слои" до тех пор, пока не убедился, что ничего плохого не произойдет, прежде чем совершить изменение кода. "Паралич анализом" приходит на ум.

Я, по-видимому, гораздо более терпим к тому, чтобы попробовать что-то другое (и тестировать, тестировать, тестировать...). Это крушение было легко исправить, и оно, безусловно, задерживало прогресс в понимании более глубоких слоев лука.

Источник
Другие вопросы по тегам