mojo/ipc/core/ipc_handle.h - Issue 23629032: mojo: MessageBuilder

Side by Side Diff

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Keyboard Shortcuts

	File
u :	up to issue
j / k :	jump to file after / before current file
J / K :	jump to next file with a comment after / before current file
	Side-by-side diff
i :	toggle intra-line diffs
e :	expand all comments
c :	collapse all comments
s :	toggle showing all comments
n / p :	next / previous diff chunk or comment
N / P :	next / previous comment
<Up> / <Down> :	next / previous line

	Issue
u :	up to list of issues
j / k :	jump to patch after / before current patch
o / <Enter> :	open current patch in side-by-side view
i :	open current patch in unified diff view

	Issue List
j / k :	jump to issue after / before current issue
o / <Enter> :	open current issue

Side by Side Diff: mojo/ipc/core/ipc_handle.h

Issue 23629032: mojo: MessageBuilder (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src

Patch Set: Add support for a string field type. Created 7 years, 3 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

OLD	NEW
(Empty)
	1 // Copyright (c) 2013 The Chromium Authors. All rights reserved.

	2 // Use of this source code is governed by a BSD-style license that can be

	3 // found in the LICENSE file.

	4

	5 #ifndef MOJO_IPC_CORE_IPC_HANDLE_H_

	6 #define MOJO_IPC_CORE_IPC_HANDLE_H_

	7

	8 #include <stdint.h>

	9

	10 namespace mojo {

	11

	12 struct Handle {
	vtl 2013/09/11 17:37:16 Probably the C++ layer should build on top of a C 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).
	13 uint32_t value;

	14 };

	15

	16 } // namespace mojo

	17

	18 #endif // MOJO_IPC_CORE_IPC_HANDLE_H_

OLD	NEW