Add an initial revision of an audio server.

services/media/audio/fwd_decls.h

+// 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 SERVICES_MEDIA_AUDIO_FWD_DECLS_H__
+#define SERVICES_MEDIA_AUDIO_FWD_DECLS_H__
+
+#include <memory>
+#include <set>
+
+namespace mojo {
+namespace media {
+namespace audio {
+
+class AudioOutput;
+class AudioOutputManager;
+class AudioServerImpl;
+class AudioTrackImpl;
+class AudioTrackToOutputLink;
+
+using AudioOutputPtr = std::shared_ptr<AudioOutput>;

[jeffbrown, 2015/11/04 23:43:34]

Are we actually taking advantage of the fact that these pointer are reference
counted or do we only need weak semantics?  If the latter, consider using
base::WeakPtr perhaps.

[johngro, 2015/11/06 02:20:26]

I'm not sure I completely understand your question...  One or more strong
references  to the Output and Track objects exist in a functioning system, as
well as (potentially) many weak ones.  Whether or not this is implemented using
a reference count or faerie dust seems like an implementation details to me.

The strongest argument I have received from James R. about using base:: pointer
classes is that they are instrusive and save allocation overhead (an argument
which I find near and dear to my heart).  However, whatever form the bookkeeping
takes (reference count, faeries, whatever), in order to have weak semtantics, it
cannot be part of the referenced object itself (otherwise, how would the object
go away, but still allow the weak references to exist).

Assuming that this is correct, I am also trying to abide by the directive "to
use std:: c++11 wherever I can and to use base:: only when there is not
equivalent functionality in c++11 std::".

So: Help me to understand what base::WeakPtr does which std::weak_ptr does not. 
Right now, using std:: seems to give me...

1) standardized shared/weak interface semantics.
2) interoperability with other components of the std:: library (see
std::owner_less being used as my sorting predicate for std:: container classes
below)
3) No more overhead (to my knowledge) than another implementation would require
(note my assertion that some sort of out-of-object bookkeeping seems like a
requirement)

+using AudioOutputSet = std::set<AudioOutputPtr,
+                                std::owner_less<AudioOutputPtr>>;
+using AudioOutputWeakPtr = std::weak_ptr<AudioOutput>;
+using AudioOutputWeakSet = std::set<AudioOutputWeakPtr,
+                                    std::owner_less<AudioOutputWeakPtr>>;
+
+using AudioTrackImplPtr = std::shared_ptr<AudioTrackImpl>;
+using AudioTrackImplSet = std::set<AudioTrackImplPtr,
+                                  std::owner_less<AudioTrackImplPtr>>;
+using AudioTrackImplWeakPtr = std::weak_ptr<AudioTrackImpl>;
+using AudioTrackImplWeakSet = std::set<AudioTrackImplWeakPtr,
+                                      std::owner_less<AudioTrackImplWeakPtr>>;
+
+using AudioTrackToOutputLinkPtr = std::shared_ptr<AudioTrackToOutputLink>;
+using AudioTrackToOutputLinkSet =
+  std::set<AudioTrackToOutputLinkPtr,
+           std::owner_less<AudioTrackToOutputLinkPtr>>;
+
+}  // namespace audio
+}  // namespace media
+}  // namespace mojo
+
+#endif  // SERVICES_MEDIA_AUDIO_FWD_DECLS_H__