Remove void** from disk_cache interface.

net/disk_cache/blockfile/backend_impl.cc

Index: net/disk_cache/blockfile/backend_impl.cc
diff --git a/net/disk_cache/blockfile/backend_impl.cc b/net/disk_cache/blockfile/backend_impl.cc
index 884dd2d43a273456402de96beb5b642529eb0a6e..9c8d03a29d2b593f16331d04a1270df3811601c5 100644
--- a/net/disk_cache/blockfile/backend_impl.cc
+++ b/net/disk_cache/blockfile/backend_impl.cc
@@ -1199,16 +1199,33 @@ int BackendImpl::DoomEntriesSince(const base::Time initial_time,
   return net::ERR_IO_PENDING;
 }
 
-int BackendImpl::OpenNextEntry(void** iter, Entry** next_entry,
+int BackendImpl::OpenNextEntry(Iterator* iter, Entry** next_entry,
                                const CompletionCallback& callback) {
+  // TODO(gavinp): Remove all void** iter from cache.
   DCHECK(!callback.is_null());
-  background_queue_.OpenNextEntry(iter, next_entry, callback);
-  return net::ERR_IO_PENDING;
-}
+  class State : public EnumerationState {

[clamy, 2014/09/04 18:22:01]

Maybe it's just me, but I find class definitions inside a function a bit hard to
read. Especially with a function argument called iter, and a class member iter_
- which are quite different, as far as I can tell.

[gavinp, 2014/09/04 18:31:46]

As it happens, I had to move this out of the function in BackendImpl, in order
to support building the dump_cache --upgrade feature, a windows only
functionality of dump_cache that depends on BackendImpl::OpenPrevEntry in the
blockfile backend.

So perhaps you'll like the latest upload; I renamed the confusing iter method
and member to the less confusing "data", which seems like it describes a void**
just fine.

I slightly prefer declaring these classes inside the functions; the reason is
just that we're doing some crazy stuff with static casts, and declaring it in
the function makes a strong statement about where you can expect that to occur,
and where the Backend::Iterator() will obey its normal interface. Do you have
the same concerns about the maybe more readable call sites in SimpleBackendImpl
or MemoryBackendImpl?

[clamy, 2014/09/04 19:01:37]

Yes the version with "data" is easier to follow. I think it should be fine for
the other call sites.

By the way, why is the upgrade feature using OpenPrevEntry instead of
OpenNextEntry? And is it really used?

+   public:
+    explicit State(base::WeakPtr<InFlightBackendIO> background_queue)
+        : background_queue_(background_queue),
+          iter_(NULL) {}
+
+    virtual ~State() {
+      if (background_queue_)
+        background_queue_->EndEnumeration(*iter());
+    }
 
-void BackendImpl::EndEnumeration(void** iter) {
-  background_queue_.EndEnumeration(*iter);
-  *iter = NULL;
+    void** iter() { return &iter_; }
+
+   private:
+    base::WeakPtr<InFlightBackendIO> background_queue_;
+    void* iter_;
+  };
+  if (!*iter)
+    iter->reset(new State(GetBackgroundQueue()));
+  State* state = static_cast<State*>(iter->get());
+
+  background_queue_.OpenNextEntry(state->iter(), next_entry, callback);
+  return net::ERR_IO_PENDING;
 }
 
 void BackendImpl::GetStats(StatsItems* stats) {