diff options
| author | Cedric Venet <cedric.venet@laposte.net> | 2009-02-14 20:20:19 +0000 |
|---|---|---|
| committer | Cedric Venet <cedric.venet@laposte.net> | 2009-02-14 20:20:19 +0000 |
| commit | 3d658640abc128dcc84a5a5201456395c86c4fa6 (patch) | |
| tree | d46663850c78e313eb0968ad3d327e8b18090280 /www/comparison.html | |
| parent | f3710babc1ba40779c0fc64e6657cfc84dee7545 (diff) | |
Add svn:eol-style=native to some files
Correct two files with inconsistent lines endings.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64564 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'www/comparison.html')
| -rw-r--r-- | www/comparison.html | 390 |
1 files changed, 195 insertions, 195 deletions
diff --git a/www/comparison.html b/www/comparison.html index e873f73b61..fa853fb084 100644 --- a/www/comparison.html +++ b/www/comparison.html @@ -1,195 +1,195 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
-<!-- Material used from: HTML 4.01 specs: http://www.w3.org/TR/html401/ -->
-<html>
-<head>
- <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
- <title>Comparing clang to other open source compilers</title>
- <link type="text/css" rel="stylesheet" href="menu.css" />
- <link type="text/css" rel="stylesheet" href="content.css" />
-</head>
-<body>
- <!--#include virtual="menu.html.incl"-->
- <div id="content">
- <h1>Clang vs Other Open Source Compilers</h1>
-
- <p>Building an entirely new compiler front-end is a big task, and it isn't
- always clear to people why we decided to do this. Here we compare clang
- and its goals to other open source compiler front-ends that are
- available. We restrict the discussion to very specific objective points
- to avoid controversy where possible. Also, software is infinitely
- mutable, so we don't talk about little details that can be fixed with
- a reasonable amount of effort: we'll talk about issues that are
- difficult to fix for architectural or political reasons.</p>
-
- <p>The goal of this list is to describe how differences in goals lead to
- different strengths and weaknesses, not to make some compiler look bad.
- This will hopefully help you to evaluate whether using clang is a good
- idea for your personal goals. Because we don't know specifically what
- <em>you</em> want to do, we describe the features of these compilers in
- terms of <em>our</em> goals: if you are only interested in static
- analysis, you may not care that something lacks codegen support, for
- example.</p>
-
- <p>Please email cfe-dev if you think we should add another compiler to this
- list or if you think some characterization is unfair here.</p>
-
- <ul>
- <li><a href="#gcc">Clang vs GCC</a> (GNU Compiler Collection)</li>
- <li><a href="#elsa">Clang vs Elsa</a> (Elkhound-based C++ Parser)</li>
- <li><a href="#pcc">Clang vs PCC</a> (Portable C Compiler)</li>
- </ul>
-
-
- <!--=====================================================================-->
- <h2><a name="gcc">Clang vs GCC (GNU Compiler Collection)</a></h2>
- <!--=====================================================================-->
-
- <p>Pro's of GCC vs clang:</p>
-
- <ul>
- <li>GCC supports languages that clang does not aim to, such as Java, Ada,
- FORTRAN, etc.</li>
- <li>GCC front-ends are very mature and already support C/C++/ObjC and all
- the variants we are interested in. <a href="cxx_status.html">clang's
- support for C++</a> in particular is nowhere near what GCC supports.</li>
- <li>GCC supports more targets than LLVM.</li>
- <li>GCC is popular and widely adopted.</li>
- <li>GCC does not require a C++ compiler to build it.</li>
- </ul>
-
- <p>Pro's of clang vs GCC:</p>
-
- <ul>
- <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 has a basic
- understanding of how a compiler works. GCC has a very old codebase
- which presents a steep learning curve to new developers.</li>
- <li>Clang is designed as an API from its inception, allowing it to be reused
- by source analysis tools, refactoring, IDEs (etc) as well as for code
- generation. GCC is built as a monolithic static compiler, which makes
- it extremely difficult to use as an API and integrate into other tools.
- Further, its historic design and <a
- href="http://gcc.gnu.org/ml/gcc/2007-11/msg00460.html">current</a>
- <a href="http://gcc.gnu.org/ml/gcc/2004-12/msg00888.html">policy</a>
- makes it difficult to decouple the front-end from the rest of the
- compiler. </li>
- <li>Various GCC design decisions make it very difficult to reuse: its build
- system is difficult to modify, you can't link multiple targets into one
- binary, you can't link multiple front-ends into one binary, it uses a
- custom garbage collector, uses global variables extensively, is not
- reentrant or multi-threadable, etc. Clang has none of these problems.
- </li>
- <li>For every token, clang tracks information about where it was written and
- where it was ultimately expanded into if it was involved in a macro.
- GCC does not track information about macro instantiations when parsing
- source code. This makes it very difficult for source rewriting tools
- (e.g. for refactoring) to work in the presence of (even simple)
- macros.</li>
- <li>Clang does not implicitly simplify code as it parses it like GCC does.
- Doing so causes many problems for source analysis tools: as one simple
- example, if you write "x-x" in your source code, the GCC AST will
- contain "0", with no mention of 'x'. This is extremely bad for a
- refactoring tool that wants to rename 'x'.</li>
- <li>Clang can serialize its AST out to disk and read it back into another
- program, which is useful for whole program analysis. GCC does not have
- this. GCC's PCH mechanism (which is just a dump of the compiler
- memory image) is related, but is architecturally only
- able to read the dump back into the exact same executable as the one
- that produced it (it is not a structured format).</li>
- <li>Clang is <a href="features.html#performance">much faster and uses far
- less memory</a> than GCC.</li>
- <li>Clang aims to provide extremely clear and concise diagnostics (error and
- warning messages), and includes support for <a
- href="features.html#expressivediags">expressive diagnostics</a>. GCC's
- warnings are acceptable, but are often confusing and it does not support
- expressive diagnostics. Clang also preserves typedefs in diagnostics
- consistently.</li>
- <li>GCC is licensed under the GPL license. clang uses a BSD license, which
- allows it to be used by projects that do not themselves want to be
- GPL.</li>
- <li>Clang inherits a number of features from its use of LLVM as a backend,
- including support for a bytecode representation for intermediate code,
- pluggable optimizers, link-time optimization support, Just-In-Time
- compilation, ability to link in multiple code generators, etc.</li>
- </ul>
-
- <!--=====================================================================-->
- <h2><a name="elsa">Clang vs Elsa (Elkhound-based C++ Parser)</a></h2>
- <!--=====================================================================-->
-
- <p>Pro's of Elsa vs clang:</p>
-
- <ul>
- <li>Elsa's support for C++ is far beyond what clang provides. If you need
- C++ support in the next year, Elsa is a great way to get it. That said,
- Elsa is missing important support for templates and other pieces: for
- example, it is not capable of compiling the GCC STL headers from any
- version newer than GCC 3.4.</li>
- <li>Elsa's parser and AST is designed to be easily extensible by adding
- grammar rules. Clang has a very simple and easily hackable parser,
- but requires you to write C++ code to do it.</li>
- </ul>
-
- <p>Pro's of clang vs Elsa:</p>
-
- <ul>
- <li>The Elsa community is extremely small and major development work seems
- to have ceased in 2005, though it continues to be used by other small
- projects
- (e.g. Oink). Clang has a vibrant community including developers that
- are paid to work on it full time. In practice this means that you can
- file bugs against Clang and they will often be fixed for you. If you
- use Elsa, you are (mostly) on your own for bug fixes and feature
- enhancements.</li>
- <li>Elsa is not built as a stack of reusable libraries like clang is. It is
- very difficult to use part of Elsa without the whole front-end. For
- example, you cannot use Elsa to parse C/ObjC code without building an
- AST. You can do this in Clang and it is much faster than building an
- AST.</li>
- <li>Elsa does not have an integrated preprocessor, which makes it extremely
- difficult to accurately map from a source location in the AST back to
- its original position before preprocessing. Like GCC, it does not keep
- track of macro expansions.</li>
- <li>Elsa is even slower and uses more memory than GCC, which itself requires
- far more space and time than clang.</li>
- <li>Elsa only does partial semantic analysis. It is intended to work on
- code that is already validated by GCC, so it does not do many semantic
- checks required by the languages it implements.</li>
- <li>Elsa does not support Objective-C.</li>
- <li>Elsa does not support native code generation.</li>
- </ul>
-
- <p>Note that there is a fork of Elsa known as "Pork". It addresses some of
- these shortcomings by loosely integrating a preprocessor. This allows it
- to map from a source location in the AST to the original position before
- preprocessing, providing it better support for static analysis and
- refactoring. Note that Pork is in stasis now too.</p>
-
-
- <!--=====================================================================-->
- <h2><a name="pcc">Clang vs PCC (Portable C Compiler)</a></h2>
- <!--=====================================================================-->
-
- <p>Pro's of PCC vs clang:</p>
-
- <ul>
- <li>The PCC source base is very small and builds quickly with just a C
- compiler.</li>
- </ul>
-
- <p>Pro's of clang vs PCC:</p>
-
- <ul>
- <li>PCC dates from the 1970's and has been dormant for most of that time.
- The clang + llvm communities are very active.</li>
- <li>PCC doesn't support C99, Objective-C, and doesn't aim to support
- C++.</li>
- <li>PCC's code generation is very limited compared to LLVM. It produces very
- inefficient code and does not support many important targets.</li>
- <li>Like Elsa, PCC's does not have an integrated preprocessor, making it
- extremely difficult to use it for source analysis tools.</li>
- </div>
-</body>
-</html>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" + "http://www.w3.org/TR/html4/strict.dtd"> +<!-- Material used from: HTML 4.01 specs: http://www.w3.org/TR/html401/ --> +<html> +<head> + <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> + <title>Comparing clang to other open source compilers</title> + <link type="text/css" rel="stylesheet" href="menu.css" /> + <link type="text/css" rel="stylesheet" href="content.css" /> +</head> +<body> + <!--#include virtual="menu.html.incl"--> + <div id="content"> + <h1>Clang vs Other Open Source Compilers</h1> + + <p>Building an entirely new compiler front-end is a big task, and it isn't + always clear to people why we decided to do this. Here we compare clang + and its goals to other open source compiler front-ends that are + available. We restrict the discussion to very specific objective points + to avoid controversy where possible. Also, software is infinitely + mutable, so we don't talk about little details that can be fixed with + a reasonable amount of effort: we'll talk about issues that are + difficult to fix for architectural or political reasons.</p> + + <p>The goal of this list is to describe how differences in goals lead to + different strengths and weaknesses, not to make some compiler look bad. + This will hopefully help you to evaluate whether using clang is a good + idea for your personal goals. Because we don't know specifically what + <em>you</em> want to do, we describe the features of these compilers in + terms of <em>our</em> goals: if you are only interested in static + analysis, you may not care that something lacks codegen support, for + example.</p> + + <p>Please email cfe-dev if you think we should add another compiler to this + list or if you think some characterization is unfair here.</p> + + <ul> + <li><a href="#gcc">Clang vs GCC</a> (GNU Compiler Collection)</li> + <li><a href="#elsa">Clang vs Elsa</a> (Elkhound-based C++ Parser)</li> + <li><a href="#pcc">Clang vs PCC</a> (Portable C Compiler)</li> + </ul> + + + <!--=====================================================================--> + <h2><a name="gcc">Clang vs GCC (GNU Compiler Collection)</a></h2> + <!--=====================================================================--> + + <p>Pro's of GCC vs clang:</p> + + <ul> + <li>GCC supports languages that clang does not aim to, such as Java, Ada, + FORTRAN, etc.</li> + <li>GCC front-ends are very mature and already support C/C++/ObjC and all + the variants we are interested in. <a href="cxx_status.html">clang's + support for C++</a> in particular is nowhere near what GCC supports.</li> + <li>GCC supports more targets than LLVM.</li> + <li>GCC is popular and widely adopted.</li> + <li>GCC does not require a C++ compiler to build it.</li> + </ul> + + <p>Pro's of clang vs GCC:</p> + + <ul> + <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 has a basic + understanding of how a compiler works. GCC has a very old codebase + which presents a steep learning curve to new developers.</li> + <li>Clang is designed as an API from its inception, allowing it to be reused + by source analysis tools, refactoring, IDEs (etc) as well as for code + generation. GCC is built as a monolithic static compiler, which makes + it extremely difficult to use as an API and integrate into other tools. + Further, its historic design and <a + href="http://gcc.gnu.org/ml/gcc/2007-11/msg00460.html">current</a> + <a href="http://gcc.gnu.org/ml/gcc/2004-12/msg00888.html">policy</a> + makes it difficult to decouple the front-end from the rest of the + compiler. </li> + <li>Various GCC design decisions make it very difficult to reuse: its build + system is difficult to modify, you can't link multiple targets into one + binary, you can't link multiple front-ends into one binary, it uses a + custom garbage collector, uses global variables extensively, is not + reentrant or multi-threadable, etc. Clang has none of these problems. + </li> + <li>For every token, clang tracks information about where it was written and + where it was ultimately expanded into if it was involved in a macro. + GCC does not track information about macro instantiations when parsing + source code. This makes it very difficult for source rewriting tools + (e.g. for refactoring) to work in the presence of (even simple) + macros.</li> + <li>Clang does not implicitly simplify code as it parses it like GCC does. + Doing so causes many problems for source analysis tools: as one simple + example, if you write "x-x" in your source code, the GCC AST will + contain "0", with no mention of 'x'. This is extremely bad for a + refactoring tool that wants to rename 'x'.</li> + <li>Clang can serialize its AST out to disk and read it back into another + program, which is useful for whole program analysis. GCC does not have + this. GCC's PCH mechanism (which is just a dump of the compiler + memory image) is related, but is architecturally only + able to read the dump back into the exact same executable as the one + that produced it (it is not a structured format).</li> + <li>Clang is <a href="features.html#performance">much faster and uses far + less memory</a> than GCC.</li> + <li>Clang aims to provide extremely clear and concise diagnostics (error and + warning messages), and includes support for <a + href="features.html#expressivediags">expressive diagnostics</a>. GCC's + warnings are acceptable, but are often confusing and it does not support + expressive diagnostics. Clang also preserves typedefs in diagnostics + consistently.</li> + <li>GCC is licensed under the GPL license. clang uses a BSD license, which + allows it to be used by projects that do not themselves want to be + GPL.</li> + <li>Clang inherits a number of features from its use of LLVM as a backend, + including support for a bytecode representation for intermediate code, + pluggable optimizers, link-time optimization support, Just-In-Time + compilation, ability to link in multiple code generators, etc.</li> + </ul> + + <!--=====================================================================--> + <h2><a name="elsa">Clang vs Elsa (Elkhound-based C++ Parser)</a></h2> + <!--=====================================================================--> + + <p>Pro's of Elsa vs clang:</p> + + <ul> + <li>Elsa's support for C++ is far beyond what clang provides. If you need + C++ support in the next year, Elsa is a great way to get it. That said, + Elsa is missing important support for templates and other pieces: for + example, it is not capable of compiling the GCC STL headers from any + version newer than GCC 3.4.</li> + <li>Elsa's parser and AST is designed to be easily extensible by adding + grammar rules. Clang has a very simple and easily hackable parser, + but requires you to write C++ code to do it.</li> + </ul> + + <p>Pro's of clang vs Elsa:</p> + + <ul> + <li>The Elsa community is extremely small and major development work seems + to have ceased in 2005, though it continues to be used by other small + projects + (e.g. Oink). Clang has a vibrant community including developers that + are paid to work on it full time. In practice this means that you can + file bugs against Clang and they will often be fixed for you. If you + use Elsa, you are (mostly) on your own for bug fixes and feature + enhancements.</li> + <li>Elsa is not built as a stack of reusable libraries like clang is. It is + very difficult to use part of Elsa without the whole front-end. For + example, you cannot use Elsa to parse C/ObjC code without building an + AST. You can do this in Clang and it is much faster than building an + AST.</li> + <li>Elsa does not have an integrated preprocessor, which makes it extremely + difficult to accurately map from a source location in the AST back to + its original position before preprocessing. Like GCC, it does not keep + track of macro expansions.</li> + <li>Elsa is even slower and uses more memory than GCC, which itself requires + far more space and time than clang.</li> + <li>Elsa only does partial semantic analysis. It is intended to work on + code that is already validated by GCC, so it does not do many semantic + checks required by the languages it implements.</li> + <li>Elsa does not support Objective-C.</li> + <li>Elsa does not support native code generation.</li> + </ul> + + <p>Note that there is a fork of Elsa known as "Pork". It addresses some of + these shortcomings by loosely integrating a preprocessor. This allows it + to map from a source location in the AST to the original position before + preprocessing, providing it better support for static analysis and + refactoring. Note that Pork is in stasis now too.</p> + + + <!--=====================================================================--> + <h2><a name="pcc">Clang vs PCC (Portable C Compiler)</a></h2> + <!--=====================================================================--> + + <p>Pro's of PCC vs clang:</p> + + <ul> + <li>The PCC source base is very small and builds quickly with just a C + compiler.</li> + </ul> + + <p>Pro's of clang vs PCC:</p> + + <ul> + <li>PCC dates from the 1970's and has been dormant for most of that time. + The clang + llvm communities are very active.</li> + <li>PCC doesn't support C99, Objective-C, and doesn't aim to support + C++.</li> + <li>PCC's code generation is very limited compared to LLVM. It produces very + inefficient code and does not support many important targets.</li> + <li>Like Elsa, PCC's does not have an integrated preprocessor, making it + extremely difficult to use it for source analysis tools.</li> + </div> +</body> +</html> |