ladybird/Userland/Libraries/LibIPC/Forward.h

/*
 * Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
 *
 * SPDX-License-Identifier: BSD-2-Clause
 */

#pragma once

namespace IPC {

class Decoder;
class Dictionary;
class Encoder;
class Message;
class File;
class Stub;

template<typename T>
bool encode(Encoder&, T const&);

template<typename T>
ErrorOr<void> decode(Decoder&, T&);

}
LibIPC: Add forwarding header for LibIPC 2020-03-29 18:57:53 +02:00			`/*`
			`* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>`
			`*`
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt * 2021-04-22 01:24:48 -07:00			`* SPDX-License-Identifier: BSD-2-Clause`
LibIPC: Add forwarding header for LibIPC 2020-03-29 18:57:53 +02:00			`*/`

			`#pragma once`

			`namespace IPC {`

			`class Decoder;`
LibIPC: Add a simple IPC::Dictionary type (String key -> String value) 2020-05-03 22:15:27 +02:00			`class Dictionary;`
LibIPC: Add forwarding header for LibIPC 2020-03-29 18:57:53 +02:00			`class Encoder;`
			`class Message;`
LibIPC: Support sending file descriptors :^) It is now possible to use the special IPC::File type in message arguments. In C++, the type is nothing more than a wrapper over a file descriptor. But when serializing/deserializing IPC::File arguments, LibIPC will use the sendfd/recvfd kernel APIs instead of sending the integer inline. This makes it quite convenient to pass files over IPC, and will allow us to significantly tighten sandboxes in the future :^) Closes https://github.com/SerenityOS/serenity/issues/3643 2020-11-21 21:59:12 +03:00			`class File;`
LibIPC: Add IPC::Stub to forwarding header 2021-10-23 21:40:07 +02:00			`class Stub;`
LibIPC: Add forwarding header for LibIPC 2020-03-29 18:57:53 +02:00
LibIPC: Forward declare the encode() and decode() template functions For the most part, we try to provide specializations of these functions in various headers by including "LibIPC/Forward.h" and then declaring encode() and decode() specializations. However, without any forward declaration of these types, we aren't actually specializing anything. Rather, we are just declaring overloads, which trips up the base encode and decode template definitions. The result is that LibIPC is very sensitive to include order, and the DependentFalse<> static assertion would fail if the includes weren't perfectly ordered. By properly forward declaring these templates, we can make sure the specializations receive precedence over the base templates. 2022-11-15 10:01:23 -05:00			`template<typename T>`
			`bool encode(Encoder&, T const&);`

			`template<typename T>`
			`ErrorOr<void> decode(Decoder&, T&);`

LibIPC: Add forwarding header for LibIPC 2020-03-29 18:57:53 +02:00			`}`