c---dialect-options.html

gcc手册

     <br><dt><code>-nostdinc++</code>
     <dd>Do not search for header files in the standard directories specific to
C++, but do still search the other standard directories.  (This option
is used when building the C++ library.) 
</dl>

   <p>In addition, these optimization, warning, and code generation options
have meanings only for C++ programs:

     <dl>
<dt><code>-fno-default-inline</code>
     <dd>Do not assume <code>inline</code> for functions defined inside a class scope. 
See <a href="Optimize-Options.html#Optimize%20Options">Options That Control Optimization</a>.  Note that these
functions will have linkage like inline functions; they just won't be
inlined by default.

     <br><dt><code>-Wabi </code>(C++ only)<code></code>
     <dd>Warn when G++ generates code that is probably not compatible with the
vendor-neutral C++ ABI.  Although an effort has been made to warn about
all such cases, there are probably some cases that are not warned about,
even though G++ is generating incompatible code.  There may also be
cases where warnings are emitted even though the code that is generated
will be compatible.

     <p>You should rewrite your code to avoid these warnings if you are
concerned about the fact that code generated by G++ may not be binary
compatible with code generated by other compilers.

     <p>The known incompatibilities at this point include:

          <ul>

          <li>Incorrect handling of tail-padding for bit-fields.  G++ may attempt to
pack data into the same byte as a base class.  For example:

          <pre class="smallexample">               struct A { virtual void f(); int f1 : 1; };
               struct B : public A { int f2 : 1; };
               </pre>

          <p>In this case, G++ will place <code>B::f2</code> into the same byte
as<code>A::f1</code>; other compilers will not.  You can avoid this problem
by explicitly padding <code>A</code> so that its size is a multiple of the
byte size on your platform; that will cause G++ and other compilers to
layout <code>B</code> identically.

          </p><li>Incorrect handling of tail-padding for virtual bases.  G++ does not use
tail padding when laying out virtual bases.  For example:

          <pre class="smallexample">               struct A { virtual void f(); char c1; };
               struct B { B(); char c2; };
               struct C : public A, public virtual B {};
               </pre>

          <p>In this case, G++ will not place <code>B</code> into the tail-padding for
<code>A</code>; other compilers will.  You can avoid this problem by
explicitly padding <code>A</code> so that its size is a multiple of its
alignment (ignoring virtual base classes); that will cause G++ and other
compilers to layout <code>C</code> identically.

          </p><li>Incorrect handling of bit-fields with declared widths greater than that
of their underlying types, when the bit-fields appear in a union.  For
example:

          <pre class="smallexample">               union U { int i : 4096; };
               </pre>

          <p>Assuming that an <code>int</code> does not have 4096 bits, G++ will make the
union too small by the number of bits in an <code>int</code>.

          </p><li>Empty classes can be placed at incorrect offsets.  For example:

          <pre class="smallexample">               struct A {};
               
               struct B {
                 A a;
                 virtual void f ();
               };
               
               struct C : public B, public A {};
               </pre>

          <p>G++ will place the <code>A</code> base class of <code>C</code> at a nonzero offset;
it should be placed at offset zero.  G++ mistakenly believes that the
<code>A</code> data member of <code>B</code> is already at offset zero.

          </p><li>Names of template functions whose types involve <code>typename</code> or
template template parameters can be mangled incorrectly.

          <pre class="smallexample">               template &lt;typename Q&gt;
               void f(typename Q::X) {}
               
               template &lt;template &lt;typename&gt; class Q&gt;
               void f(typename Q&lt;int&gt;::X) {}
               </pre>

          <p>Instantiations of these templates may be mangled incorrectly.

     </ul>

     <br><dt><code>-Wctor-dtor-privacy </code>(C++ only)<code></code>
     <dd>Warn when a class seems unusable, because all the constructors or
destructors in a class are private and the class has no friends or
public static member functions.  This warning is enabled by default.

     <br><dt><code>-Wnon-virtual-dtor </code>(C++ only)<code></code>
     <dd>Warn when a class declares a non-virtual destructor that should probably
be virtual, because it looks like the class will be used polymorphically. 
This warning is enabled by <code>-Wall</code>.

     <br><dt><code>-Wreorder </code>(C++ only)<code></code>
     <dd>Warn when the order of member initializers given in the code does not
match the order in which they must be executed.  For instance:

     <pre class="smallexample">          struct A {
            int i;
            int j;
            A(): j (0), i (1) { }
          };
          </pre>

     <p>Here the compiler will warn that the member initializers for <code>i</code>
