Initialize observer_ to nullptr in DevicePermissionsDialogView.

chrome/browser/ui/views/extensions/device_permissions_dialog_view.cc

 // Copyright 2014 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.
 
 #include "chrome/browser/ui/views/extensions/device_permissions_dialog_view.h"
 
 #include "base/strings/utf_string_conversions.h"
 #include "chrome/browser/extensions/api/chrome_device_permissions_prompt.h"
 #include "chrome/grit/generated_resources.h"
 #include "components/constrained_window/constrained_window_views.h"
@@ skipping 26 matching lines @@
   // ui::TableModel
   int RowCount() override;
   base::string16 GetText(int row, int column) override;
   void SetObserver(ui::TableModelObserver* observer) override;
 
   // extensions::DevicePermissionsPrompt::Prompt::Observer
   void OnDevicesChanged() override;
 
  private:
   scoped_refptr<DevicePermissionsPrompt::Prompt> prompt_;
-  ui::TableModelObserver* observer_;
+  ui::TableModelObserver* observer_ = nullptr;

[benwells, 2015/04/08 22:53:22]

since you already have an initializer list in the constructor, why not do it
there, the old fashioned way?

[Reilly Grant (use Gerrit), 2015/04/08 22:57:25]

This method guarantees that any future constructor will also inherit this
default behavior. Disregarding the initializer list in the constructor this
feels equivalent to the way that the scoped_refptr above would be initialized to
nullptr because that's what its default constructor does. This is simply working
around the lack of a default constructor for raw pointer types.

[benwells, 2015/04/08 23:44:29]

Yes, I understand that this will be caught by all future constructors.

Can you see that it might be confusing for people reading the code?

[Reilly Grant (use Gerrit), 2015/04/09 00:06:35]

I disagree that this is confusing. This method is clearer than constructor
initialization lists because one can tell from reading only the field
declarations that they will all be initialized without having to check that the
(possibly multiple) constructors aren't missing something.

From personal experience I am very likely to shoot myself in the foot by adding
a primitive type field to a class and forgetting to add an initializer to the
constructor. Combining these two in one place seems like a net win.

 };
 
 int DevicePermissionsTableModel::RowCount() {
   return prompt_->GetDeviceCount();
 }
 
 base::string16 DevicePermissionsTableModel::GetText(int row, int col_id) {
   switch (col_id) {
     case IDS_DEVICE_PERMISSIONS_DIALOG_DEVICE_NAME_COLUMN:
       return prompt_->GetDeviceName(row);
@@ skipping 97 matching lines @@
 
 gfx::Size DevicePermissionsDialogView::GetPreferredSize() const {
   return gfx::Size(500, 250);
 }
 
 void ChromeDevicePermissionsPrompt::ShowDialog() {
   DCHECK_CURRENTLY_ON(content::BrowserThread::UI);
   constrained_window::ShowWebModalDialogViews(
       new DevicePermissionsDialogView(delegate(), prompt()), web_contents());
 }