Add empty constructor/destructor to ResourceContext on iOS

Add empty constructor/destructor to ResourceContext on iOS

Empty ResourceContext constructors and destructors are needed on iOS since 
profile_io_data has a subclass of the interface, but iOS doesn't use all the code in resource_context_impl.cc

Also removes a bunch of #include/using cruft in resource_context_impl.cc

BUG=None

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

[stuartmorgan, 2012-11-14 11:52:44]

This is the alternative approach you requested in
http://codereview.chromium.org/11230028/

FWIW, I still disagree pretty strongly with this; adding more ifdefs and keeping
a class in a file named after a different class (which no longer exists; it's
just static util functions now) just to save a line in a gypi file doesn't make
sense to me. I don't know why having another file is a problem, given that
having each class defined in a .cc file named after the class is a project-wide
standard.

I'll also point out that this approach means that resource_context_impl.h (i.e.,
some miscellaneous utility declarations) must now remain iOS-clean forever,
meaning that if anyone ever needs to bring in a header there that's not
iOS-safe, the header will also need #ifdefs. This seems like exactly the kind of
thing you wanted to avoid in cases like WebContents, and I'm not sure why this
is different.

[jam, 2012-11-14 21:05:50]

how about in resource_context.h, you have

#if defined(OS_IOS)
  virtual ~ResourceContext() {}
#else
  ResourceContext();
  virtual ~ResourceContext();
#endif

[stuartmorgan, 2012-11-15 14:15:41]

On 2012/11/14 21:05:50, John Abd-El-Malek wrote:
> how about in resource_context.h, you have
> 
> #if defined(OS_IOS)
>   virtual ~ResourceContext() {}
> #else
>   ResourceContext();
>   virtual ~ResourceContext();
> #endif

That's fine with me; done (I had just assumed you wouldn't want to have a
platform implementation detail like this in the public header). I duplicated the
constructor in the OS_IOS block too because otherwise the chances of someone
breaking the iOS build if they add a argument to the constructor seemed
incredibly high if we rely on the hidden default constructor, so this seems more
maintainable to me, but I can take it back out if you want.

I left the cruft cleanup of resource_context_impl.cc in the CL, since it seemed
like a shame to throw that away.

[jam, 2012-11-15 16:39:09]

lgtm

I prefer taking out the constructor on IOS. in general for the interfaces in
content\public, we only add a virtual destructor and not a constructor. the
current constructor and destructor bodies for ResourceContext are actually an
anomaly, and I'd love to get rid of them, but I can't find a better way of
ensuring this cleanup happens for all embedders.

[stuartmorgan, 2012-11-16 09:14:08]

On 2012/11/15 16:39:09, John Abd-El-Malek wrote:
> I prefer taking out the constructor on IOS.

Done.

[commit-bot: I haz the power, 2012-11-16 09:14:17]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/stuartmorgan@chromium.org/11365253/13001

[commit-bot: I haz the power, 2012-11-16 11:05:20]

Retried try job too often for step(s) sync_integration_tests

[commit-bot: I haz the power, 2012-11-16 11:53:07]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/stuartmorgan@chromium.org/11365253/13001

[commit-bot: I haz the power, 2012-11-16 12:27:39]

Change committed as 168192