Печать контейнера с разделителями

Иногда, при печати содержимого контейнера хочется избежать ненужного хвостового разделителя.

Простейшее решение выглядит так:

#include <iostream>
#include <vector>

int main(int argc, char* argv[]) {
  int a[] = { 1, 2, 3, 4, 5 };
  std::vector<int> v(a, a + 5);

  for (int i = 0; i < v.size(); ++i) {
    std::cout << v[i];
    if (i < v.size() - 1)
      std::cout << ", ";
  }
  std::cout << std::endl;

  return 0;
}

Условие в теле цикла решает поставленную задачу, но контейнеры лучше обходить через итераторы, поэтому следующая попытка может выглятеть так:

#include <iostream>
#include <vector>

int main(int argc, char* argv[]) {
  int a[] = { 1, 2, 3, 4, 5 };
  std::vector<int> v(a, a + 5);

  for (std::vector<int>::const_iterator i = v.begin(); i != v.end(); ++i) {
    std::cout << *i;
    if (v.end() - i > 1)
      std::cout << ", ";
  }
  std::cout << std::endl;

  return 0;

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

#include <iostream>
#include <vector>

int main(int argc, char* argv[]) {
  int a[] = { 1, 2, 3, 4, 5 };
  std::vector<int> v(a, a + 5);

  typedef std::vector<int>::const_iterator iterator;
  for (iterator i = v.begin(); i != v.end(); ++i) {
    std::cout << *i;
    if (std::distance<iterator>(i, v.end()) > 1)
      std::cout << ", ";
  }
  std::cout << std::endl;
  return 0;
}

Шаблонный класс std::distance умеет рассчитывать расстояние между итераторами, и даже для тех, которые не поддерживают операции сложения и вычетания. Для таких итераторов будет делаться пошаговый обход от одного к другому для подсчета расстояния. На первый взгляд получается, что вычислительная сложность такого простого цикла будет уже не линейной, а квадратической. Еше надо таскать за собой описание типа дважды — чтобы создать итератор цикла и экземпляр std::distance. Например, Visual Studio 2008 требует указывать тип итератора для шаблона std::distance и не может "угадать" его из параметров (другие компиляторы могут вести себя иначе). Получается, на ровном месте навернули какую-то ерунду.

Но есть весьма элегантный способ, который позволяет и использовать итераторы, и сохранить линейную сложность алгоритма для контейнеров, которые не умеют эффективно вычислять расстояние между элементами (например, std::list), и писать красиво и компактно:

#include <iostream>
#include <vector>

int main(int argc, char* argv[]) {
  int a[] = { 1, 2, 3, 4, 5 };
  std::vector<int> v(a, a + 5);

  for (std::vector<int>::const_iterator i = v.begin(); i != v.end(); ++i) {
    std::cout << *i;
    if (i != --v.end())
      std::cout << ", ";
  }
  std::cout << std::endl;

  return 0;
}

Трюк с оператором "--" позволяет эффективно проверить на последний элемент контейнера.

Как реализована сортировка в STL

Все началось с того, что я почему-то написал свою реализацию классического алгоритма быстрой сортировки QuickSort. И все бы хорошо, но я, конечно, решил померяться достоинством с STL'ой реализацией. Результат был очевиден, и я даже не хочу приводить цифры.

Вобщем, я открыл файл algorithm из STL'я в Visual Studio 2008 и часок покопался в нем. Вот результаты моих "исследований".

Начнем с нестабильной сортировки std::sort().

• основа: алгоритм быстрой сортировки QuickSort (почти как у меня)
• выбор опорного элемента — центральный по индексу элемент в сортируемом фрагменте
• после каждого выбора опорного элемента:
  • начальный, опорный и последний элементы сортируются между собой (их всего три, так что тут это делается тремя последовательными if'ами)
  • если длина сортируемого фрагмента менее более 40, то отрезок делится 8 частeй (длина каждой части S = 1/8*N) и для троиц элементов (1, S, 2*S), (N/2 - S, N/2, N/2 + S) и (N - 2*S, N - S, N) делается такая же минисортировка, как и на предыдущем шаге (где число элементов было меньше 40)
  • далее происходит обычная для QuickSort процедура деления фрагмента на две части с использованием опорного элемента (цикл по перебрасыванию элементов, меньших опорного направо, а больших — налево)
• затем вся процедура рекурсивно повторяется для левой и правой частей

Количество рекурсивных операций не идет до победного конца, как в чистом QuickSort. Если количество итераций (процедур разделения массива) превысило 1.5*log2(N), где N длина всего массива, то рекурсивные операции прекращаются. Если количество оставшихся недосортированных элементов меньше 32-х, то фрагмент досортируется методом вставки InsertionSort (этот метод имеет общую сложность O(N²) и для больших массивов не используется, но на малых длинах он быстрее всех из-за простоты). Если же остается более 32-х элементов, то досортировка происходит пирамидальным методом HeapSort в чистом его виде.

Видимо все эти ухищрения для уменьшения накладных расходов QuickSort на малых массивах.

Вот такая вот далеко непрямолинейная реализация.

Далее.

Стабильная сортировка std::stable_sort() реализована алгоримом слияния MergeSort. Особых ухищрений по сравнению с чистным алгоритмом я не нашел. Разве что малые фрагменты (короче 32-х элементов) досортировываются методом вставки InsertionSort, как и в случае с QuickSort.

Частичая сортировка std::partial_sort() реализована в чистом виде пирамидальным методом HeapSort.

Вывод:
Читать исходники очень интересно. Особенно хорошие исходники.

Шестнадцатеричная печать в STL поток

Когда-то очень давно я написал элементарный манипулятор для шестнадцатеричной печати в стандарный поток. Все просто и тривиально. Но тем не менее я заметил, что таскаю этот микрокласс почти в кажный проект, где нужна отладочная печать. Обычно для шестнадцатеричной печати надо указывать сразу несколько итераторов, типа:

std::cout << std::hex << std::uppercase << std::setfill('0') << std::setw(2) << 0xAA;

Причем std::setw() надо повторять для каждого нового выводимого элемента. Я свел все это в один итератор, чтобы можно было просто написать (указав итератору ширину выводимого поля):

std::cout << ext::Hex(2) << 0xAA;

Итак, класс Hex (название пространства имен можно подкрутить по вкусу), файл hex.h:

#ifndef _EXT_HEX_H
#define _EXT_HEX_H

#include <iostream>
#include <iomanip>

namespace ext {

class Hex {
public:
  Hex(int width) : __width(width) {}
  friend std::ostream& operator<< (std::ostream& os, const Hex& hex);
private:
  int __width;
};

inline std::ostream& operator<< (std::ostream& os, const Hex& hex) {
  std::hex(os);
  std::uppercase(os);
  os.width(hex.__width);
  os.fill('0');
  return os;
}

} // ext

#endif // _EXT_HEX_H

Теперь можно писать так:

std::cout << ext::Hex(0)  << 0x0a << std::endl;
std::cout << ext::Hex(1)  << 0x0a << std::endl;
std::cout << ext::Hex(1)  << 0xaa << std::endl;
std::cout << ext::Hex(2)  << 0xaa << std::endl;
std::cout << ext::Hex(4)  << 0xaa << std::endl;
std::cout << ext::Hex(8)  << 0x0a << std::endl;
std::cout << ext::Hex(16) << 0x0a << std::endl;
std::cout << ext::Hex(32) << 0x0a << std::endl;

И результатом будет:

A
A
AA
AA
00AA
0000000A
000000000000000A
0000000000000000000000000000000A

На всякий случай, unit-тест. Чтобы не было сюрпризов при обновлении компилятора, STLport или чего-то еще. Тест всегда проверит, работает ли класс так, как вы от него ждете. Вы можете возразить — ну класс-то выеденного яйца не стоит, а тут для него тесты... Соглашусь. А еще я соглашусь, что сотни раз самые казалось бы ненужные на первый взгляд тесты для "очевидных" классов помогали обнаружить глюки на новой версии системных библиотек, новой версии компилятора, использовании "более мощных" параметров оптимизации и т.д. Время на написание тестов всегда окупается сполна, всегда.

Традиционно, для компиляции тестов нам нужна Google Test Framework. Как я уже писал, вы можете скачать мою модификацию этой библиотеки, которая сокращена без потери какой-либо функциональности до двух необходимых файлов gtest/gtest.h и gtest-all.cc.

Файл hex_unittest.cpp:

#include "gtest/gtest.h"
#include "hex.h"
#include <sstream>

void testHex(int n, int w, const std::string& etalon) {
  std::stringstream fmt;
  fmt << ext::Hex(w) << n;
  EXPECT_EQ(etalon, fmt.str());
}

TEST(HexManip, Generic) {
  testHex(0x0A, 0, "A");
  testHex(0x0A, 1, "A");
  testHex(0xAA, 1, "AA");
  testHex(0xAA, 2, "AA");
  testHex(0xAA, 4, "00AA");
  testHex(0xAA, 8, "000000AA");
  testHex(0xAA, 16, "00000000000000AA");
  testHex(0xAA, 32, "000000000000000000000000000000AA");
}

Ну и головная программа:

#include "gtest/gtest.h"
int main(int argc, char* argv[]) {
  testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

Компилируем.

Visual Studio:

cl /EHsc /I. /Fehex_unittest_vs2008.exe runner.cpp hex_unittest.cpp gtest\gtest-all.cc

Cygwin:

g++ -I. -o hex_unittest_cygwin.exe runner.cpp hex_unittest.cpp gtest/gtest-all.cc

Запускаем:

[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from HexManip
[ RUN      ] HexManip.Generic
[       OK ] HexManip.Generic
[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran.
[  PASSED  ] 1 test.

Работает как положено.

При использовании Hex у себя в проекте не забудьте включить файл hex_unittest.cpp в ваш набор unit-тестов. Оберегите себя от ненужной траты времени в будущем.

Под занавес пара слов о производительности. Очевидно, что если вы выводите в поток десятки тысяч шестнадцатеричных чисел подряд, то разумнее будет использовать стандартные итераторы — настроить поток с помощью std::hex, std::uppercase и std::setfill(), а потом вызывать только std::setw() для каждого нового элемента. Но если вы печатаете разнородные данные, что часто требуется при отладке, то тогда итератор Hex будет в самый раз.


Другие посты по теме:

• Unit-тестирование для параллельных потоков

Скоростное чтение файла в STL через итераторы

Во многих современных языках программирования считать весь файл в строку можно буквально одним оператором, например, в php это делается так:

$lines = file_get_contents("textfile.txt");

или так, медленно и неэффективно, по-старинке:

$lines = join("", file("textfile.txt"));

Задумался я, как бы это так элегантно одним оператором сделать в С++. Естественно, хочется, чтобы это работало приемлемо быстро для больших файлов (например, от одного мегабайта и больше).

Первое, что сходу приходит в голову (универсальная кондовая классика):

std::ifstream is("testfile.txt");
std::string v;
char buf[N];
while (is) { 
  is.read(buf, sizeof(buf));
  v.append(buf, is.gcount());
}

где с размером буфера N можно еще проиграться, выбрав оптимальный.

Первое улучшение, приходящее в голову — это распределить заранее внутренний буфер для строки, минимизировав количество перераспределений буфера в процессе чтения. Для этого мы, естественно, должны заранее знать размер читаемого файла. Пусть это будет 1 мегабайт (1024*1024).

std::ifstream is("testfile.txt");
std::string v;
// Резервируем внутренний буфер std::string на указанный
// размер в один мегабайт.
v.reserve(1024*1024);
char buf[N];
while (is) { 
  is.read(buf, sizeof(buf));
  v.append(buf, is.gcount());
}

Далее на сцену выходят STL-алгоритмы и потоковые итераторы. Берем типовой пример использования алгоритма stl::copy, который есть практически в любой книге по С++:

std::ifstream is("testfile.txt");
std::string v;
// Сброс данного флага необходим для отключения пропуска пробельных
// символов при форматном вводе через поток.
is.unsetf(std::ios::skipws);
std::copy(
  std::istream_iterator<char>(is), 
  std::istream_iterator<char>(), 
  std::back_inserter(v)
);

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

std::ifstream is("testfile.txt");
std::string v;
// Резервируем внутренний буфер std::string на указанный
// размер в один мегабайт.
v.reserve(1024*1024);
is.unsetf(std::ios::skipws);
std::copy(
  std::istream_iterator<char>(is), 
  std::istream_iterator<char>(), 
  std::back_inserter(v)
);

В рассмотренном методе видно, что сначала данные изымаются из потока потоковым итератором istream_iterator, а потом кладутся через итератор строки back_inserter в саму строку. Двойная работа. Есть метод лучше — класть данные из потока напрямую в строку, используя один из специальных конструкторов класса std::string:

std::ifstream is("testfile.txt");
is.unsetf(std::ios::skipws);
// Самое интересное происходит тут: создается переменная "v"
// через конструктор, работающий напрямую с итераторами потока,
// и данные напрямую поступают во внутренний буфер строки.
std::string v(
  (std::istream_iterator<char>(is)), 
  std::istream_iterator<char>()
);

Опытный читатель заметит казалось бы ненужные обрамляющие скобки вокруг первого параметра. Сразу скажу — без них работать не будет, а будет ошибка компиляции. Тут мы касаемся одного из "темных углов" С++. Это не самый очевидный вопрос, поэтому я посвятил ему отдельную статью.

Уже лучше, но двигаемся дальше. В потоках ввода есть специальные итераторы istreambuf_iterator, которые работают напрямую с внутренними буферами потока в обход всех высокоуровневых функций форматирования и выходного преобразования. Именно по этому для них вызов функции unsetf будет уже не нужен:

std::ifstream is("testfile.txt");
std::string v;
// Опциональное резервирование буфера приемной строки.
v.reserve(1024*1024);
std::copy(
  std::istreambuf_iterator<char>(is), 
  std::istreambuf_iterator<char>(),
  std::back_inserter(v) 
);

И теперь вариант через конструктор класса std::string:

std::ifstream is("testfile.txt");
std::string v(
  (std::istreambuf_iterator<char>(is)), 
  std::istreambuf_iterator<char>()
);

Мы уже близки к идеалу. Теперь встроим создание объекта std::ifstream прямо в код создания строки:

std::string v(
  (std::istreambuf_iterator<char>(
    std::ifstream("testfile.txt")
  )), 
  std::istreambuf_iterator<char>()
);

Мы уже в миллиметре от идеала, но в приведенном примере есть одно большое "но". Вызов std::ifstream("testfile.txt") прямо в вызове конструктора создает временный объект, который по стандарту языка всегда является константой, а первый параметр конструктора ожидает принять не константный параметр, поэтому "строгий" компилятор типа gcc скорее всего выдаст ошибку компиляции, а менее "строгий", например cl.exe от Майкрософта на такой вызов не ругается. Но мы не можем принять такое не универсальное решение, поэтому изменим код, чтобы параметр создавался динамически в куче, а для автоматического его удаления будет использоваться std::auto_ptr:

std::string v(
  (std::istreambuf_iterator<char>(
    *(std::auto_ptr<std::ifstream>(
      new std::ifstream("testfile.txt")
    )).get()
  )), 
  std::istreambuf_iterator<char>()
);

Этот код должен работать в любом стандартном компиляторе С++.

Оглядимся назад. У нас столько вариантов — какой выбрать? Для начала, скорость. Надо понять, какой вариант работает банально быстрее. Для этого я собрал все эти варианты в тестовую программу (конечно, с использованием Google Test Framework).

Как я уже писал, вы можете скачать мою модификацию этой библиотеки, которая сокращена до двух необходимых файлов gtest/gtest.h и gtest-all.cc.

Файл filereader_unittest.cpp:

#include <gtest/gtest.h>

#include <iostream>
#include <streambuf>
#include <istream>
#include <fstream>
#include <ios>
#include <iomanip>
#include <string>
#include <vector>
#include <memory>
#include <cstdlib>

// Управляющий класс для нашей среды тестирования.
class Env: public testing::Environment {
public:
  // Размер тестового файла: 1 мегабайт.
  static int testfile_sz() { return 1024 * 1024; }
  // Имя тестового файла.
  static const char* testfile() { return "testfile"; }

protected:
  // Эта функция вызывается один раз в начале тестирования.
  // Она создает тестовый файл.
  void SetUp() {
    std::string dummy(testfile_sz(), 'x');
    std::ofstream os(testfile());
    os.write(dummy.c_str(), dummy.length());
  }

  // Эта функция вызывается один раз после всех тестов.
  // Она удаляет тестовый файл.
  void TearDown() {
    std::remove(testfile());
  }
};

// Функция, реализующая классический метод чтения файла кусками
// заданной длины N. При необходимости производится предварительное
// распределение буфера приемной строки.
void rawRead(int N, bool reserve) {
  std::ifstream is(Env::testfile());

  std::string v;
  if (reserve)
    v.reserve(Env::testfile_sz());

  char* buf = new char[N];
  while (is) {
    is.read(buf, sizeof(buf));
    v.append(buf, is.gcount());
  }
  delete[] buf;

  // На всякий случай проверяем размер считанного файла.
  EXPECT_EQ(Env::testfile_sz(), v.length()); 
}

// Классическое чтение с буфером в 100 байт.
TEST(ReaderTest, raw_100) {
  rawRead(100, false);
}

// Классическое чтение с буфером в 1 килобайт.
TEST(ReaderTest, raw_1024) {
  rawRead(1024, false);
}

// Классическое чтение с буфером в 10 килобайт.
TEST(ReaderTest, raw_10240) {
  rawRead(10240, false);
}

// Классическое чтение с буфером в 10 килобайт с предварительным
// распределением буфера приемной строки.
TEST(ReaderTest, raw_reserve_10240) {
  rawRead(10240, true);
}

// Функция, реализующая чтение через итератор istream_iterator.
// При необходимости производится предварительное распределение 
// буфера приемной строки.
void check_istream_iterator(bool reserve) {
  std::ifstream is(Env::testfile());

  std::string v;
  if (reserve)
    v.reserve(Env::testfile_sz());

  // Принудительное игнорирование пропуска пробельных символов.
  // С этим флагом двоичные данные будут читаться неверно.
  is.unsetf(std::ios::skipws);
  std::copy(
    std::istream_iterator<char>(is), 
    std::istream_iterator<char>(), 
    std::back_inserter(v)
  );

  // На всякий случай проверяем размер считанного файла.
  EXPECT_EQ(Env::testfile_sz(), v.length()); 
}

// Тестируем работу через istream_iterator.
TEST(ReaderTest, istream_iterator) {
  check_istream_iterator(false);  
}

// Тестируем работу через istream_iterator с предварительным
// распределением буфера приемной строки.
TEST(ReaderTest, istream_iterator_reserve) {
  check_istream_iterator(true);  
}

// Тестируем работу через istream_iterator при прямом
// вызове конструктора строки, который берет данные напрямую
// из итераторов.
TEST(ReaderTest, istream_iterator_tostring) {
  std::ifstream is(Env::testfile());
  is.unsetf(std::ios::skipws);

  std::string v(
    (std::istream_iterator<char>(is)), 
    std::istream_iterator<char>()
  );

  // На всякий случай проверяем размер считанного файла.
  EXPECT_EQ(Env::testfile_sz(), v.length()); 
}

// Функция, реализующая чтение через итератор istreambuf_iterator.
// При необходимости производится предварительное распределение 
// буфера приемной строки. Для данного метода сброс флага
// std::ios::skipws не нужен, так как этот итератор работает
// на более низком уровне.
void check_istreambuf_iterator(bool reserve) {
  std::ifstream is(Env::testfile());

  std::string v;
  if (reserve)
    v.reserve(Env::testfile_sz());

  std::copy(
    std::istreambuf_iterator<char>(is), 
    std::istreambuf_iterator<char>(),
    std::back_inserter(v)  
  );

  // На всякий случай проверяем размер считанного файла.
  EXPECT_EQ(Env::testfile_sz(), v.length()); 
}

// Тестируем работу через istreambuf_iterator.
TEST(ReaderTest, istreambuf_iterator) {
  check_istreambuf_iterator(false);
}

// Тестируем работу через istreambuf_iterator с предварительным
// распределением буфера приемной строки.
TEST(ReaderTest, istreambuf_iterator_reserve) {
  check_istreambuf_iterator(true);
}

// Тестируем работу через istreambuf_iterator при прямом
// вызове конструктора строки, который берет данные напрямую
// из итераторов.
TEST(ReaderTest, istreambuf_iterator_tostring) {
  std::ifstream is(Env::testfile());

  std::string v(
    (std::istreambuf_iterator<char>(is)), 
    std::istreambuf_iterator<char>()
  );

  // На всякий случай проверяем размер считанного файла.
  EXPECT_EQ(Env::testfile_sz(), v.length()); 
}

#ifdef WIN32

// Этот тест аналогичен тесту istreambuf_iterator_tostring
// за исключение создания объекта потока прямо в вызове
// конструктора строки. Работает только в cl.exe, так как
// "стандартный" компилятор запрещает передавать временные
// объекты по неконстантной ссылке, а cl.exe почему-то это
// разрешает.
TEST(ReaderTest, istreambuf_iterator_tostring_short) {
  std::string v(
    (std::istreambuf_iterator<char>(
      std::ifstream(Env::testfile())
    )), 
    std::istreambuf_iterator<char>()
  );

  // На всякий случай проверяем размер считанного файла.
  EXPECT_EQ(Env::testfile_sz(), v.length()); 
}

#endif

// Финальный метод. Конструктор строки берет данные напрямую
// из итератора istreambuf_iterator. Объект потока создается
// динамически прямо в коде вызова конструктора строки через 
// std::auto_ptr.
TEST(ReaderTest, istreambuf_iterator_tostring_short_auto_ptr) {
  std::string v(
    (std::istreambuf_iterator<char>(
      *(std::auto_ptr<std::ifstream>(
        new std::ifstream(Env::testfile())
      )).get()
    )), 
    std::istreambuf_iterator<char>()
  );

  // На всякий случай проверяем размер считанного файла.
  EXPECT_EQ(Env::testfile_sz(), v.length()); 
}

// Запуск тестов.
int main(int argc, char **argv) {
  // Инициализация нашей тестовой среды.
  testing::AddGlobalTestEnvironment(new Env);
  testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

Для компиляции вам необходимы файлы gtest/gtest.h и gtest-all.cc (см. выше).

Для начала скомпилируем в Visual Studio 2008:

cl /Fefilereader_vs2008.exe /DWIN32 /O2 /arch:SSE2 /I. /EHsc filereader_unittest.cpp gtest-all.cc

Запускаем:

filereader_vs2008.exe --gtest_print_time

Опция --gtest_print_time указывает Google Test выводить время работы каждого теста.

Результат:

[==========] Running 12 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 12 tests from ReaderTest
[ RUN      ] ReaderTest.raw_100
[       OK ] ReaderTest.raw_100 (141 ms)
[ RUN      ] ReaderTest.raw_1024
[       OK ] ReaderTest.raw_1024 (94 ms)
[ RUN      ] ReaderTest.raw_10240
[       OK ] ReaderTest.raw_10240 (109 ms)
[ RUN      ] ReaderTest.raw_reserve_10240
[       OK ] ReaderTest.raw_reserve_10240 (94 ms)
[ RUN      ] ReaderTest.istream_iterator
[       OK ] ReaderTest.istream_iterator (359 ms)
[ RUN      ] ReaderTest.istream_iterator_reserve
[       OK ] ReaderTest.istream_iterator_reserve (344 ms)
[ RUN      ] ReaderTest.istream_iterator_tostring
[       OK ] ReaderTest.istream_iterator_tostring (281 ms)
[ RUN      ] ReaderTest.istreambuf_iterator
[       OK ] ReaderTest.istreambuf_iterator (141 ms)
[ RUN      ] ReaderTest.istreambuf_iterator_reserve
[       OK ] ReaderTest.istreambuf_iterator_reserve (125 ms)
[ RUN      ] ReaderTest.istreambuf_iterator_tostring
[       OK ] ReaderTest.istreambuf_iterator_tostring (78 ms)
[ RUN      ] ReaderTest.istreambuf_iterator_tostring_short
[       OK ] ReaderTest.istreambuf_iterator_tostring_short (67 ms)
[ RUN      ] ReaderTest.istreambuf_iterator_tostring_short_auto_ptr
[       OK ] ReaderTest.istreambuf_iterator_tostring_short_auto_ptr (78 ms)
[----------] 12 tests from ReaderTest (1891 ms total)

[----------] Global test environment tear-down
[==========] 12 tests from 1 test case ran. (1906 ms total)
[  PASSED  ] 12 tests.

Теперь в gcc 3.4.4:

g++ -O2 -funroll-all-loops -fomit-frame-pointer -msse2 -mtune=nocona -I. -o filereader_gcc344.exe filereader_unittest.cpp gtest-all.cc

Запускаем:

filereader_gcc344.exe --gtest_print_time

Результат:

[==========] Running 11 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 11 tests from ReaderTest
[ RUN      ] ReaderTest.raw_100
[       OK ] ReaderTest.raw_100 (647 ms)
[ RUN      ] ReaderTest.raw_1024
[       OK ] ReaderTest.raw_1024 (649 ms)
[ RUN      ] ReaderTest.raw_10240
[       OK ] ReaderTest.raw_10240 (647 ms)
[ RUN      ] ReaderTest.raw_reserve_10240
[       OK ] ReaderTest.raw_reserve_10240 (644 ms)
[ RUN      ] ReaderTest.istream_iterator
[       OK ] ReaderTest.istream_iterator (2141 ms)
[ RUN      ] ReaderTest.istream_iterator_reserve
[       OK ] ReaderTest.istream_iterator_reserve (2131 ms)
[ RUN      ] ReaderTest.istream_iterator_tostring
[       OK ] ReaderTest.istream_iterator_tostring (1115 ms)
[ RUN      ] ReaderTest.istreambuf_iterator
[       OK ] ReaderTest.istreambuf_iterator (1124 ms)
[ RUN      ] ReaderTest.istreambuf_iterator_reserve
[       OK ] ReaderTest.istreambuf_iterator_reserve (1120 ms)
[ RUN      ] ReaderTest.istreambuf_iterator_tostring
[       OK ] ReaderTest.istreambuf_iterator_tostring (76 ms)
[ RUN      ] ReaderTest.istreambuf_iterator_tostring_short_auto_ptr
[       OK ] ReaderTest.istreambuf_iterator_tostring_short_auto_ptr (74 ms)
[----------] 11 tests from ReaderTest (10371 ms total)

[----------] Global test environment tear-down
[==========] 11 tests from 1 test case ran. (10396 ms total)
[  PASSED  ] 11 tests.

Давайте проанализируем результаты.

Мы не будем сравнивать абсолютные времена компиляторов друг против друга. Сейчас не об этом.

Вывод первый. Предварительное резервирование буфера приемной строки (метод reserve()) не дает никакого эффекта в нашем случае. Может это из-за того, что стратегия расширения буфера при простом линейном добавлении данных итак весьма эффективна в классе std::string.

Вывод второй. Размер буфера чтения в методе чтения файла явными кусками установленного размера не дал четкой картины. Не очевидно, какой размер буфера может быть потенциально оптимальным. Тут может и дисковый кэш повлиял, может внутреннее буферизирование в классе std::ifstream, может что-то еще.

Вывод третий. Работа через итератор istream_iterator является крайне медленной. Возможно это связано с накладными расходами на форматные преобразования, производимые данным классом и совершенно ненужные в нашей задаче. Для реального использования данный метод практически непригоден.

Вывод четвертый. Использование конструктора класса std::string, работающего напрямую с итераторами потока, заметно быстрее, чем использование алгоритма std::copy (ReaderTest.istream_iterator заметно медленнее ReaderTest.istream_iterator_tostring и ReaderTest.istreambuf_iterator заметно медленнее ReaderTest.istreambuf_iterator_tostring). И понятно почему — данные напрямую поступают в буфер строки без ненужного промежуточного копирования.

Вывод пятый (основной). Метод чтения через итератор istreambuf_iterator с использованием конструктора строки, работающего напрямую с итераторами потока (тест ReaderTest.istreambuf_iterator_tostring для "нестрогого" компилятора и тест ReaderTest.istreambuf_iterator_tostring_auto_ptr для компилятора, следующего стандартам), является весьма эффективным и может конкурировать с ручным блочным чтением. Конечно, текст данного метода весьма непрост и может запутан для понимания на первый взгляд, особенно для начинающих, а блочное чтения прозрачно и ясно, но при почти равной эффективности этих методов нет причин отказываться от работы через итераторы, так как данный метод весь фактически предоставляется библиотекой STL, а значит быть может оптимизирован независимо, без затрагивания кода уже использующей его программы.


Другие посты по теме:

• Темные углы C++
• Unit-тестирование для параллельных потоков