From patchwork Wed Oct 23 13:52:55 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Laurent Pinchart X-Patchwork-Id: 2211 Return-Path: Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 2A8066138B for ; Wed, 23 Oct 2019 15:54:01 +0200 (CEST) Received: from pendragon.ideasonboard.com (143.121.2.93.rev.sfr.net [93.2.121.143]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id ABA6171F for ; Wed, 23 Oct 2019 15:54:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1571838840; bh=Dw2zSmuQ4ZAjdEVFMkfMIMApPUxbKHYW5Cr6RHVStv0=; h=From:To:Subject:Date:From; b=fRgTkJ2GIep85xx044Vm3rKnQZgqjyzcB8j/lidVnmfj8He86vvdK6cK6z7LihSuS KdgvD+bwU6vq07WPUo+gKXK5t/W+YnOacx1COyESFUNRthDl5SrX3Vs6m1xKuacgTg d6usKaHpW1l6yncSx4n88gwdXIdmHEwuop4vYFOs= From: Laurent Pinchart To: libcamera-devel@lists.libcamera.org Date: Wed, 23 Oct 2019 16:52:55 +0300 Message-Id: <20191023135258.32256-1-laurent.pinchart@ideasonboard.com> X-Mailer: git-send-email 2.23.0 MIME-Version: 1.0 Subject: [libcamera-devel] [PATCH 1/4] Documentation: coding-style: Document usage of C compatibility headers X-BeenThere: libcamera-devel@lists.libcamera.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 13:54:01 -0000 The C++ standard defines a set of C++ standard library headers, and for some of them, defines C compatibility headers. The former have a name of the form while the later are named . The C++ headers declare names in the std namespace, and may declare the same names in the global namespace. The C compatibility headers declare names in the global namespace, and may declare the same names in the std namespace. We want to standardise on one set of headers through libcamera, and don't want to rely on optional behaviour. We can thus either use the C++ headers with an explicit std:: namespace qualifier through the code, or the C headers without the qualifier. Both set of headers are defined by the C++ standard, and are thus valid choices. After weighting pros and cons, we have decided to use the C compatibility headers, as nobody wanted to write std::uint32_t. Document this decision. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham Reviewed-by: Niklas Söderlund --- Documentation/coding-style.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/Documentation/coding-style.rst b/Documentation/coding-style.rst index 8dd1afce1a2c..ced3155169a6 100644 --- a/Documentation/coding-style.rst +++ b/Documentation/coding-style.rst @@ -170,6 +170,18 @@ These rules match the `object ownership rules from the Chromium C++ Style Guide` long term borrowing isn't marked through language constructs, it shall be documented explicitly in details in the API. +C Compatibility Headers +~~~~~~~~~~~~~~~~~~~~~~~ + +The C++ standard defines a set of C++ standard library headers, and for some of +them, defines C compatibility headers. The former have a name of the form + while the later are named . The C++ headers declare names in the +std namespace, and may declare the same names in the global namespace. The C +compatibility headers declare names in the global namespace, and may declare +the same names in the std namespace. Usage of the C compatibility headers is +strongly preferred. Code shall not rely on the optional declaration of names in +the global or std namespace. + Documentation -------------