On Tue, Oct 9, 2018 at 1:19 PM David Malcolm <dmalc...@redhat.com> wrote:
> + /* Emulation of a "move" constructor, but really a copy
> + constructor. */
> +
> + name_hint (const name_hint &other)
> + : m_suggestion (other.m_suggestion),
> + m_deferred (const_cast<name_hint &> (other).take_deferred ())
> + {
> + }
> +
> + /* Emulation of "move" assigment, but really copy assignment. */
> +
> + name_hint& operator= (const name_hint &other)
> + {
> + m_suggestion = other.m_suggestion;
> + m_deferred = const_cast<name_hint &> (other).take_deferred ();
> + return *this;
> + }
> +
> + /* Take ownership of this name_hint's deferred_diagnostic, for use
> + in chaining up deferred diagnostics. */
> + gnu::unique_ptr<deferred_diagnostic> take_deferred () { return move
> (m_deferred); }
Why do you want to propagate this hackery into name_hint? I would
expect the defaulted special member functions to do the right thing
with m_deferred: in -std=c++98 the implicit copy ops call the
gnu::unique_ptr copy ops that actually move, and in -std=c++11 and up
we're calling the move constructor for std::unique_ptr, which does the
right thing.
This also doesn't limit the hack to C++98 mode the way unique-ptr.h does.
Jason
