Add a new function for getting a deterministic machine ID

chrome/browser/prefs/tracked/device_id.h

Index: chrome/browser/prefs/tracked/device_id.h
diff --git a/chrome/browser/prefs/tracked/device_id.h b/chrome/browser/prefs/tracked/device_id.h
new file mode 100644
index 0000000000000000000000000000000000000000..04280e97bbcaefb3c6f67d48d3c1ea44ff54d6a5
--- /dev/null
+++ b/chrome/browser/prefs/tracked/device_id.h
@@ -0,0 +1,12 @@
+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CHROME_BROWSER_PREFS_TRACKED_DEVICE_ID_H_
+#define CHROME_BROWSER_PREFS_TRACKED_DEVICE_ID_H_
+
+#include <string>
+
+bool GetDeterministicMachineSpecificId(std::string* machine_id);

[gab, 2015/01/20 15:34:12]

Add a method comment which starts with a verb stating the actions it results in,
e.g.:

// Populates |machine_id| with a deterministic ID for this machine. Returns
false on failure (in which case |machine_id|'s content is undefined and should
not be used).

In fact since we'll need to differentiate between "unsupported on platform" and
"failed to obtain ID" (easier for tests and users of the call will likely care
about the difference), how about changing the return type to an enum?

[alito, 2015/01/26 16:32:47]

Done.

+

[gab, 2015/01/20 15:34:12]

Now that I see it in context, I think it may make sense to wrap this in a
"tracked_prefs" namespace (similar to the "chrome_prefs" namespace used in
chrome_pref_service_factory.h for similar free functions).

I always forget the exact guidance on namespaces in Chromium, probably because
there isn't even a clear agreement among Chromium devs (latest discussion on the
topic:
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/pcgYLSJsii8/E3K_K...).

From the Google C++ Style Guide:

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Nonmem...

"Sometimes it is useful, or even necessary, to define a function not bound to a
class instance. Such a function can be either a static member or a nonmember
function. Nonmember functions should not depend on external variables, and
should nearly always exist in a namespace. Rather than creating classes only to
group static member functions which do not share static data, use namespaces
instead."

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Namespaces

"With named namespaces, choose the name based on the project, and possibly its
path."


Therefore it feels like a "tracked_prefs" namespace here is the right thing
after all (sorry if I told you the opposite when we first discussed it, I
changed my mind after seeing it..).


@grt: WDYT, any opinion/guidance on namespace usage in Chromium?

[alito, 2015/01/26 16:32:47]

Done.

[grt (UTC plus 2), 2015/01/27 17:06:22]

In general, I avoid them since I'm tired of having the discussion. :-)  The
"chrome" namespace is flat out banned, as I understand it. In this case, I think
a tracked_prefs namespace to hold an enum and a single function is overkill.

[gab, 2015/01/27 18:27:40]

Ok sounds good, I'm happy with none as well, especially with enum class since it
doesn't pollute the (global) namespace.

[alito, 2015/01/27 20:56:55]

Done.

+#endif  // CHROME_BROWSER_PREFS_TRACKED_DEVICE_ID_H_