mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-11-05 13:09:10 +00:00
fix some wording problems Daniel pointed out, make a example actually real.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76751 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
parent
38c3363090
commit
59fec6a532
@ -631,7 +631,7 @@ be a big understandability win.</p>
|
||||
|
||||
<div class="doc_text">
|
||||
|
||||
<p>It is very common to write inline functions that just compute a boolean
|
||||
<p>It is very common to write small loops that just compute a boolean
|
||||
value. There are a number of ways that people commonly write these, but an
|
||||
example of this sort of thing is:</p>
|
||||
|
||||
@ -653,8 +653,8 @@ be a big understandability win.</p>
|
||||
<p>This sort of code is awkward to write, and is almost always a bad sign.
|
||||
Instead of this sort of loop, we strongly prefer to use a predicate function
|
||||
(which may be <a href="#micro_anonns">static</a>) that uses
|
||||
<a href="#hl_earlyexit">early exits</a> to compute the predicate. Code like
|
||||
this would be preferred:
|
||||
<a href="#hl_earlyexit">early exits</a> to compute the predicate. We prefer
|
||||
the code to be structured like this:
|
||||
</p>
|
||||
|
||||
|
||||
@ -1050,21 +1050,27 @@ example:
|
||||
|
||||
<div class="doc_code">
|
||||
<pre>
|
||||
/// SomeCrazyThing - This namespace contains flags for ...
|
||||
namespace SomeCrazyThing {
|
||||
enum foo {
|
||||
/// X - This is the X flag, which is ...
|
||||
X = 1,
|
||||
|
||||
/// Y - This is the Y flag, which is ...
|
||||
Y = 2,
|
||||
|
||||
/// Z - This is the Z flag, which is ...
|
||||
Z = 4,
|
||||
|
||||
/// ALL_FLAGS - This is the union of all flags.
|
||||
ALL_FLAGS = 7
|
||||
};
|
||||
namespace llvm {
|
||||
namespace X86 {
|
||||
/// RelocationType - An enum for the x86 relocation codes. Note that
|
||||
/// the terminology here doesn't follow x86 convention - word means
|
||||
/// 32-bit and dword means 64-bit.
|
||||
enum RelocationType {
|
||||
/// reloc_pcrel_word - PC relative relocation, add the relocated value to
|
||||
/// the value already in memory, after we adjust it for where the PC is.
|
||||
reloc_pcrel_word = 0,
|
||||
|
||||
/// reloc_picrel_word - PIC base relative relocation, add the relocated
|
||||
/// value to the value already in memory, after we adjust it for where the
|
||||
/// PIC base is.
|
||||
reloc_picrel_word = 1,
|
||||
|
||||
/// reloc_absolute_word, reloc_absolute_dword - Absolute relocation, just
|
||||
/// add the relocated value to the value already in memory.
|
||||
reloc_absolute_word = 2,
|
||||
reloc_absolute_dword = 3
|
||||
};
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
@ -1114,7 +1120,8 @@ the contents of the namespace.</p>
|
||||
|
||||
<div class="doc_text">
|
||||
|
||||
<p>A common topic after talking about namespaces is anonymous namespaces.
|
||||
<p>After talking about namespaces in general, you may be wondering about
|
||||
anonymous namespaces in particular.
|
||||
Anonymous namespaces are a great language feature that tells the C++ compiler
|
||||
that the contents of the namespace are only visible within the current
|
||||
translation unit, allowing more aggressive optimization and eliminating the
|
||||
@ -1186,7 +1193,7 @@ bool StringSort::operator<(const char *RHS) const {
|
||||
of a large C++ file, that you have no immediate way to tell if it is local to
|
||||
the file. When it is marked static explicitly, this is immediately obvious.
|
||||
Also, there is no reason to enclose the definition of "operator<" in the
|
||||
namespace since it was declared there.
|
||||
namespace just because it was declared there.
|
||||
</p>
|
||||
|
||||
</div>
|
||||
|
Loading…
Reference in New Issue
Block a user