Re: [PATCH v2 5/5] Eliminate make_cleanup_ui_file_delete / make ui_file a class hierarchy

[Simon Marchi <simon dot marchi at polymtl dot ca>]

On 2017-01-24 13:29, Simon Marchi wrote:
> > @@ -420,22 +412,20 @@ c_compute_program (struct compile_instance 
> > *inst,
> >  			   ? "&" : ""));
> >        break;
> >      default:
> > -      fputs_unfiltered (input, buf);
> > +      buf.puts (input);
> >        break;
> >      }
> >
> > -  fputs_unfiltered ("\n", buf);
> > +  buf.puts ("\n");
> >
> >    /* For larger user expressions the automatic semicolons may be
> >       confusing.  */
> >    if (strchr (input, '\n') == NULL)
> > -    fputs_unfiltered (";\n", buf);
> > +    buf.puts (";\n");
> >
> >    if (inst->scope != COMPILE_I_RAW_SCOPE)
> > -    fputs_unfiltered ("}\n", buf);
> > +    buf.puts ("}\n");
> >
> > -  add_code_footer (inst->scope, buf);
> > -  code = ui_file_as_string (buf);
> > -  do_cleanups (cleanup);
> > -  return code;
> > +  add_code_footer (inst->scope, &buf);
> > +  return std::move (buf.string ());
>
> I would have thought that this std::move would be superfluous, because
> the compiler would do it anyway.  Is it the case?  Is it a good
> practice to use move explicitly to make sure it's a move and not a
> copy (and probably get a compile-time error if a move is not
> possible)?

Oh, I guess it's because buf.string() returns a reference and not a 
string directly.  Otherwise, then I guess the compiler could have done 
some return value optimization (look at me, using words I don't 
understand).