parent
aa085d36e2
commit
b6a8cfea24
|
|
@ -60,7 +60,8 @@
|
|||
<p>Pro's of clang vs GCC:</p>
|
||||
|
||||
<ul>
|
||||
<li>The Clang ASTs and design are intended to be easily understandable to
|
||||
<li>The Clang ASTs and design are intended to be <a
|
||||
href="features.html#simplecode">easily understandable</a> by
|
||||
anyone who is familiar with the languages involved and who have a basic
|
||||
understanding of how a compiler works. GCC has a very old codebase
|
||||
which presents a steep learning curve to new developers.</li>
|
||||
|
|
|
|||
|
|
@ -27,16 +27,17 @@ These features are:
|
|||
<ul>
|
||||
<li><a href="#performance">High Performance and Low Memory Use</a></li>
|
||||
<li><a href="#expressivediags">Expressive Diagnostics</a></a></li>
|
||||
<li><a href="#gcccompat">GCC compatibility</a></li>
|
||||
</ul>
|
||||
|
||||
<p>Driving Goals and Internal Design:</p>
|
||||
<ul>
|
||||
<li><a href="#real">A real-world, production quality compiler</a></li>
|
||||
<li><a href="#simplecode">A simple and hackable code base</a></li>
|
||||
<li><a href="#unifiedparser">A single unified parser for C, Objective C, C++,
|
||||
and Objective C++</a></li>
|
||||
<li><a href="#conformance">Conformance with C/C++/ObjC and their
|
||||
variants</a></li>
|
||||
<li><a href="#gcccompat">GCC compatibility</a></li>
|
||||
</ul>
|
||||
|
||||
<!--=======================================================================-->
|
||||
|
|
@ -147,6 +148,26 @@ std::char_traits<char>, std::allocator<char> ></tt>"!), but it is
|
|||
also very useful in C code in some cases as well (e.g. "<tt>__m128"</tt> vs
|
||||
"<tt>float __attribute__((__vector_size__(16)))</tt>").</p>
|
||||
|
||||
<!--=======================================================================-->
|
||||
<h2><a name="gcccompat">GCC Compatibility</a></h2>
|
||||
<!--=======================================================================-->
|
||||
|
||||
<p>GCC is currently the defacto-standard open source compiler today, and it
|
||||
routinely compiles a huge volume of code. GCC supports a huge number of
|
||||
extensions and features (many of which are undocumented) and a lot of
|
||||
code and header files depend on these features in order to build.</p>
|
||||
|
||||
<p>While it would be nice to be able to ignore these extensions and focus on
|
||||
implementing the language standards to the letter, pragmatics force us to
|
||||
support the GCC extensions that see the most use. Many users just want their
|
||||
code to compile, they don't care to argue about whether it is pedantically C99
|
||||
or not.</p>
|
||||
|
||||
<p>As mentioned above, all
|
||||
extensions are explicitly recognized as such and marked with extension
|
||||
diagnostics, which can be mapped to warnings, errors, or just ignored.
|
||||
</p>
|
||||
|
||||
|
||||
<!--=======================================================================-->
|
||||
<h1>Driving Goals and Internal Design</h1>
|
||||
|
|
@ -170,6 +191,23 @@ being used and depended on by a broad range of people. While we are still in
|
|||
the early development stages, we strongly believe that this will become a
|
||||
reality.</p>
|
||||
|
||||
<!--=======================================================================-->
|
||||
<h2><a name="simplecode">A simple and hackable code base</a></h2>
|
||||
<!--=======================================================================-->
|
||||
|
||||
<p>Our goal is to make it possible for anyone with a basic understanding
|
||||
of compilers and working knowledge of the C/C++/ObjC languages to understand and
|
||||
extend the clang source base. A large part of this falls out of our decision to
|
||||
make the AST mirror the languages as closely as possible: you have your friendly
|
||||
if statement, for statement, parenthesis expression, structs, unions, etc, all
|
||||
represented in a simple and explicit way.</p>
|
||||
|
||||
<p>In addition to a simple design, we work to make the source base approachable
|
||||
by commenting it well, including citations of the language standards where
|
||||
appropriate, and designing the code for simplicity. Beyond that, clang offers
|
||||
a set of AST dumpers, printers, and visualizers that make it easy to put code in
|
||||
and see how it is represented.</p>
|
||||
|
||||
<!--=======================================================================-->
|
||||
<h2><a name="unifiedparser">A single unified parser for C, Objective C, C++,
|
||||
and Objective C++</a></h2>
|
||||
|
|
@ -209,22 +247,6 @@ clang in "strict" mode if you desire.</p>
|
|||
<p>We also intend to support "dialects" of these languages, such as C89, K&R
|
||||
C, C++'03, Objective-C 2, etc.</p>
|
||||
|
||||
<!--=======================================================================-->
|
||||
<h2><a name="gcccompat">GCC Compatibility</a></h2>
|
||||
<!--=======================================================================-->
|
||||
|
||||
<p>GCC is currently the defacto-standard open source compiler today, and it
|
||||
routinely compiles a huge volume of code. GCC supports a huge number of
|
||||
extensions and features (many of which are undocumented) and a lot of
|
||||
code and header files depend on these features in order to build.</p>
|
||||
|
||||
<p>While it would be nice to be able to ignore these extensions and focus on
|
||||
implementing the language standards to the letter, pragmatics force us to
|
||||
support the GCC extensions that see the most use. As mentioned above, all
|
||||
extensions are explicitly recognized as such and marked with extension
|
||||
diagnostics, which can be mapped to warnings, errors, or just ignored.
|
||||
</p>
|
||||
|
||||
|
||||
<!--=======================================================================-->
|
||||
<h2><a name="libraryarch">Library based architecture</a></h2>
|
||||
|
|
|
|||
Loading…
Reference in New Issue