Rewrite scoped_ptr<T>(NULL) to use the default ctor in remoting/.

Rewrite scoped_ptr<T>(NULL) to use the default ctor in remoting/.

This is the result of running the rewrite_scoped_ptr_ctor_null tool
across all files built on Linux in the remoting/ directory.

BUG=173286
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=206247

[Wez, 2013-06-13 17:15:52]

lgtm

https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
File remoting/codec/video_encoder_vp8.cc (right):

https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
remoting/codec/video_encoder_vp8.cc:36: last_timestamp_(0) {}
nit: Please put the closing brace back on the next line.

[dcheng, 2013-06-13 18:28:36]

https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
File remoting/codec/video_encoder_vp8.cc (right):

https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
remoting/codec/video_encoder_vp8.cc:36: last_timestamp_(0) {}
On 2013/06/13 17:15:52, Wez wrote:
> nit: Please put the closing brace back on the next line.

This is the result of clang-format-diff.py. If you feel strongly, I can manually
revert these by hand but future refactorings will likely keep doing the same
thing.

[Wez, 2013-06-13 18:41:02]

On 2013/06/13 18:28:36, dcheng wrote:
>
https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
> File remoting/codec/video_encoder_vp8.cc (right):
> 
>
https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
> remoting/codec/video_encoder_vp8.cc:36: last_timestamp_(0) {}
> On 2013/06/13 17:15:52, Wez wrote:
> > nit: Please put the closing brace back on the next line.
> 
> This is the result of clang-format-diff.py. If you feel strongly, I can
manually
> revert these by hand but future refactorings will likely keep doing the same
> thing.

Is it possible to fix clang-format-diff.py to generate style-guide-compatible
output for multi-line ctor definitions?

[dcheng, 2013-06-13 18:47:50]

On 2013/06/13 18:41:02, Wez wrote:
> On 2013/06/13 18:28:36, dcheng wrote:
> >
>
https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
> > File remoting/codec/video_encoder_vp8.cc (right):
> > 
> >
>
https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
> > remoting/codec/video_encoder_vp8.cc:36: last_timestamp_(0) {}
> > On 2013/06/13 17:15:52, Wez wrote:
> > > nit: Please put the closing brace back on the next line.
> > 
> > This is the result of clang-format-diff.py. If you feel strongly, I can
> manually
> > revert these by hand but future refactorings will likely keep doing the same
> > thing.
> 
> Is it possible to fix clang-format-diff.py to generate style-guide-compatible
> output for multi-line ctor definitions?

It is possible. However,
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Constr...
seems to suggest that this formatting is OK and is ultimately one of preference.
Where there is a choice, clang-format has generally picked one way and stuck
with it.

The biggest exception I know if is T* x vs T *x; clang-format only output T* x,
but since there was a lot of outcry, an option was added to allow T *x as well
=)

[Wez, 2013-06-13 19:00:49]

On 2013/06/13 18:47:50, dcheng wrote:
> On 2013/06/13 18:41:02, Wez wrote:
> > On 2013/06/13 18:28:36, dcheng wrote:
> > >
> >
>
https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
> > > File remoting/codec/video_encoder_vp8.cc (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
> > > remoting/codec/video_encoder_vp8.cc:36: last_timestamp_(0) {}
> > > On 2013/06/13 17:15:52, Wez wrote:
> > > > nit: Please put the closing brace back on the next line.
> > > 
> > > This is the result of clang-format-diff.py. If you feel strongly, I can
> > manually
> > > revert these by hand but future refactorings will likely keep doing the
same
> > > thing.
> > 
> > Is it possible to fix clang-format-diff.py to generate
style-guide-compatible
> > output for multi-line ctor definitions?
> 
> It is possible. However,
>
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Constr...
> seems to suggest that this formatting is OK and is ultimately one of
preference.

That section says that {} is OK iff it all fits on one line, which isn't the
case here.

[dcheng, 2013-06-13 19:05:56]

On 2013/06/13 19:00:49, Wez wrote:
> On 2013/06/13 18:47:50, dcheng wrote:
> > On 2013/06/13 18:41:02, Wez wrote:
> > > On 2013/06/13 18:28:36, dcheng wrote:
> > > >
> > >
> >
>
https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
> > > > File remoting/codec/video_encoder_vp8.cc (right):
> > > > 
> > > >
> > >
> >
>
https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
> > > > remoting/codec/video_encoder_vp8.cc:36: last_timestamp_(0) {}
> > > > On 2013/06/13 17:15:52, Wez wrote:
> > > > > nit: Please put the closing brace back on the next line.
> > > > 
> > > > This is the result of clang-format-diff.py. If you feel strongly, I can
> > > manually
> > > > revert these by hand but future refactorings will likely keep doing the
> same
> > > > thing.
> > > 
> > > Is it possible to fix clang-format-diff.py to generate
> style-guide-compatible
> > > output for multi-line ctor definitions?
> > 
> > It is possible. However,
> >
>
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Constr...
> > seems to suggest that this formatting is OK and is ultimately one of
> preference.
> 
> That section says that {} is OK iff it all fits on one line, which isn't the
> case here.

Maybe I'm missing something.
"The close curly brace is either on the last line by itself or (if other style
rules permit) on the same line as the open curly brace."
I would interpret that to mean that {} is OK, even if you have something like