and <code>j</code> will be rearranged to match the declaration order of the
members.  This warning is enabled by <code>-Wall</code>. 
</dl>

   <p>The following <code>-W...</code> options are not affected by <code>-Wall</code>.

     <dl>
<dt><code>-Weffc++ </code>(C++ only)<code></code>
     <dd>Warn about violations of the following style guidelines from Scott Meyers'
<cite>Effective C++</cite> book:

          <ul>
<li>Item 11:  Define a copy constructor and an assignment operator for classes
with dynamically allocated memory.

          <li>Item 12:  Prefer initialization to assignment in constructors.

          <li>Item 14:  Make destructors virtual in base classes.

          <li>Item 15:  Have <code>operator=</code> return a reference to <code>*this</code>.

          <li>Item 23:  Don't try to return a reference when you must return an object.

     </ul>

     <p>and about violations of the following style guidelines from Scott Meyers'
<cite>More Effective C++</cite> book:

          <ul>
<li>Item 6:  Distinguish between prefix and postfix forms of increment and
decrement operators.

          <li>Item 7:  Never overload <code>&amp;&amp;</code>, <code>||</code>, or <code>,</code>.

     </ul>

     <p>If you use this option, you should be aware that the standard library
headers do not obey all of these guidelines; you can use <code>grep -v</code>
to filter out those warnings.

     <br><dt><code>-Wno-deprecated </code>(C++ only)<code></code>
     <dd>Do not warn about usage of deprecated features.  See <a href="Deprecated-Features.html#Deprecated%20Features">Deprecated Features</a>.

     <br><dt><code>-Wno-non-template-friend </code>(C++ only)<code></code>
     <dd>Disable warnings when non-templatized friend functions are declared
within a template.  With the advent of explicit template specification
support in G++, if the name of the friend is an unqualified-id (i.e.,
<code>friend foo(int)</code>), the C++ language specification demands that the
friend declare or define an ordinary, nontemplate function.  (Section
14.5.3).  Before G++ implemented explicit specification, unqualified-ids
could be interpreted as a particular specialization of a templatized
function.  Because this non-conforming behavior is no longer the default
behavior for G++, <code>-Wnon-template-friend</code> allows the compiler to
check existing code for potential trouble spots, and is on by default. 
This new compiler behavior can be turned off with
<code>-Wno-non-template-friend</code> which keeps the conformant compiler code
but disables the helpful warning.

     <br><dt><code>-Wold-style-cast </code>(C++ only)<code></code>
     <dd>Warn if an old-style (C-style) cast to a non-void type is used within
a C++ program.  The new-style casts (<code>static_cast</code>,
<code>reinterpret_cast</code>, and <code>const_cast</code>) are less vulnerable to
unintended effects, and much easier to grep for.

     <br><dt><code>-Woverloaded-virtual </code>(C++ only)<code></code>
     <dd>Warn when a function declaration hides virtual functions from a
base class.  For example, in:

     <pre class="smallexample">          struct A {
            virtual void f();
          };
          
          struct B: public A {
            void f(int);
          };
          </pre>

     <p>the <code>A</code> class version of <code>f</code> is hidden in <code>B</code>, and code
like this:

     <pre class="smallexample">          B* b;
          b-&gt;f();
          </pre>

     <p>will fail to compile.

     <br><dt><code>-Wno-pmf-conversions </code>(C++ only)<code></code>
     <dd>Disable the diagnostic for converting a bound pointer to member function
to a plain pointer.

     <br><dt><code>-Wsign-promo </code>(C++ only)<code></code>
     <dd>Warn when overload resolution chooses a promotion from unsigned or
enumeral type to a signed type over a conversion to an unsigned type of
the same size.  Previous versions of G++ would try to preserve
unsignedness, but the standard mandates the current behavior.

     <br><dt><code>-Wsynth </code>(C++ only)<code></code>
     <dd>Warn when G++'s synthesis behavior does not match that of cfront.  For
instance:

     <pre class="smallexample">          struct A {
            operator int ();
            A&amp; operator = (int);
          };
          
          main ()
          {
            A a,b;
            a = b;
          }
          </pre>

     <p>In this example, G++ will synthesize a default <code>A&amp; operator =
(const A&amp;);</code>, while cfront will use the user-defined <code>operator =</code>. 
</dl>

   </body></html>