Я просто думал о реализации std::string::substr
.Он возвращает новый std::string
объект, который мне кажется немного расточительным.Почему бы не вернуть объект, который ссылается на содержимое исходной строки и может быть неявно присвоен std::string
?Этакая ленивая оценка фактического копирования.Такой класс может выглядеть примерно так:
template <class Ch, class Tr, class A>
class string_ref {
public:
// not important yet, but *looks* like basic_string's for the most part
private:
const basic_string<Ch, Tr, A> &s_;
const size_type pos_;
const size_type len_;
};
Открытый интерфейс этого класса будет имитировать все операции только для чтения реального std::string
, поэтому его использование будет беспроблемным.std::string
может иметь новый конструктор, который принимает string_ref
, поэтому пользователь никогда не станет мудрее.В тот момент, когда вы пытаетесь «сохранить» результат, вы в конечном итоге создаете копию, поэтому никаких реальных проблем со ссылкой, указывающей на данные, и последующим ее изменением за спиной.
Идея в том, что этот код подобен этому:
std::string s1 = "hello world";
std::string s2 = "world";
if(s1.substr(6) == s2) {
std::cout << "match!" << std::endl;
}
будет иметь в общей сложности не более 2 std::string
объектов.Это кажется полезной оптимизацией для кода, который выполняет много строковых манипуляций.Конечно, это относится не только к std::string
, но и к любому типу, который может возвращать подмножество его содержимого.
Насколько я знаю, никакие реализации не делают этого.
Я предполагаю, что суть вопроса заключается в следующем:
Учитывая класс, который может быть неявно преобразован в std::string
по мере необходимости, будет ли соответствовать стандарту для автора библиотеки изменение прототипа члена натип возврата?Или, в более общем смысле, имеют ли разработчики библиотеки возможность вернуть «прокси-объекты» вместо обычных объектов в этих типах случаев в качестве оптимизации?
Мне кажется, что это недопустимо и что прототипы должны совпадатьименно так.Учитывая, что вы не можете перегрузить только тип возвращаемого значения, это не оставит возможность авторам библиотек воспользоваться этими типами ситуаций.Как я уже сказал, я думаю, что ответ - нет, но я решил спросить: -).