void ReallyLongFunctionNameHere(
  int obnoxiously_long_parameter_name_there) {}

[Wez, 2013-06-13 19:57:15]

On 2013/06/13 19:05:56, dcheng wrote:
> On 2013/06/13 19:00:49, Wez wrote:
> > On 2013/06/13 18:47:50, dcheng wrote:
> > > On 2013/06/13 18:41:02, Wez wrote:
> > > > On 2013/06/13 18:28:36, dcheng wrote:
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
> > > > > File remoting/codec/video_encoder_vp8.cc (right):
> > > > > 
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
> > > > > remoting/codec/video_encoder_vp8.cc:36: last_timestamp_(0) {}
> > > > > On 2013/06/13 17:15:52, Wez wrote:
> > > > > > nit: Please put the closing brace back on the next line.
> > > > > 
> > > > > This is the result of clang-format-diff.py. If you feel strongly, I
can
> > > > manually
> > > > > revert these by hand but future refactorings will likely keep doing
the
> > same
> > > > > thing.
> > > > 
> > > > Is it possible to fix clang-format-diff.py to generate
> > style-guide-compatible
> > > > output for multi-line ctor definitions?
> > > 
> > > It is possible. However,
> > >
> >
>
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Constr...
> > > seems to suggest that this formatting is OK and is ultimately one of
> > preference.
> > 
> > That section says that {} is OK iff it all fits on one line, which isn't the
> > case here.
> 
> Maybe I'm missing something.
> "The close curly brace is either on the last line by itself or (if other style
> rules permit) on the same line as the open curly brace."

Right; the wording isn't actually very helpful, but the examples imply that the
braces should be split if the definition spans multiple lines.  There's a
similar pattern w/ if(), where we omit the {} iff it's a single-line condition
and single-line command.

How about we land this and file a bug against clang-format-diff.py / style-guide
for this case, rather than rathole this CL?

[dcheng, 2013-06-13 20:12:18]

On 2013/06/13 19:57:15, Wez wrote:
> On 2013/06/13 19:05:56, dcheng wrote:
> > On 2013/06/13 19:00:49, Wez wrote:
> > > On 2013/06/13 18:47:50, dcheng wrote:
> > > > On 2013/06/13 18:41:02, Wez wrote:
> > > > > On 2013/06/13 18:28:36, dcheng wrote:
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
> > > > > > File remoting/codec/video_encoder_vp8.cc (right):
> > > > > > 
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/16964002/diff/1/remoting/codec/video_encoder_...
> > > > > > remoting/codec/video_encoder_vp8.cc:36: last_timestamp_(0) {}
> > > > > > On 2013/06/13 17:15:52, Wez wrote:
> > > > > > > nit: Please put the closing brace back on the next line.
> > > > > > 
> > > > > > This is the result of clang-format-diff.py. If you feel strongly, I
> can
> > > > > manually
> > > > > > revert these by hand but future refactorings will likely keep doing
> the
> > > same
> > > > > > thing.
> > > > > 
> > > > > Is it possible to fix clang-format-diff.py to generate
> > > style-guide-compatible
> > > > > output for multi-line ctor definitions?
> > > > 
> > > > It is possible. However,
> > > >
> > >
> >
>
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Constr...
> > > > seems to suggest that this formatting is OK and is ultimately one of
> > > preference.
> > > 
> > > That section says that {} is OK iff it all fits on one line, which isn't
the
> > > case here.
> > 
> > Maybe I'm missing something.
> > "The close curly brace is either on the last line by itself or (if other
style
> > rules permit) on the same line as the open curly brace."
> 
> Right; the wording isn't actually very helpful, but the examples imply that
the
> braces should be split if the definition spans multiple lines.  There's a
> similar pattern w/ if(), where we omit the {} iff it's a single-line condition
> and single-line command.
> 
> How about we land this and file a bug against clang-format-diff.py /
style-guide
> for this case, rather than rathole this CL?

SGTM.

[commit-bot: I haz the power, 2013-06-13 20:13:02]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dcheng@chromium.org/16964002/1

[commit-bot: I haz the power, 2013-06-14 00:35:15]

Change committed as 206247