diff --git a/source/compiler_stages/tc_2/goals.rst b/source/compiler_stages/tc_2/goals.rst index d0af8b5daea1341ffbdcbc28a7886b049865727a..cd86b4760f87fb6c43e7cdc555b238532d6b5453 100644 --- a/source/compiler_stages/tc_2/goals.rst +++ b/source/compiler_stages/tc_2/goals.rst @@ -7,7 +7,7 @@ Things to learn during this stage that you should remember: Strict Coding Style Following a strict coding style is an essential part of collaborative work. Understanding the rationales - behind rules is even better. See :ref:`Coding Style`. + behind rules is even better. See :ref:`Coding_Style`. Memory Leak Trackers Using tools such as Valgrind (see :ref:`Valgrind`) to track memory leaks. diff --git a/source/compiler_stages/tc_2/improvements.rst b/source/compiler_stages/tc_2/improvements.rst index ccd6404c29a1c4418232278320549e9390c8082a..6d6418effc393333f7e2bd953e74740b5249daac 100644 --- a/source/compiler_stages/tc_2/improvements.rst +++ b/source/compiler_stages/tc_2/improvements.rst @@ -19,10 +19,10 @@ Introduce an Error class class (one?), which will never trigger type checking errors. Using Generic Visitors - Andrei Alexandrescu has done a very interesting work on generic implementation of Visitors, see :ref:`Modern C++ - Design`. It does require advanced C++ skills, since it is based on type lists, which requires heavy use of - templates. + Andrei Alexandrescu has done a very interesting work on generic implementation of Visitors, + see :ref:`Modern C++ Design <Modern C++ Design>`. It does require advanced C++ skills, + since it is based on type lists, which requires heavy use of templates. Using Visitor Combinators Going even further that Andrei Alexandrescu, Nicolas Tisserand proposes an implementation of Visitor combinators, - see :ref:`Generic Visitors in C++`. + see :ref:`Generic Visitors in C++ <Generic Visitors in C++>`. diff --git a/source/compiler_stages/tc_3/code_to_write.rst b/source/compiler_stages/tc_3/code_to_write.rst index 5dfe132ee70bed6bdf08ca490e25a35e6b6bf5d7..cbebad7e8495c03d2b5d0d8c6cf5f567f8abd5f1 100644 --- a/source/compiler_stages/tc_3/code_to_write.rst +++ b/source/compiler_stages/tc_3/code_to_write.rst @@ -5,7 +5,7 @@ TC-3 Code to Write misc::scoped_map<Key, Data> Complete the class template :code:`misc::scoped_map` in :code:`lib/misc/scoped-map.hh` and - :code:`lib/misc/scoped-map.hxx`. See :ref:`lib/misc`, See :ref:`scoped_map`, for more details. + :code:`lib/misc/scoped-map.hxx`. See :ref:`lib/misc`, see :ref:`scoped_map <scoped_map>` for more details. Equip ast Augment constructs "using" an identifier, such as :code:`CallExp`, with :code:`def_`, :code:`def_get`, and diff --git a/source/compiler_stages/tc_5/faq.rst b/source/compiler_stages/tc_5/faq.rst index fecd20ea08ee2bc5f105488f4f69a4df569546c1..07c85c64c8fef89ae6fb8896afda4fb586fea44a 100644 --- a/source/compiler_stages/tc_5/faq.rst +++ b/source/compiler_stages/tc_5/faq.rst @@ -3,6 +3,8 @@ TC-5 FAQ -------- +.. _fp or fp: + ‘$fp’ or ‘fp’? Andrew Appel clearly has his HIR/LIR depend on the target in three different ways: the names of the frame pointer and result registers, and the machine word size. diff --git a/source/compiler_stages/tc_5/goals.rst b/source/compiler_stages/tc_5/goals.rst index 41069ffc22f65c838f2e1e4a8b799380b1da5f5e..81a15bb005855ac4ba96bf8dd1b679e94d4aca42 100644 --- a/source/compiler_stages/tc_5/goals.rst +++ b/source/compiler_stages/tc_5/goals.rst @@ -47,7 +47,7 @@ Explicit template instantiations You must be able to explain how templates are “compiledâ€. In addition, you know how to explicitly instantiate templates, and explain what it can be used for. The implementation of :code:`temp::Identifier` (and :code:`temp::Temp` and :code:`temp::Label`) is based on these ideas. See the corresponding rule in - :ref:`File Conventions` for some explanations on this topic. + :ref:`File_Conventions` for some explanations on this topic. Covariant return C++ supports covariance of the method return type. This feature is crucial to implement methods such diff --git a/source/compiler_stages/tc_5/primitive_samples.rst b/source/compiler_stages/tc_5/primitive_samples.rst index 312984ab8e6d13f5d03fd94355baa845442b2266..a805d720d85a287fda7f21d35173c7edce7f03ef 100644 --- a/source/compiler_stages/tc_5/primitive_samples.rst +++ b/source/compiler_stages/tc_5/primitive_samples.rst @@ -9,6 +9,8 @@ This example is probably the simplest Tiger program. 0 +.. _0.tig: + **File 4.53**: 0.tig .. code:: diff --git a/source/compiler_stages/tc_8/faq.rst b/source/compiler_stages/tc_8/faq.rst index f95fe0d318c4a7df8c935734ae106285d9aa016b..932b19a4c583a3718c2e1e28de472beb6db65763 100644 --- a/source/compiler_stages/tc_8/faq.rst +++ b/source/compiler_stages/tc_8/faq.rst @@ -4,7 +4,7 @@ TC-8 FAQ -------- Why do we have a :code:`TempMap`, and not Appel? - :ref:`$fp or fp`, for all the details. Pay special attention to + :ref:`$fp or fp <fp or fp>`, in :ref:`TC-5 FAQ`, for all the details. Pay special attention to converting the temporaries where needed: - the flow graph is independent of the temporaries diff --git a/source/compiler_stages/tc_9/samples.rst b/source/compiler_stages/tc_9/samples.rst index b64f128e273cb8b1d9e87cc7c765cd2a68f2e0de..6f6d0eec7808cc2acee906464526afcbc143111c 100644 --- a/source/compiler_stages/tc_9/samples.rst +++ b/source/compiler_stages/tc_9/samples.rst @@ -13,18 +13,22 @@ short: we use :code:`-sI` instead of :code:`-S` to save place. Allocating registers in the main function, when there is no register pressure is easy, as, in particular, there are no spills. A direct consequence is that many :code:`move` are now useless, and have -disappeared. For instance (:ref:`seven.tig`, :ref:`seven.s`): +disappeared. For instance (:ref:`seven.tig <seven.tig>`, :ref:`seven.s <seven.s>`): .. code:: 1 + 2 * 3 +.. _seven.tig: + **File 4.86**: seven.tig .. command-output:: tc -sI seven.tig :shell: :cwd: . +.. _seven.s: + **Example 4.126**: tc -sI seven.tig .. command-output:: tc -S seven.tig > seven.s diff --git a/source/compiler_stages/tc_e/code_to_write.rst b/source/compiler_stages/tc_e/code_to_write.rst index 5937423c2a3bf8b6088932613490a8f4c7761c4f..c42b11784c21f456cf14b406a9435ec042d8dbef 100644 --- a/source/compiler_stages/tc_e/code_to_write.rst +++ b/source/compiler_stages/tc_e/code_to_write.rst @@ -17,4 +17,5 @@ escapes::EscapesVisitor :code:`src/escapes/escapes-visitor.cc`. Introduce ast::Escapable - Ensure :code:`ast::VarDec` inherits from :code:`ast::Escapable`. See :ref:`Escapable`. + Ensure :code:`ast::VarDec` inherits from :code:`ast::Escapable`. + See :ref:`Escapable <Escapable>`. diff --git a/source/instructions/coding_style/documentation_style.rst b/source/instructions/coding_style/documentation_style.rst index a791e9eb91b713a581460e2347ba2dd07ed1e431..54865961fa8f688f9fdbac2fbea2932ff9b46766 100644 --- a/source/instructions/coding_style/documentation_style.rst +++ b/source/instructions/coding_style/documentation_style.rst @@ -24,7 +24,7 @@ Rule: Write correct English Rule: Be concise For documentation as for any other kind of writing, the shorter, the - better: hunt useless words. :ref:`The Elements of Style`, for an + better: hunt useless words. See :ref:`The Elements of Style <The Elements of Style>`, for an excellent set of writing guidelines. Here are a few samples of things to avoid: @@ -100,7 +100,7 @@ Rule: Use :file:`rebox.el` to mark up paragraphs Often one wants to leave a clear markup to separate different matters. For declarations, this is typically done using the Doxygen :code:`\name ... \{ ... \}` sequence; for implementation files use :file:`rebox.el` - (:ref:`rebox.el`). + (:ref:`rebox.el <rebox.el>`). Rule: Write Documentation in Doxygen Documentation is a genuine part of programming, just as testing. We use diff --git a/source/instructions/coding_style/matters_of_style.rst b/source/instructions/coding_style/matters_of_style.rst index b269ebebcbbe794d1f7876709e0aa9db1b109e4e..255d9871e58bfa5ddc5d0ed981addf988b0b8141 100644 --- a/source/instructions/coding_style/matters_of_style.rst +++ b/source/instructions/coding_style/matters_of_style.rst @@ -76,7 +76,8 @@ Rule: Keep superclasses on the class declaration line the same line. Leave a space at least on the right hand side of the colon. If there is not enough room to do so, leave the colon on the class declaration line (the opposite applies for constructor, see - :ref:`Put initializations below the constructor declaration`). + :ref:`Put initializations below the constructor declaration + <Put initializations below the constructor declaration>`). .. code:: c++ @@ -197,6 +198,8 @@ Rule: Leave no space between a function name and its argument(s), either formal bool operator()(int n); }; +.. _Put initializations below the constructor declaration: + Rule: Put initializations below the constructor declaration Don't put or initializations or constructor invocations on the same line as you declare the constructor. As a matter of fact, don't even leave diff --git a/source/instructions/coding_style/name_conventions.rst b/source/instructions/coding_style/name_conventions.rst index 4a1e10965b57546d326ef9ff4e04487bca34a392..3eeb44dc89f31a26e7df5726ccc7a9e3b2912d24 100644 --- a/source/instructions/coding_style/name_conventions.rst +++ b/source/instructions/coding_style/name_conventions.rst @@ -3,6 +3,8 @@ Name Conventions ---------------- +.. _Stay out of reserved names: + Rule: Stay out of reserved names The standard reserves a number of identifier classes, most notably *_\*** [17.4.3.1.2]: @@ -18,7 +20,7 @@ Rule: Stay out of reserved names Rule: Name your classes :code:`LikeThis` Class should be named in mixed case; for instance :code:`Exp`, :code:`StringExp`, :code:`TempMap`, :code:`InterferenceGraph` etc. This - applies to class templates. See :ref:`CStupidClassName`. + applies to class templates. See :ref:`CStupidClassName <CStupidClassName>`. Rule: Name public members :code:`like_this` @@ -30,8 +32,8 @@ Rule: Name private/protected members :code:`like_this_` protected members: you make it clear to the reader, you avoid gratuitous warnings about conflicts in constructors, you leave the "beautiful" name available for public members etc. We used to write - :code:`like_this`, but this goes against the standard, see :ref:`Stay out - of reserved names`. + :code:`like_this`, but this goes against the standard, see + :ref:`Stay out of reserved names <Stay out of reserved names>`. For instance, write: @@ -49,7 +51,7 @@ Rule: Name private/protected members :code:`like_this_` int first_, second_; } - See :ref:`CStupidClassName`. + See :ref:`CStupidClassName <CStupidClassName>`. Rule: Name your :code:`using` type alias :code:`foo_type` When declaring a :code:`using` type alias, name the type :code:`foo_type` diff --git a/source/instructions/coding_style/use_of_cpp_features.rst b/source/instructions/coding_style/use_of_cpp_features.rst index a27d80bb904018e8f46ca6589b8c96f7f10d6563..cd5a3467f516b734073ec7a076357dc6628df975 100644 --- a/source/instructions/coding_style/use_of_cpp_features.rst +++ b/source/instructions/coding_style/use_of_cpp_features.rst @@ -145,7 +145,7 @@ Rule: Use :code:`dynamic_cast` for type cases :code:`typeid` will probably not. More material can be found the chapter 8 of see :ref:`Thinking in C++ - Volume 2`: + Volume 2 <Thinking in C++ Volume 2>`: `Run-time type identification <http://www.smart2help.com/e-books/ticpp-2nd-ed-vol-two/#_Toc53985808>`_. diff --git a/source/instructions/coding_style/use_of_foreign_features.rst b/source/instructions/coding_style/use_of_foreign_features.rst index 72862c1f448de31fea68a345b6c8556b37d7c06b..f3116e395f34104f1d0cc7a512d9030fea4b82a3 100644 --- a/source/instructions/coding_style/use_of_foreign_features.rst +++ b/source/instructions/coding_style/use_of_foreign_features.rst @@ -20,11 +20,11 @@ tools that we don't master: You are on your own, but, hey!, that's what you're looking for, ain't it? The Loki Library - See :ref:`Modern C++ Design`, for more information about Loki. + See :ref:`Modern C++ Design <Modern C++ Design>`, for more information about Loki. The Boost Library As provided by the unstable Debian packages :code:`libboost-*`. - See :ref:`Boost.org`. + See :ref:`Boost.org <Boost.org>`. Any Other Parser or Scanner Generator If you dislike Flex and/or Bison *but you already know how to use them*, diff --git a/source/instructions/interactions.rst b/source/instructions/interactions.rst index 1604444c2eaf82257caa9cec0539e9856716f768..0acfb29f77ad92ee9bf9da426e4c1f0e1c020f6b 100644 --- a/source/instructions/interactions.rst +++ b/source/instructions/interactions.rst @@ -44,8 +44,9 @@ A complete content the compiler/tool. The following text by Simon Tatham is enlightening; its scope goes way beyond the |project| Project: `How to Report Bugs Effectively - <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>`_. See also :ref:`How - not to go about a programming assignment`, item "Be clever when using + <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>`_. See also + :ref:`How not to go about a programming assignment + <How not to go about a programming assignment>`, item "Be clever when using electronic mail". A legible content diff --git a/source/instructions/rules_of_the_game.rst b/source/instructions/rules_of_the_game.rst index a6dbc1545446a2702acb74b8be8b3cda66ed74e6..3b1b53c80762c796781529e69f3fe4de6a3b89ad 100644 --- a/source/instructions/rules_of_the_game.rst +++ b/source/instructions/rules_of_the_game.rst @@ -10,7 +10,8 @@ follow. **Rule: Thou Shalt Not Possess Thy Neighbor's Code** It is *strictly* forbidden to possess code that is not yours. You are encouraged to work with others, but don't get a copy of their code. -See :ref:`How not to go about a programming assignment`, for more hints on +See :ref:`How not to go about a programming assignment +<How not to go about a programming assignment>`, for more hints on what will *not* be accepted. diff --git a/source/instructions/submission.rst b/source/instructions/submission.rst index 4ea5f0c7fd3575e920f859b9843176898b8200dc..5a5395566c4a279932e3b5a0068784440ca4ed2c 100644 --- a/source/instructions/submission.rst +++ b/source/instructions/submission.rst @@ -5,7 +5,7 @@ Submission We use two kinds of project submissions in the project. - - For PTHL (:ref:`PTHL (TC-0)`), your *sources* must be pushed + - For PTHL (:ref:`PTHL`), your *sources* must be pushed through the :code:`master` branch to the central Git repository at submission time. Follow the instructions given by the teaching assistants. diff --git a/source/instructions/tests/tests.rst b/source/instructions/tests/tests.rst index 21c816585011c328cae1b1d9a4177c59db0aacd3..8a980b122ecb1368e479489bdffabb6faadec257 100644 --- a/source/instructions/tests/tests.rst +++ b/source/instructions/tests/tests.rst @@ -3,7 +3,7 @@ Tests ===== -As stated in :ref:`Rules of the Game`, writing a test framework and tests +As stated in :ref:`Rules_of_the_Game`, writing a test framework and tests is part of the exercise. As a starting point, we provide a tarball containing a few diff --git a/source/instructions/tests/writing_tests.rst b/source/instructions/tests/writing_tests.rst index 20772658118b06e2b1e3367e885da25731e7cbf1..aff551928980361991eb3cbe7ffd107e407b1516 100644 --- a/source/instructions/tests/writing_tests.rst +++ b/source/instructions/tests/writing_tests.rst @@ -15,5 +15,5 @@ In three occasions tests are "easy" to write: - If you are developing a component for the compiler, you can certainly feel the weak points. Immediately write a test for these. -:ref:`Testing student-made compilers`, for many hints on what tests you -need to write. +See :ref:`Testing student-made compilers <Testing student-made compilers>`, +for many hints on what tests you need to write. diff --git a/source/intro/history/tiger_2005.rst b/source/intro/history/tiger_2005.rst index 60290337185010a5c8724d337b82baec723abfe9..4dae2314d3fea15a81d9f5481c810528855aadb2 100644 --- a/source/intro/history/tiger_2005.rst +++ b/source/intro/history/tiger_2005.rst @@ -67,7 +67,7 @@ Too many memory leaks Too long to compile Too much code was in `*.hh` files. Since then the policy wrt file - contents was defined (See :ref:`File Conventions`), and in |Project| + contents was defined (See :ref:`File_Conventions`), and in |Project| 2006 was adjusted to obey these conventions. Unfortunately, although the improvement was significant, it was not measured precisely. @@ -94,8 +94,8 @@ Filling holes is not interesting No written conventions Since its inception, the |project| Compiler Project lacked this very section - (See :ref:`History`) and that dedicated to coding style (See :ref:`Coding - Style`) until the debriefing of 2005. As a result, some students or even so + (See :ref:`History`) and that dedicated to coding style (See :ref:`Coding_Style`) + until the debriefing of 2005. As a result, some students or even so co-developers of our own `tc` reproduced errors of the past, changed something for lack of understanding, slightly broke the homogeneity of the coding style etc. Do not make the same mistake: write down your policy. diff --git a/source/intro/how_to_read_this_document.rst b/source/intro/how_to_read_this_document.rst index 2ed8517c4de0551aa2859fcef2a84b1bc69e5874..ee1dad5b4036814e435e8762fe01e411ac39f0b4 100644 --- a/source/intro/how_to_read_this_document.rst +++ b/source/intro/how_to_read_this_document.rst @@ -27,7 +27,7 @@ Incremental Auxiliary This information is provided to help you: just go there when you feel the - need, :ref:`Tools`, and :ref:`Source Code`. If you want to have a better understanding + need, :ref:`Tools`, and :ref:`Source_Code`. If you want to have a better understanding of the project, if you are about to criticize something, be sure to read :ref:`History` beforehand. diff --git a/source/intro/why_the_tiger_project.rst b/source/intro/why_the_tiger_project.rst index 044bf51b8473d724b70adf41b7b0134ed2674fbc..08fcaa5f32954c75410d730e1706e5e3a7ef8765 100644 --- a/source/intro/why_the_tiger_project.rst +++ b/source/intro/why_the_tiger_project.rst @@ -51,7 +51,7 @@ Understanding Computers: understanding how it works, and therefore *how to perform a good job*. Although most students will never be asked to write a single line of assembly during their whole lives, knowing assembly is also of help. - :ref:`Bjarne Stroustrup`, for instance, says: + See :ref:`Bjarne Stroustrup <Bjarne Stroustrup>`, for instance, says: Q: What is your opinion, is knowing assembly language useful for programmers nowadays? @@ -63,8 +63,8 @@ English English is *the* language for this project, starting with this very document, written by a French person, for French students. You cannot be a good computer scientist with absolutely no fluency in English. The following quote is from - Bjarne Stroustrup, who is danish (:ref:`The Design and Evolution of C++`, - 6.5.3.2 Extended Character Sets): + Bjarne Stroustrup, who is danish (See :ref:`The Design and Evolution of C++ + <The Design and Evolution of C++>`, 6.5.3.2 Extended Character Sets): English has an important role as a common language for programmers, and I suspect that it would be unwise to abandon that without serious @@ -74,8 +74,7 @@ English *do not translate this document nor any other*. Ask support to the Yakas, or to the English team. By the past, some oral and written examinations were made in English. It may well be back some day. Some - books will help you to improve your English, see :ref:`The Elements of - Style`. + books will help you to improve your English, see :ref:`The Elements of Style <The Elements of Style>`. Compiler The project aims at the implementation of a compiler, but **this is @@ -85,10 +84,12 @@ Compiler the full list of all these items is. The |project| project is not unique in these regards, see -:ref:`Cool - The Classroom Object-Oriented Compiler`, for instance, with +:ref:`Cool - The Classroom Object-Oriented Compiler +<Cool - The Classroom Object-Oriented Compiler>`, for instance, with many strikingly similar goals, and some profound differences. See also :ref:`Making Compiler Design Relevant for Students who will (Most Likely) -Never Design a Compiler`, for an explanation of why compilation +Never Design a Compiler <Making Compiler Design Relevant for Students who will (Most Likely) +Never Design a Compiler>`, for an explanation of why compilation techniques have a broader influence than they seem. diff --git a/source/source_code/project_layout/build_aux.rst b/source/source_code/project_layout/build_aux.rst index 3ee5d062bf2ee006ad0a7f902474e02f852d3036..482838ad351a4199c4c996086029bf0a7552a5f3 100644 --- a/source/source_code/project_layout/build_aux.rst +++ b/source/source_code/project_layout/build_aux.rst @@ -20,6 +20,8 @@ The :code:`build-aux` Directory Likewise for MonoBURG. +.. _rebox.el: + **File: rebox.el(build-aux/)** This file provides two new Emacs fucntions, :code:`M-x rebox-comment` and :code:`M-x rebox-region`. diff --git a/source/source_code/project_layout/lib_misc.rst b/source/source_code/project_layout/lib_misc.rst index 9c07234321aa0c8787e3e1a7088a0bae0e6e4372..fcf14dc71a86bc6262f36a89e4201b6997c11b61 100644 --- a/source/source_code/project_layout/lib_misc.rst +++ b/source/source_code/project_layout/lib_misc.rst @@ -78,6 +78,8 @@ Convenient C++ tools. A wrapper around :code:`std::set` that introduce convenient operators (:code:`operator+` and so forth). +.. _scoped_map: + **File: scoped-map.\* (lib/misc/)** The handling of :code:`misc::scoped_map<Key, Data>`, generic scoped map, serving as a basis for symbol diff --git a/source/source_code/project_layout/src_ast.rst b/source/source_code/project_layout/src_ast.rst index c34eec6b43a6242e88ccc6079838681abc21808e..bb4de319c24f1e2e65cf4885282780ce16e9c88b 100644 --- a/source/source_code/project_layout/src_ast.rst +++ b/source/source_code/project_layout/src_ast.rst @@ -81,6 +81,8 @@ Namespace :code:`ast`, delivered for TC-2. Implementation of the abstract syntax It is convenient to be able to visit these, but it is not needed. +.. _Escapable: + **File: escapable.* (src/ast/)** This class is needed only for TC-E. diff --git a/source/tools/bibliography.rst b/source/tools/bibliography.rst index 413a220e4c04596972dee11019337897632ad373..4264ef472746267b60abd6ee3d99a64d48af61ad 100644 --- a/source/tools/bibliography.rst +++ b/source/tools/bibliography.rst @@ -9,11 +9,12 @@ read them all, except :ref:`Modern Compiler Implementation`. A suggested ordered small selection of books is: 1. :ref:`Modern Compiler Implementation` -2. :ref:`C++ Primer` -3. :ref:`Design Patterns - Elements of Reusable Object-Oriented Software` -4. :ref:`Effective Modern C++` -5. :ref:`Effective C++` -6. :ref:`Effective STL` +2. :ref:`C++ Primer <C++ Primer>` +3. :ref:`Design Patterns - Elements of Reusable Object-Oriented Software + <Design Patterns - Elements of Reusable Object-Oriented Software>` +4. :ref:`Effective Modern C++ <Effective Modern C++>` +5. :ref:`Effective C++ <Effective C++>` +6. :ref:`Effective STL <Effective STL>` The books are available at the EPITA Library: you are encouraged to borrow them there. If some of these books are missing, please suggest @@ -22,8 +23,10 @@ these books, we recommend `Le Monde en "tique" <http://www.lmet.fr>`_, a bookshop that has demonstrated several times its dedication to its job, and its kindness to EPITA students/members. +.. _Autotools Tutorial: + Web Site: Autotools Tutorial *-- Alexandre Duret-Lutz* - The `Autotools Tutorial <http://www.lrde.epita.fr/~adl/autotools.html>`_ + The `Autotools Tutorial <http://www.lrde.epita.fr/~adl/autotools.html>`__ is the best introduction to Autoconf, Automake, and Libtool, that we know. It covers also other components of the GNU Build System. You should read this before diving into the documentation. @@ -39,10 +42,12 @@ Web Site: Autotools Tutorial *-- Alexandre Duret-Lutz* - the `Goat Book <http://www.sourceware.org/autobook/>`_ covers the whole GNU Build System: Autoconf, Automake and Libtool. +.. _Bjarne Stroustrup: + Web Site: Bjarne Stroustrup .. image:: bjarne.jpg - `Bjarne Stroustrup <http://www.stroustrup.com>`_ + `Bjarne Stroustrup <http://www.stroustrup.com>`__ is the author of C++, which he describes as (`The C++ Programming Language <http://www.stroustrup.com/C++.html>`_): @@ -75,6 +80,8 @@ Web Site: Bjarne Stroustrup His list of `C++ Applications <http://www.stroustrup.com/applications.html>`_ is worth the browsing. +.. _Boost.org: + Web Site: Boost.org The `Boost.org web site <http://www.boost.org>`_ reads: @@ -95,6 +102,8 @@ Web Site: Boost.org `Boost Variant Library <http://www.boost.org/libs/variant/index.html>`_ etc. +.. _BURG - Fast Optimal Instruction Selection and Tree Parsing: + Paper: BURG: Fast Optimal Instruction Selection and Tree Parsing *-- Christopher W. Fraser, Robert R. Henry, Todd A. Proebsting* SIGPLAN Notices 24(4), 68-76. 1992. @@ -102,6 +111,8 @@ Paper: BURG: Fast Optimal Instruction Selection and Tree Parsing *-- Christopher is a description of BURG and an introduction to the concept of code generator generators. +.. _Compilers and Compiler Generators, an introduction with C++: + Book: Compilers and Compiler Generators, an introduction with C++ *-- P.D. Terry* Its site reads: @@ -115,6 +126,8 @@ Book: Compilers and Compiler Generators, an introduction with C++ *-- P.D. Terry use, its C++ is antique, and its approach to compilation is significantly different from Appel's. +.. _C++ Primer: + Book: C++ Primer *-- Stanley B. Lippman, Josée Lajoie* .. image:: c++-primer.jpg @@ -142,9 +155,13 @@ Book: C++ Primer *-- Stanley B. Lippman, Josée Lajoie* which is extremely stupid since *Essential C++* is another book from Stanley B. Lippman (but not with Josée Lajoie). +.. _Compilers - Principles, Techniques and Tools: + +.. _The Dragon Book: + Book: Compilers: Principles, Techniques and Tools *-- Alfred V. Aho, Ravi Sethi, and Jeffrey D. Ullman* _ - + Book: The Dragon Book .. image:: compilers-principles-techniques-and-tools.jpg @@ -176,6 +193,8 @@ Book: The Dragon Book Philippe Deschamp, Martin Jourdan, Bernard Lorho and Monique Lazaud: the pleasure is as good in French as it is in English. +.. _Cool - The Classroom Object-Oriented Compiler: + Web Site: Cool: The Classroom Object-Oriented Compiler `The Classroom Object-Oriented Compiler <http://theory.stanford.edu/~aiken/software/cool/cool.html>`_, from the University of California, Berkeley, @@ -184,14 +203,18 @@ Web Site: Cool: The Classroom Object-Oriented Compiler Nevertheless, if you enjoy the |Project| project, you might want to see its older siblings. +.. _CStupidClassName: + Paper: CStupidClassName *-- Dejan Jelovi* This short paper, `CStupidClassName - <http://www.jelovic.com/articles/stupid_naming.htm>`_, explains + <http://www.jelovic.com/articles/stupid_naming.htm>`__, explains why naming classes :code:`CLikeThis` is stupid, but why lexical conventions are nevertheless very useful. It turns out we follow the same scheme that is emphasized there. +.. _Design Patterns - Elements of Reusable Object-Oriented Software: + Book: Design Patterns: Elements of Reusable Object-Oriented Software *-- Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides* .. image:: design-patterns.jpg @@ -215,6 +238,8 @@ Book: Design Patterns: Elements of Reusable Object-Oriented Software *-- Erich G `Portland Pattern Repository <http://c2.com/cgi/wiki?PortlandPatternRepository>`_. +.. _Effective Modern C++: + Book: Effective Modern C++ *-- Scott Meyers* .. image:: effective-modern-c++.jpg @@ -224,13 +249,15 @@ Book: Effective Modern C++ *-- Scott Meyers* An amazingly practical book when using C++11 and C++14 (modern C++). These days, it should be the first book that every new C++ programmer should read. - It follows the same format as :ref:`Effective C++`. + It follows the same format as :ref:`Effective C++ <Effective C++>`. `Effective Modern C++ O'Reilly Page <http://shop.oreilly.com/product/0636920033707.do>`_. In this document, EMCN refers to item *n* in Effective Modern C++. +.. _Effective C++: + Book: Effective C++ *-- Scott Meyers* .. image:: effective-c++.jpg @@ -247,6 +274,8 @@ Book: Effective C++ *-- Scott Meyers* In this document, ECN refers to item *n* in Effective C++. +.. _Effective STL: + Book: Effective STL *-- Scott Meyers* .. image:: effective-stl.jpg @@ -261,6 +290,8 @@ Book: Effective STL *-- Scott Meyers* In this document, ESN refers to item *n* in Effective STL. +.. _Engineering a simple efficient code generator generator: + Paper: Engineering a simple, efficient code generator generator *-- Christopher W. Fraser, David R. Hanson, Todd A. Proebsting* ACM Letters on Programming Languages and Systems 1, 3 (Sep. 1992), 213-226. @@ -270,12 +301,14 @@ Paper: Engineering a simple, efficient code generator generator *-- Christopher compile time (BURG-like programs use dynamic programming to select the optimum tree tiling during a bottom-up walk). +.. _Generic Visitors in C++: + Technical Report: Generic Visitors in C++ *-- Nicolas Tisserand* This report is available on line from `Visitors Page <http://www.lrde.epita.fr/cgi-bin/twiki/view/Projects/Visitors>`_: `Generic Visitors in C++ - <http://www.lrde.epita.fr/cgi-bin/twiki/view/Publications/20030528-Seminar-Tisserand-Report>`_. + <http://www.lrde.epita.fr/cgi-bin/twiki/view/Publications/20030528-Seminar-Tisserand-Report>`__. Its abstract reads: The Visitor design pattern is a well-known software engineering @@ -294,9 +327,11 @@ Technical Report: Generic Visitors in C++ *-- Nicolas Tisserand* "visitable" target hierarchies, without being intrusive on their codes. - This report is in the spirit of :ref:`Modern C++ Design`, and should + This report is in the spirit of :ref:`Modern C++ Design <Modern C++ Design>`, and should probably be read afterward. +.. _Guru of the Week: + News: Guru of the Week Written by various authors, compiled by Herb Sutter @@ -310,6 +345,8 @@ News: Guru of the Week famous GotW) is freely available. In this document, GotWn refers to the item number *n*. +.. _How not to go about a programming assignment: + Article: How *not* to go about a programming assignment *-- AgustÃn Cernuda del RÃo* This paper provides excellent advice on how to succeed an assignment by showing the converse: @@ -335,6 +372,8 @@ Article: How *not* to go about a programming assignment *-- AgustÃn Cernuda del - Leave it all for the last minute - Cheat with your assignment +.. _Lex & Yacc: + Book: Lex & Yacc *-- John R. Levine, Tony Mason, Doug Brown* Published by O'Reilly & Associates; 2nd edition (October 1992); ISBN: 1-565-92000-7. @@ -348,6 +387,8 @@ Book: Lex & Yacc *-- John R. Levine, Tony Mason, Doug Brown* (more about exclusive start condition (Flex only), more about Bison only stuff, interaction with C++ etc.). +.. _Making Compiler Design Relevant for Students who will (Most Likely) Never Design a Compiler: + Article: Making Compiler Design Relevant for Students who will (Most Likely) Never Design a Compiler *-- Saumya K. Debray* This `paper about teaching compilers <https://cs.arizona.edu/~debray/Publications/teaching_compilers.pdf>`_ @@ -356,6 +397,8 @@ Article: Making Compiler Design Relevant for Students who will (Most Likely) Nev construction **projects**, and therefore it misses quite a few motivations we have for the |Project| *project*. +.. _Modern C++ Design: + Book: Modern C++ Design -- Generic Programming and Design Patterns Applied *-- Andrei Alexandrescu* .. image:: modern-c++-design.jpg @@ -363,8 +406,10 @@ Book: Modern C++ Design -- Generic Programming and Design Patterns Applied *-- A A wonderful book on very advanced C++ programming with a heavy use of templates to achieve beautiful and useful designs (including the - classical design patterns, see :ref:`Design Patterns - Elements of - Reusable Object-Oriented Software`). The code is available in the form + classical design patterns, see + :ref:`Design Patterns - Elements of Reusable Object-Oriented Software + <Design Patterns - Elements of Reusable Object-Oriented Software>`). + The code is available in the form of the `Loki Library <http://sourceforge.net/projects/loki-lib/>`_. The `Modern C++ Design Web Site <http://www.moderncppdesign.com/book/main.html>`_ includes pointers @@ -374,6 +419,8 @@ Book: Modern C++ Design -- Generic Programming and Design Patterns Applied *-- A Read this book only once you have gained good understanding of the C++ core language, and after having read the "Effective C++/STL" books. +.. _Modern Compiler Implementation in C, Java, ML: + Book: Modern Compiler Implementation in C, Java, ML *-- Andrew W. Appel* Published by Cambridge University Press; ISBN: 0-521-58390-X @@ -390,6 +437,7 @@ Book: Modern Compiler Implementation in C, Java, ML *-- Andrew W. Appel* material to the rest of the compiler, or even nothing for advanced material. This book does not suffer these flaws. +.. _Object Management Group: Web Site: Object Management Group `OMG's Home Page <http://www.omg.org/>`_, with a @@ -397,13 +445,17 @@ Web Site: Object Management Group on the `Unified Modeling Language <http://www.uml.org/>`_ (UML). +.. _Parsing Techniques -- A Practical Guide: + Book: Parsing Techniques -- A Practical Guide *-- Dick Grune and Ceriel J. Jacob* Published by the authors; ISBN: 0-13-651431-6 A remarkable review of all the parsing techniques. Because the book is out of print, its authors made it freely available: `Parsing Techniques -- A Practical Guide - <http://dickgrune.com/Books/PTAPG_1st_Edition/>`_. + <http://dickgrune.com/Books/PTAPG_1st_Edition/>`__. + +.. _Programming - Principles and Practice Using C++: Book: Programming: Principles and Practice Using C++ *-- Bjarne Stroustrup* .. image:: programming-principles-and-practice-using-c++.jpg @@ -415,6 +467,8 @@ Book: Programming: Principles and Practice Using C++ *-- Bjarne Stroustrup* Published by Addison-Wesley Professional, 2008; ISBN-13: 978-0321543721. +.. _SPOT - une bibliothèque de vérification de propriétés de logique temporelle à temps linéaire: + Report: SPOT: une bibliothèque de vérification de propriétés de logique temporelle à temps linéaire *-- Alexandre Duret-Lutz & Rachid Rebiha* This report presents SPOT, a model checking library written in C++ and Python. Parts were inspired by the |Project| project, and @@ -424,6 +478,8 @@ Report: SPOT: une bibliothèque de vérification de propriétés de logique temp Another useful source of inspiration was the use of Python and Swig to write the command line interface. +.. _Testing student-made compilers: + Paper: Testing student-made compilers *-- José de Oliveira Guimaraes* ACM SIGCSE Bulletin archive Volume 26, Issue 3 (September 1994). @@ -432,6 +488,8 @@ Paper: Testing student-made compilers *-- José de Oliveira Guimaraes* gives a classified list of test cases for a small Pascal compiler. It is a good source of inspiration for any other language. +.. _The Design and Evolution of C++: + Book: The Design and Evolution of C++ *-- Bjarne Stroustrup* .. image:: the-design-and-evolution-of-c++.jpg @@ -452,6 +510,8 @@ Book: The Design and Evolution of C++ *-- Bjarne Stroustrup* .. FIXME: Cite them, especially the HOPL III paper (they may deserve an .. entry). +.. _The Elements of Style: + Book: The Elements of Style *-- William Strunk Jr., E.B. White* .. image:: the-elements-of-style.jpg @@ -469,6 +529,8 @@ Book: The Elements of Style *-- William Strunk Jr., E.B. White* `First Edition of The Elements of Style <http://www.bartleby.com/141/>`_ on line. +.. _Thinking in C++ Volume 1: + Book: Thinking in C++ Volume 1 *-- Bruce Eckel* Published by Prentice Hall; ISBN: 0-13-979809-9 @@ -478,6 +540,8 @@ Book: Thinking in C++ Volume 1 *-- Bruce Eckel* `Thinking in C++ Volume 1 Zipped <http://www.babeuk.net/mirror/book/TICPP-2nd-ed-Vol-one.zip>`_. +.. _Thinking in C++ Volume 2: + Book: Thinking in C++ Volume 2 *-- Bruce Eckel and Chuck Allison* Available on the Internet on many `Book Download Sites <http://mindview.net/Books/DownloadSites>`_. @@ -485,12 +549,16 @@ Book: Thinking in C++ Volume 2 *-- Bruce Eckel and Chuck Allison* `Thinking in C++ Volume 2 Zipped <http://www.babeuk.net/mirror/book/TICPP-2nd-ed-Vol-two.zip>`_. +.. _Traits - a new and useful template technique: + Article: Traits: a new and useful template technique *-- Nathan C. Myers* The first presentation of the traits technique is from this paper, `Traits: a new and useful template technique <http://www.cantrip.org/traits.html>`_. It is now a common C++ programming idiom, which is even used in the C++ standard. +.. _Writing Compilers and Interpreters: + Book: Writing Compilers and Interpreters -- An Applied Approach Using C++ *-- Ronald Mak* Published by Wiley; Second Edition, ISBN: 0-471-11353-0 @@ -501,6 +569,8 @@ Book: Writing Compilers and Interpreters -- An Applied Approach Using C++ *-- Ro C++ as it still uses :code:`#include <iostream.h>` and the like, there is no use of STL etc.). +.. _STL Home: + Web site: STL Home `SGI's STL Home Page <http://www.sgi.com/tech/stl/index.html>`_, which includes diff --git a/source/tools/gnu_build_system/gnu_build_system.rst b/source/tools/gnu_build_system/gnu_build_system.rst index 951c514a49e84da87401a5f50f91069322eba886..358e62a04824c94988460983e7f0bd98cc36ccd2 100644 --- a/source/tools/gnu_build_system/gnu_build_system.rst +++ b/source/tools/gnu_build_system/gnu_build_system.rst @@ -6,7 +6,7 @@ The GNU Build System Automake is used to facilitate the writing of power :file:`Makefile`. Libtool eases the creation of libraries, especially dynamic ones. Autoconf is required by Automake: we do not address portability issues -for this project. :ref:`Autotools Tutorial`, for documentation. +for this project. See :ref:`Autotools Tutorial <Autotools Tutorial>`, for documentation. Using :code:`info` is pleasant, for instance :code:`info autoconf` on any properly set up system. diff --git a/source/tools/monoburg.rst b/source/tools/monoburg.rst index 77590e633504fc7612c631991b32757656a15e19..bdd3b4909a1a1436bad5e18fb98ea792ca582690 100644 --- a/source/tools/monoburg.rst +++ b/source/tools/monoburg.rst @@ -22,5 +22,7 @@ Resources: Some papers on code generator generators are available in the bibliography. :ref:`BURG - Fast Optimal Instruction Selection and Tree -Parsing`, and :ref:`Engineering a simple efficient code generator -generator`. +Parsing <BURG - Fast Optimal Instruction Selection and Tree +Parsing>`, and :ref:`Engineering a simple efficient code generator +generator <Engineering a simple efficient code generator +generator>`. diff --git a/source/tools/programming_environment.rst b/source/tools/programming_environment.rst index 77f98e1d3c281567c583dd0ee64115786718b441..11e33381c5a2e85d05f00db3bf6703d69670f441 100644 --- a/source/tools/programming_environment.rst +++ b/source/tools/programming_environment.rst @@ -22,7 +22,7 @@ This section lists the tools you need to work in good conditions. +----------+-------------------+------------------------------------+ | GNU Make | |makeversion| | | +----------+-------------------+------------------------------------+ -| Boost | |boostversion| | TC >= 5, :ref:`Boost.org`. | +| Boost | |boostversion| | TC >= 5, :ref:`Boost <Boost.org>` | +----------+-------------------+------------------------------------+ | Doxygen | |doxygenversion| | :ref:`DoxygenTC`. | +----------+-------------------+------------------------------------+ diff --git a/source/tools/valgrind.rst b/source/tools/valgrind.rst index 17a0768a4888485abeda19d4f01e78aa391ddb14..00313f484311a64a4e211e1c31fec885c1740089 100644 --- a/source/tools/valgrind.rst +++ b/source/tools/valgrind.rst @@ -39,7 +39,7 @@ I (Akim) personally use the following shell script to track memory leaks: **File 5.1**: v -For instance on :ref:`0.tig`, +For instance on :ref:`0.tig <0.tig>`, .. command-output:: v tc -XA 0.tig :shell: