Access singletons with a new GetInstance() method instead of Singleton<T>.

This CL add a GetInstance() method to singleton classes instead of relying on the callers to use Singleton<T>.

In some cases I have used the LazyInstance<T> pattern as that was simpler.

This is a small step towards making all singleton classes use the Singleton<T> pattern within their code and not expect the callers to know about it.

I have selected all files under src/app and src/base which use Singleton<T> in this CL. Once this CL goes in I'll work on the rest of the files.

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

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

[M-A Ruel, 2010-12-03 21:06:06]

lgtm with nits

http://codereview.chromium.org/5527004/diff/12001/app/active_window_watcher_x.h
File app/active_window_watcher_x.h (right):

http://codereview.chromium.org/5527004/diff/12001/app/active_window_watcher_x...
app/active_window_watcher_x.h:31: static ActiveWindowWatcherX* GetInstance();
I don't think this class is necessary.

http://codereview.chromium.org/5527004/diff/12001/base/logging_win.h
File base/logging_win.h (right):

http://codereview.chromium.org/5527004/diff/12001/base/logging_win.h#newcode13
base/logging_win.h:13: #include "base/singleton.h"
I think you could forward declare the trait instead.

[darin (slow to review), 2010-12-03 21:15:38]

Can we do anything clever to prevent multiple instantiations of Singleton<T> for
the same value of T?  If we do not do that, then we run the risk of breaking the
Multi-DLL build too easily.

[M-A Ruel, 2010-12-03 21:27:39]

On 2010/12/03 21:15:38, darin wrote:
> Can we do anything clever to prevent multiple instantiations of Singleton<T>
for
> the same value of T?  If we do not do that, then we run the risk of breaking
the
> Multi-DLL build too easily.

Across different dynamic libraries, it's impossible unless you use a post link
tool to check manually for the symbols.

By putting all the Singleton instantiations in .cc files, that should fix the
problem.

[darin (slow to review), 2010-12-03 22:26:16]

On Fri, Dec 3, 2010 at 1:27 PM, <maruel@chromium.org> wrote:

> On 2010/12/03 21:15:38, darin wrote:
>
>> Can we do anything clever to prevent multiple instantiations of
>> Singleton<T>
>>
> for
>
>> the same value of T?  If we do not do that, then we run the risk of
>> breaking
>>
> the
>
>> Multi-DLL build too easily.
>>
>
> Across different dynamic libraries, it's impossible unless you use a post
> link
> tool to check manually for the symbols.
>

Right... I was thinking that this would help us catch errors introduced in
the statically
linked build.  That seems valuable since the statically linked build is the
current default
build.

-Darin



>
> By putting all the Singleton instantiations in .cc files, that should fix
> the
> problem.
>
>

> http://codereview.chromium.org/5527004/
>

[Satish, 2010-12-03 23:44:48]

I was planning to make all members of Singleton<T> private, and mark T as a
friend, so Singleton can't be used in the same fashion as it is today. Are there
cases which this would not cover?

[darin (slow to review), 2010-12-04 00:39:01]

Yes...

class Foo {
 public:
  inline Foo* GetInstance() {
    return Singleton<Foo>::get();
  }
};

-Darin

On Fri, Dec 3, 2010 at 3:44 PM, <satish@chromium.org> wrote:

> I was planning to make all members of Singleton<T> private, and mark T as a
> friend, so Singleton can't be used in the same fashion as it is today. Are
> there
> cases which this would not cover?
>
>
> http://codereview.chromium.org/5527004/
>

[darin (slow to review), 2010-12-04 00:39:46]

But I think your idea is very good, and maybe my example is not compelling
enough.

-Darin


On Fri, Dec 3, 2010 at 4:38 PM, Darin Fisher <darin@chromium.org> wrote:

> Yes...
>
> class Foo {
>  public:
>   inline Foo* GetInstance() {
>     return Singleton<Foo>::get();
>   }
> };
>
> -Darin
>
> On Fri, Dec 3, 2010 at 3:44 PM, <satish@chromium.org> wrote:
>
>> I was planning to make all members of Singleton<T> private, and mark T as
>> a
>> friend, so Singleton can't be used in the same fashion as it is today. Are
>> there
>> cases which this would not cover?
>>
>>
>> http://codereview.chromium.org/5527004/
>>
>
>

[Satish, 2010-12-04 12:12:31]

Yes using the Singleton<T> inline in the header file is an issue I considered.
Would a presubmit check be suitable to prevent using the string "Singleton<" in
any header?

[darin (slow to review), 2010-12-04 21:05:27]

SGTM!

On Sat, Dec 4, 2010 at 4:12 AM, <satish@chromium.org> wrote:

> Yes using the Singleton<T> inline in the header file is an issue I
> considered.
> Would a presubmit check be suitable to prevent using the string
> "Singleton<" in
> any header?
>
>
> http://codereview.chromium.org/5527004/
>

[Satish, 2010-12-04 23:00:40]

http://codereview.chromium.org/5527004/diff/12001/app/active_window_watcher_x.h
File app/active_window_watcher_x.h (right):

http://codereview.chromium.org/5527004/diff/12001/app/active_window_watcher_x...
app/active_window_watcher_x.h:31: static ActiveWindowWatcherX* GetInstance();
On 2010/12/03 21:06:07, Marc-Antoine Ruel wrote:
> I don't think this class is necessary.

Removed

http://codereview.chromium.org/5527004/diff/12001/base/logging_win.h
File base/logging_win.h (right):

http://codereview.chromium.org/5527004/diff/12001/base/logging_win.h#newcode13
base/logging_win.h:13: #include "base/singleton.h"
On 2010/12/03 21:06:07, Marc-Antoine Ruel wrote:
> I think you could forward declare the trait instead.

Done.