Как общаться, если в качестве аргумента разрешены ссылки, выделенные стеком?
Я ищу стандартный способ сообщить пользователю API C ++, принимает ли конструктор (или метод) объекты, размещенные в стеке, в качестве допустимых аргументов. Есть ли шаблон (например, специальная сигнатура конструктора / метода), который сообщает здесь нет стековых объектов/объекты стека здесь хорошо? Есть ли здравый смысл для предположения по умолчанию, если стековые объекты разрешены, если не задокументировано иное?
Иллюстрация проблемы: Когда урок Vector6D имеет конструктор Vector6D(const Vector3D& upper, const Vector3D& lower) класс может быть реализован как минимум двумя способами:
а) Скопируйте элементы двух векторов в конструктор и забудьте о Vector3D экземпляров.
б) агрегировать Vector3D случаи в Vector6D и продолжайте использовать ссылки для последующих вызовов методов.
Для а) не имеет значения, где Vector3D экземпляры выделены. Б) если Vector3D экземпляры размещаются в стеке, реализация перестает работать, когда кадр стека исчезает.
Поэтому, не глядя на реализацию или документацию, пользователь не может решить, что делать.
редактировать: Контекст является проектом встроенного программного обеспечения, и мне не разрешено использовать STL, исключения, повышение и т. Д.
Решение
В C ++ нет механизма, обеспечивающего, чтобы время жизни параметра конструктора (или другого метода-члена-члена) превышало время жизни объекта.
Только владение кучей выделенных объектов, хранящихся и передаваемых через std::unique_ptr<T>, std::shared_ptr<T>или аналогичные, могут быть четко выражены и перенесены.
Было бы плохим дизайном класса иметь специальные соглашения, не выполняемые компиляторами, намекающие на то, что аргументы хранятся в виде ссылок.
Вы должны рассмотреть следующие общие рекомендации:
- Дешево скопированные типы должны быть просто скопированы.
- Не копируемые типы должны быть выделены в куче и переданы / принадлежать через интеллектуальные указатели.
- Типы, которые считаются «слишком дорогими» для копирования, должны также иметь интеллектуальный указатель, если они должны постоянно использоваться совместно с другими объектами с независимым временем жизни.
Существуют исключения из этой политики распределения кучи, когда время жизни не контролируется пользователями API произвольно, но не в сценариях, подобных описанным выше.
Другие решения