Должен этот C++ временная привязка к ссылочному участнику быть недопустимым?
Безопасность - проверяющий, что у пользователей есть соответствующие полномочия до выполнения определенных методов.
4 ответа
Я думаю, что это сложная часть, которая не слишком ясна. Пару дней назад был подобный вопрос.
По умолчанию временные объекты уничтожаются в обратном порядке построения, когда завершается полное выражение, в котором они были созданы. Здесь все хорошо и понятно, но затем возникают исключения (12.2 [class.temporary] / 4,5), и все становится запутанным.
Вместо того, чтобы иметь дело с точными формулировками и определениями в стандарте, я подхожу к проблеме с точки зрения разработки / компилятора. Временные библиотеки создаются в стеке, когда функция завершает работу, фрейм стека освобождается (указатель стека перемещается обратно в исходную позицию до начала вызова функции).
Это означает, что временный объект никогда не сможет выжить для функции, в которой он был создан. Точнее, он не может выжить в той области, в которой он был определен, даже если он действительно может пережить полное выражение , в котором он был создан.
Ни одно из исключений в стандарте не выходит за рамки этого ограничения, во всех случаях время жизни временного продлевается до точки, которая гарантированно не превысит время вызова функции, в которой временное устройство было создано.
Оригинальная статья Guru of the Week находится здесь: Guru of the Week # 15 .
Часть вашего ответа может исходить от самого Херба, в «Кандидат на самую важную константу» - «константная» часть присвоения временного значения ссылке действительно важна.
Таким образом, может показаться, что это ошибка в исходной статье.
Я всегда считал, что передача параметров адреса (по ссылке или указателю) требует понимания времени жизни переданного объекта. Период. Конец дискуссии. Это кажется просто атрибутом среды, не управляемой сборщиком мусора / НЕ управляемой ссылками.
Это одно из преимуществ GC.
В C ++ иногда проблемы времени жизни решались с помощью:
X :: clone
или явной документации интерфейса, например:
"это вплоть до создателя экземпляра Y, чтобы гарантировать, что экземпляр X, переданный в параметре x, остается существующим в течение всего времени существования Y »
или
явным копированием x в кишечнике получателя.
Это просто c ++. Этот c ++ добавил гарантию на ссылки на константу - это хорошо (и действительно в некоторой степени необходимо), но это было все.
Таким образом, я считаю код, показанный в вопросе, неправильным и считаю, что он должен был быть таким:
int main()
{
MyWorker w;
GenericTableAlgorithm a( "Customer", w);
a.Process();
}
Я не думаю, что вы можете сделать это с текущим C ++. Вам понадобится семантика перемещения , которая будет представлена в C ++ x0.