Конструкторы
То есть каждый из 10 000 элементов vr инициализируется конструктором Record(), а каждый из s1 элементов контейнера vi инициализируется int().
Инициализация 10 000 элементов конструктором по умолчанию не может не впечатлять -- только в очень редком случае нужно именно это. Если вы выделяете эти 10 000 элементов про запас, для последующей перезаписи, то стоит подумать о следующей альтернативе: vector<X> vx; // объявляем пустой вектор vx.reserve(10000); // резервируем место воизбежание "дорогих" // перераспределений в push_back() // ... vx.push_back(x_work); // добавляем элементы по мере надобности
О ней тем более стоит подумать, т.к. даже в отличной реализации STL 3.2 от sgi конструктор vector<int> vi(s1);
подразумевает явный цикл заполнения нулями: for (int i=0; i<s1; i++) vi.elements[i]=0;
и требуется достаточно интеллектуальный оптимизатор для превращения этого цикла в вызов memset(): memset(vi.elements, 0, sizeof(int)*s1);
что значительно улучшит производительность (конечно не программы вообще, а только данного отрезка кода). Matt Austern поставлен в известность, и в будущих версиях sgi STL можно ожидать повышения производительности данного конструктора.
Реализация basic_string хранит длину строки, не полагаясь на завершающий символ (ноль).
Вместе с тем, хорошо оптимизированные реализации хранят строку вместе с завершающим нулем, дабы максимально ускорить функцию basic_string::c_str(). Не секрет, что большинство используемых функций (традиционно) принимают строку в виде [const] char* вместо эквивалентного по смыслу [const] string&, исходя из того простого факта, что мы не можем ускорить "безопасную" реализацию, но можем скрыть эффективную за безопасным интерфейсом.
К слову сказать, мой личный опыт свидетельствует о том, что слухи об опасности манипулирования простыми char* в стиле C оказываются сильно преувеличенными. Да, вы должны следить за всеми мелочами, но, например, ни у кого не возникает протеста по поводу того, что если в формуле корней квадратного уравнения мы вместо '-' напишем '+', то результат будет неверен.
Резюмируя данный абзац, хочу сказать, что string использовать можно и нужно, но если логика работы вашей программы интенсивно использует манипуляции со строками, стоит подумать о разработке собственных средств, основанных на функциях типа memcpy(), а в "узких" местах без этого просто не обойтись.