mojo: MessageBuilder

mojo/ipc/core/ipc_handle.h

Index: mojo/ipc/core/ipc_handle.h
diff --git a/mojo/ipc/core/ipc_handle.h b/mojo/ipc/core/ipc_handle.h
new file mode 100644
index 0000000000000000000000000000000000000000..cc56f7b49ee2c1253b80ca826e8e38395f2641e7
--- /dev/null
+++ b/mojo/ipc/core/ipc_handle.h
@@ -0,0 +1,18 @@
+// Copyright (c) 2013 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 MOJO_IPC_CORE_IPC_HANDLE_H_
+#define MOJO_IPC_CORE_IPC_HANDLE_H_
+
+#include <stdint.h>
+
+namespace mojo {
+
+struct Handle {

[vtl, 2013/09/11 17:37:16]

Probably the C++ layer should build on top of a C layer?

(I'm ambivalent about wrapping a single value in a struct, though it does have
good type-safety advantages.)

I guess the C API would probably use the uint32_t directly? I've been using
typedefs, e.g., |typedef uint32_t MojoHandle;|, but this isn't super-important.

More significantly, I'm thinking that handles should have
movable-but-not-copyable semantics, which could actually be modelled/enforced in
a C++ wrapper. I.e., when you pass a handle, you no longer have access to it. If
you want to keep access to that object, you need to "duplicate" the handle
explicitly and the semantics of that depend on the type of object (and may not
even be allowed).

+  uint32_t value;
+};
+
+}  // namespace mojo
+
+#endif  // MOJO_IPC_CORE_IPC_HANDLE_H_