Mercurial > hg > CbC > CbC_llvm

comparison docs/CodingStandards.rst @ 83:60c9769439b8 LLVM3.7

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
LLVM 3.7
author Tatsuki IHA <e125716@ie.u-ryukyu.ac.jp>
date Wed, 18 Feb 2015 14:55:36 +0900
parents 54457678186b
children afa8332a0e37
comparison
equal deleted inserted replaced
78:af83660cff7b 83:60c9769439b8
81 Supported C++11 Language and Library Features 81 Supported C++11 Language and Library Features
82 --------------------------------------------- 82 ---------------------------------------------
83 83
84 While LLVM, Clang, and LLD use C++11, not all features are available in all of 84 While LLVM, Clang, and LLD use C++11, not all features are available in all of
85 the toolchains which we support. The set of features supported for use in LLVM 85 the toolchains which we support. The set of features supported for use in LLVM
86 is the intersection of those supported in MSVC 2012, GCC 4.7, and Clang 3.1. 86 is the intersection of those supported in MSVC 2013, GCC 4.7, and Clang 3.1.
87 The ultimate definition of this set is what build bots with those respective 87 The ultimate definition of this set is what build bots with those respective
88 toolchains accept. Don't argue with the build bots. However, we have some 88 toolchains accept. Don't argue with the build bots. However, we have some
89 guidance below to help you know what to expect. 89 guidance below to help you know what to expect.
90 90
91 Each toolchain provides a good reference for what it accepts: 91 Each toolchain provides a good reference for what it accepts:
121 ``{}`` are required around function-like macros inside range-based for 121 ``{}`` are required around function-like macros inside range-based for
122 loops. 122 loops.
123 123
124 * ``override`` and ``final``: N2928_, N3206_, N3272_ 124 * ``override`` and ``final``: N2928_, N3206_, N3272_
125 * Atomic operations and the C++11 memory model: N2429_ 125 * Atomic operations and the C++11 memory model: N2429_
126 * Variadic templates: N2242_
127 * Explicit conversion operators: N2437_
128 * Defaulted and deleted functions: N2346_
129
130 * But not defaulted move constructors or move assignment operators, MSVC 2013
131 cannot synthesize them.
126 132
127 .. _N2118: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html 133 .. _N2118: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html
128 .. _N2439: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm 134 .. _N2439: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm
129 .. _N1720: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html 135 .. _N1720: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html
130 .. _N1984: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf 136 .. _N1984: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf
141 .. _N2930: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2930.html 147 .. _N2930: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2930.html
142 .. _N2928: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2928.htm 148 .. _N2928: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2928.htm
143 .. _N3206: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm 149 .. _N3206: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm
144 .. _N3272: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm 150 .. _N3272: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm
145 .. _N2429: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2429.htm 151 .. _N2429: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2429.htm
152 .. _N2242: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf
153 .. _N2437: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2437.pdf
154 .. _N2346: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm
146 .. _MSVC-compatible RTTI: http://llvm.org/PR18951 155 .. _MSVC-compatible RTTI: http://llvm.org/PR18951
147 156
148 The supported features in the C++11 standard libraries are less well tracked, 157 The supported features in the C++11 standard libraries are less well tracked,
149 but also much greater. Most of the standard libraries implement most of C++11's 158 but also much greater. Most of the standard libraries implement most of C++11's
150 library. The most likely lowest common denominator is Linux support. For 159 library. The most likely lowest common denominator is Linux support. For
173 you hit a type trait which doesn't work we can then add support to LLVM's 182 you hit a type trait which doesn't work we can then add support to LLVM's
174 traits header to emulate it. 183 traits header to emulate it.
175 184
176 .. _the libstdc++ manual: 185 .. _the libstdc++ manual:
177 http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/manual/manual/status.html#status.iso.2011 186 http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/manual/manual/status.html#status.iso.2011
187
188 Other Languages
189 ---------------
190
191 Any code written in the Go programming language is not subject to the
192 formatting rules below. Instead, we adopt the formatting rules enforced by
193 the `gofmt`_ tool.
194
195 Go code should strive to be idiomatic. Two good sets of guidelines for what
196 this means are `Effective Go`_ and `Go Code Review Comments`_.
197
198 .. _gofmt:
199 https://golang.org/cmd/gofmt/
200
201 .. _Effective Go:
202 https://golang.org/doc/effective_go.html
203
204 .. _Go Code Review Comments:
205 https://code.google.com/p/go-wiki/wiki/CodeReviewComments
178 206
179 Mechanical Source Issues 207 Mechanical Source Issues
180 ======================== 208 ========================
181 209
182 Source Code Formatting 210 Source Code Formatting
230 258
231 The next section in the file is a concise note that defines the license that the 259 The next section in the file is a concise note that defines the license that the
232 file is released under. This makes it perfectly clear what terms the source 260 file is released under. This makes it perfectly clear what terms the source
233 code can be distributed under and should not be modified in any way. 261 code can be distributed under and should not be modified in any way.
234 262
235 The main body is a ``doxygen`` comment describing the purpose of the file. It 263 The main body is a ``doxygen`` comment (identified by the ``///`` comment
264 marker instead of the usual ``//``) describing the purpose of the file. It
236 should have a ``\brief`` command that describes the file in one or two 265 should have a ``\brief`` command that describes the file in one or two
237 sentences. Any additional information should be separated by a blank line. If 266 sentences. Any additional information should be separated by a blank line. If
238 an algorithm is being implemented or something tricky is going on, a reference 267 an algorithm is being implemented or something tricky is going on, a reference
239 to the paper where it is published should be included, as well as any notes or 268 to the paper where it is published should be included, as well as any notes or
240 *gotchas* in the code to watch out for. 269 *gotchas* in the code to watch out for.
260 happens: does the method return null? Abort? Format your hard disk? 289 happens: does the method return null? Abort? Format your hard disk?
261 290
262 Comment Formatting 291 Comment Formatting
263 ^^^^^^^^^^^^^^^^^^ 292 ^^^^^^^^^^^^^^^^^^
264 293
265 In general, prefer C++ style (``//``) comments. They take less space, require 294 In general, prefer C++ style comments (``//`` for normal comments, ``///`` for
295 ``doxygen`` documentation comments). They take less space, require
266 less typing, don't have nesting problems, etc. There are a few cases when it is 296 less typing, don't have nesting problems, etc. There are a few cases when it is
267 useful to use C style (``/* */``) comments however: 297 useful to use C style (``/* */``) comments however:
268 298
269 #. When writing C code: Obviously if you are writing C code, use C style 299 #. When writing C code: Obviously if you are writing C code, use C style
270 comments. 300 comments.