X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FCodingStandards.rst;h=3cfa1f66ab4ef09b42dfaacbc0decaf04a11bd04;hb=895fcbe7a1c8b59fa83d18a4d62e28f434c97a19;hp=f9685d69ad5d7532bad189b78b4228cc825dcec0;hpb=fc9031cdffa3063ef747bd3a98833f164d07fc4a;p=oota-llvm.git diff --git a/docs/CodingStandards.rst b/docs/CodingStandards.rst index f9685d69ad5..3cfa1f66ab4 100644 --- a/docs/CodingStandards.rst +++ b/docs/CodingStandards.rst @@ -76,10 +76,7 @@ implemented in the LLVM namespace following the expected standard interface. There are some exceptions such as the standard I/O streams library which are avoided. Also, there is much more detailed information on these subjects in the -`Programmer's Manual`_. - -.. _Programmer's Manual: - http://llvm.org/docs/ProgrammersManual.html +:doc:`ProgrammersManual`. Supported C++11 Language and Library Features --------------------------------------------- @@ -110,7 +107,7 @@ unlikely to be supported by our host compilers. * Trailing return types: N2541_ * Lambdas: N2927_ - * But *not* ``std::function``, until Clang implements `MSVC-compatible RTTI`_. + * But *not* lambdas with default arguments. * ``decltype``: N2343_ * Nested closing right angle brackets: N1757_ @@ -119,6 +116,11 @@ unlikely to be supported by our host compilers. * Strongly-typed and forward declarable enums: N2347_, N2764_ * Local and unnamed types as template arguments: N2657_ * Range-based for-loop: N2930_ + + * But ``{}`` are required around inner ``do {} while()`` loops. As a result, + ``{}`` are required around function-like macros inside range-based for + loops. + * ``override`` and ``final``: N2928_, N3206_, N3272_ * Atomic operations and the C++11 memory model: N2429_ @@ -605,7 +607,7 @@ is never used for a class. Because of this, we turn them off globally in the code. That said, LLVM does make extensive use of a hand-rolled form of RTTI that use -templates like `isa<>, cast<>, and dyn_cast<> `_. +templates like :ref:`isa\<>, cast\<>, and dyn_cast\<> `. This form of RTTI is opt-in and can be :doc:`added to any class `. It is also substantially more efficient than ``dynamic_cast<>``. @@ -746,23 +748,21 @@ The convenience of ``auto`` makes it easy to forget that its default behavior is a copy. Particularly in range-based ``for`` loops, careless copies are expensive. -As a rule of thumb, use ``const auto &`` unless you need to mutate or copy the -result, and use ``const auto *`` when copying pointers. +As a rule of thumb, use ``auto &`` unless you need to copy the result, and use +``auto *`` when copying pointers. .. code-block:: c++ - // Typically there's no reason to mutate or modify Val. + // Typically there's no reason to copy. for (const auto &Val : Container) { observe(Val); } - - // Remove the const if you need to modify Val. for (auto &Val : Container) { Val.change(); } // Remove the reference if you really want a new copy. for (auto Val : Container) { Val.change(); saveSomewhere(Val); } // Copy pointers, but make it clear that they're pointers. - for (const auto *Val : Container) { observe(*Val); } - for (auto *Val : Container) { Val->change(); } + for (const auto *Ptr : Container) { observe(*Ptr); } + for (auto *Ptr : Container) { Ptr->change(); } Style Issues ============ @@ -1283,9 +1283,9 @@ method will never be implemented. This enables other checks like ``-Wunused-private-field`` to run correctly on classes that contain these methods. -To maintain compatibility with C++03, ``LLVM_DELETED_FUNCTION`` should be used -which will expand to ``= delete`` if the compiler supports it. These methods -should still be declared private. Example of the uncopyable pattern: +For compatibility with MSVC, ``LLVM_DELETED_FUNCTION`` should be used which +will expand to ``= delete`` on compilers that support it. These methods should +still be declared private. Example of the uncopyable pattern: .. code-block:: c++