Add a new GetInstance() method for singleton classes used in chrome/browser files.

Add a new GetInstance() method for singleton classes used in chrome/browser files.

This CL includes half of the files under chrome/browser using Singleton<T>.
The rest of the files will be sent in a second CL.

In one case I used a LazyInstance<T> instead of Singleton<T> as that was simpler and necessary since T was a typedef and can't add member functions to it.

BUG=65298
TEST=all existing tests should continue to pass.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=68723

[joth, 2010-12-08 17:15:07]

Looks good, would be nice if we can remove the include pollution too (will need
to add the #include to all the .cc instead)

http://codereview.chromium.org/5519016/diff/3001/chrome/browser/browser_about...
File chrome/browser/browser_about_handler.h (right):

http://codereview.chromium.org/5519016/diff/3001/chrome/browser/browser_about...
chrome/browser/browser_about_handler.h:15: #include "base/singleton.h"
It looks like you can remove this include and forward declare instead:

template<typename Type>
struct DefaultSingletonTraits;

http://codereview.chromium.org/5519016/diff/3001/chrome/browser/crash_handler...
File chrome/browser/crash_handler_host_linux.h (right):

http://codereview.chromium.org/5519016/diff/3001/chrome/browser/crash_handler...
chrome/browser/crash_handler_host_linux.h:13: #include "base/singleton.h"
remove

http://codereview.chromium.org/5519016/diff/3001/chrome/browser/cross_site_re...
File chrome/browser/cross_site_request_manager.h (right):

http://codereview.chromium.org/5519016/diff/3001/chrome/browser/cross_site_re...
chrome/browser/cross_site_request_manager.h:14: #include "base/singleton.h"
remove

http://codereview.chromium.org/5519016/diff/3001/chrome/browser/dom_ui/chrome...
File chrome/browser/dom_ui/chrome_url_data_manager.h (right):

http://codereview.chromium.org/5519016/diff/3001/chrome/browser/dom_ui/chrome...
chrome/browser/dom_ui/chrome_url_data_manager.h:134: ~ChromeURLDataManager();
c'tor & d'tor go before all methods (inc. static methods)

http://codereview.chromium.org/5519016/diff/3001/chrome/browser/renderer_host...
File chrome/browser/renderer_host/render_sandbox_host_linux.h (right):

http://codereview.chromium.org/5519016/diff/3001/chrome/browser/renderer_host...
chrome/browser/renderer_host/render_sandbox_host_linux.h:14: #include
"base/singleton.h"
remove

http://codereview.chromium.org/5519016/diff/3001/chrome/browser/translate/tra...
File chrome/browser/translate/translate_manager.h (right):

http://codereview.chromium.org/5519016/diff/3001/chrome/browser/translate/tra...
chrome/browser/translate/translate_manager.h:15: #include "base/singleton.h"
remove

http://codereview.chromium.org/5519016/diff/3001/chrome/browser/ui/app_modal_...
File chrome/browser/ui/app_modal_dialogs/app_modal_dialog_queue.h (right):

http://codereview.chromium.org/5519016/diff/3001/chrome/browser/ui/app_modal_...
chrome/browser/ui/app_modal_dialogs/app_modal_dialog_queue.h:11: #include
"base/singleton.h"
remove?

[Satish, 2010-12-08 17:56:52]

I prefer forward declarations as well if the type is used in a small number of
headers. But forward declaring a type from /base in every single header which
uses it seems ugly and needs to be updated if say the default traits changed in
future. Though this reduces the include pollution arguably it introduces forward
declaration pollution :) so I think it is better to include the header in this
case. Are there other strong reasons for doing the forward decl?

[willchan no longer on Chromium, 2010-12-08 18:08:19]

Apparently I was sloppier than I had intended in my review of your other
change.  I agree with joth here.  I prefer the forward declaration.  If the
default traits changes in the future, you'll have to update every file
anyway since they all use friend declarations anyway.  It just doubles the
spots within the file.  Using forward declarations makes the build faster.
 I think it's worth it.

On Wed, Dec 8, 2010 at 9:56 AM, <satish@chromium.org> wrote:

> I prefer forward declarations as well if the type is used in a small number
> of
> headers. But forward declaring a type from /base in every single header
> which
> uses it seems ugly and needs to be updated if say the default traits
> changed in
> future. Though this reduces the include pollution arguably it introduces
> forward
> declaration pollution :) so I think it is better to include the header in
> this
> case. Are there other strong reasons for doing the forward decl?
>
>
> http://codereview.chromium.org/5519016/
>

[Satish, 2010-12-08 23:03:58]

Thanks, I've now changed the headers to use forward declarations as suggested.

[joth, 2010-12-08 23:25:13]

LGTM
[[ I just read the delta from patch set 1; assume the TOUCH_UI deletion was
due to a rebase?

On 8 December 2010 23:03, <satish@chromium.org> wrote:

> Thanks, I've now changed the headers to use forward declarations as
> suggested.
>
>
> http://codereview.chromium.org/5519016/
>

[Satish, 2010-12-08 23:31:24]

> [[ I just read the delta from patch set 1; assume the TOUCH_UI deletion was
> due to a rebase?

Yes it is, the diff from trunk doesn't touch that portion.