g++ man page on 4.4BSD

Man page or keyword search:  
man Server   1065 pages
apropos Keyword Search (all sections)
Output format
4.4BSD logo
[printable version]

G++(1)				   GNU Tools				G++(1)

NAME
       g++ - GNU project C++ Compiler (v2 preliminary)

SYNOPSIS
       g++ [option | filename ]...

DESCRIPTION
       The  C  and  C++	 compilers are integrated; g++ is a script to call gcc
       with options to recognize C++.  gcc processes input files  through  one
       or more of four stages: preprocessing, compilation, assembly, and link‐
       ing.  This man page contains full descriptions for  only	 C++  specific
       aspects of the compiler, though it also contains summaries of some gen‐
       eral-purpose options.  For a fuller explanation of  the	compiler,  see
       gcc(1).

       C++  source  files use one of the suffixes `.C', `.cc', or `.cxx'; pre‐
       processed C++ files use the suffix `.ii'.

OPTIONS
       There are many  command-line  options,  including  options  to  control
       details	of optimization, warnings, and code generation, which are com‐
       mon to both gcc and g++.	 For full  information	on  all	 options,  see
       gcc(1).

       Options must be separate: `-dr' is quite different from `-d -r '.

       Most  `-f'  and	`-W'  options  have  two  contrary  forms:  -fname and
       -fno-name (or -Wname and -Wno-name). Only  the  non-default  forms  are
       shown here.

       -c     Compile or assemble the source files, but do not link.  The com‐
	      piler output is an object	 file  corresponding  to  each	source
	      file.

       -Dmacro
	      Define macro macro with the string `1' as its definition.

       -Dmacro=defn
	      Define macro macro as defn.

       -E     Stop  after  the	preprocessing  stage;  do not run the compiler
	      proper.  The output is preprocessed source code, which  is  sent
	      to the standard output.

       +eN    control whether virtual function definitions in classes are used
	      to generate code, or only to define interfaces for  their	 call‐
	      ers.   These  options are provided for compatibility with cfront
	      1.x usage; the recommended GNU  C++  usage  is  to  use  #pragma
	      interface and #pragma implementation, instead.

	      With `+e0', virtual function definitions in classes are declared
	      extern; the declaration is used only as an interface  specifica‐
	      tion,  not  to  generate code for the virtual functions (in this
	      compilation).

	      With `+e1', g++ actually generates the code implementing virtual
	      functions defined in the code, and makes them publicly visible.

       -fall-virtual
	      When  you	 use the `-fall-virtual', all member functions (except
	      for  constructor	functions  and	new/delete  member  operators)
	      declared	in  the	 same  class  with  a ``method-call'' operator
	      method are treated as virtual functions of the given class.   In
	      effect, all of these methods become ``implicitly virtual.''

	      This  does not mean that all calls to these methods will be made
	      through the internal table of virtual functions.	There are some
	      circumstances  under  which it is obvious that a call to a given
	      virtual function can be made directly, and in  these  cases  the
	      calls still go direct.

	      The  effect  of  making  all  methods of a class with a declared
	      `operator->()()'	implicitly   virtual   using   `-fall-virtual'
	      extends also to all non-constructor methods of any class derived
	      from such a class.

       -fdollars-in-identifiers
	      Permit the use of `$' in identifiers.  Traditional C allowed the
	      character	 `$'  to  form	part of identifiers; by default, GNU C
	      also allows this.	 However, ANSI C forbids `$'  in  identifiers,
	      and GNU C++ also forbids it by default on most platforms (though
	      on some platforms it's enabled by default for GNU C++ as well).

       -felide-constructors
	      Use this option to instruct the compiler	to  be	smarter	 about
	      when  it can elide constructors.	Without this flag, GNU C++ and
	      cfront both generate effectively the same code for:

	      A foo ();
	      A x (foo ());   // x initialized by `foo ()', no ctor called
	      A y = foo ();   // call to `foo ()' heads to temporary,
			      // y is initialized from the temporary.

	      Note the difference!  With this flag, GNU	 C++  initializes  `y'
	      directly	from the call to foo () without going through a tempo‐
	      rary.

       -fenum-int-equiv
	      Normally GNU C++ allows conversion of enum to int, but  not  the
	      other  way around.  Use this option if you want GNU C++ to allow
	      conversion of int to enum as well.

       -fgnu-binutils

       -fno-gnu-binutils
	      `-fgnu-binutils ' (the default for most, but not all, platforms)
	      makes  GNU  C++ emit extra information for static initialization
	      and finalization.	 This information has to be  passed  from  the
	      assembler	 to  the  GNU linker.  Some assemblers won't pass this
	      information; you must either use GNU as or  specify  the	option
	      `-fno-gnu-binutils'.

	      With `-fno-gnu-binutils', you must use the program collect (part
	      of the GCC distribution) for linking.

       -fmemoize-lookups

       -fsave-memoized
	      These flags are used to get the  compiler	 to  compile  programs
	      faster  using heuristics.	 They are not on by default since they
	      are only effective about half the time.  The other half  of  the
	      time programs compile more slowly (and take more memory).

	      The  first time the compiler must build a call to a member func‐
	      tion (or reference to a data  member),  it  must	(1)  determine
	      whether  the class implements member functions of that name; (2)
	      resolve which member function to call (which  involves  figuring
	      out  what	 sorts	of  type conversions need to be made); and (3)
	      check the visibility of the member function to the caller.   All
	      of  this	adds  up  to slower compilation.  Normally, the second
	      time a call is made to that member  function  (or	 reference  to
	      that  data  member), it must go through the same lengthy process
	      again.  This means that code like this

		cout << "This " << p << " has " << n << " legs.\n";

	      makes six passes through all three steps.	 By using  a  software
	      cache,  a	 ``hit''  significantly	 reduces  this cost.  Unfortu‐
	      nately, using the cache introduces another layer	of  mechanisms
	      which  must  be  implemented,  and  so  incurs its own overhead.
	      `-fmemoize-lookups' enables the software cache.

	      Because access privileges (visibility)  to  members  and	member
	      functions	 may differ from one function context to the next, g++
	      may need to flush the cache. With the `-fmemoize-lookups'	 flag,
	      the cache is flushed after every function that is compiled.  The
	      `-fsave-memoized' flag enables the same software cache, but when
	      the  compiler  determines	 that the context of the last function
	      compiled would yield the same  access  privileges	 of  the  next
	      function to compile, it preserves the cache.  This is most help‐
	      ful when defining many member functions for the same class: with
	      the  exception  of  member  functions which are friends of other
	      classes, each member function has exactly the same access privi‐
	      leges as every other, and the cache need not be flushed.

       -fno-default-inline
	      If  `-fdefault-inline'  is enabled then member functions defined
	      inside class scope are compiled inline  by  default;  i.e.,  you
	      don't need to add `inline' in front of the member function name.
	      By popular demand, this option is now the default.  To keep  GNU
	      C++    from    inlining	 these	 member	  functions,   specify
	      `-fno-default-inline'.

       -fno-strict-prototype
	      Consider the declaration int foo ();.  In C++, this  means  that
	      the  function  foo  takes	 no  arguments.	  In  ANSI  C, this is
	      declared int foo(void);.	With the flag `-fno-strict-prototype',
	      declaring functions with no arguments is equivalent to declaring
	      its argument list to be untyped, i.e., int foo (); is equivalent
	      to saying int foo (...);.

       -fnonnull-objects
	      Normally,	 GNU  C++ makes conservative assumptions about objects
	      reached through references.   For	 example,  the	compiler  must
	      check that `a' is not null in code like the following:
		  obj &a = g ();
		  a.f (2);
	      Checking	that  references  of  this  sort  have non-null values
	      requires extra code, however, and it  is	unnecessary  for  many
	      programs.	  You  can  use `-fnonnull-objects' to omit the checks
	      for null, if your program doesn't require the default checking.

       -fthis-is-variable
	      The incorporation of user-defined free store management into C++
	      has  made	 assignment  to	 this  an  anachronism.	 Therefore, by
	      default GNU C++ treats the type of this in a member function  of
	      class X to be X *const.  In other words, it is illegal to assign
	      to this within a class member function.  However, for  backwards
	      compatibility,   you  can	 invoke	 the  old  behavior  by	 using
	      `-fthis-is-variable'.

       -g     Produce debugging information in the operating  system's	native
	      format  (for  DBX or SDB or DWARF).  GDB also can work with this
	      debugging information.  On most systems  that  use  DBX  format,
	      `-g'  enables  use  of extra debugging information that only GDB
	      can use.

	      Unlike most other C compilers, GNU CC allows  you	 to  use  `-g'
	      with  `-O'.  The shortcuts taken by optimized code may occasion‐
	      ally produce surprising results: some variables you declared may
	      not exist at all; flow of control may briefly move where you did
	      not expect it; some statements may not be executed because  they
	      compute  constant	 results or their values were already at hand;
	      some statements may execute in  different	 places	 because  they
	      were moved out of loops.

	      Nevertheless it proves possible to debug optimized output.  This
	      makes it reasonable to use the optimizer for programs that might
	      have bugs.

       -Idir	Append	directory  dir to the list of directories searched for
	      include files.

       -Ldir   Add directory dir to the list of directories to be searched for
	      `-l'.

       -llibrary
		Use  the  library  named  library when linking.	 (C++ programs
	      often require `-lg++' for successful linking.)

       -O     Optimize.	 Optimizing compilation takes somewhat more time,  and
	      a lot more memory for a large function.

	      Without  `-O', the compiler's goal is to reduce the cost of com‐
	      pilation and to make debugging  produce  the  expected  results.
	      Statements  are  independent:  if	 you  stop  the program with a
	      breakpoint between statements, you can then assign a  new	 value
	      to  any  variable	 or  change  the  program counter to any other
	      statement in the function and get exactly the results you	 would
	      expect from the source code.

	      Without  `-O', only variables declared register are allocated in
	      registers.  The resulting compiled code is a little  worse  than
	      produced by PCC without `-O'.

	      With  `-O', the compiler tries to reduce code size and execution
	      time.

       -o file
	       Place output in file file.

       -S     Stop after the stage of compilation  proper;  do	not  assemble.
	      The  output  is  an  assembler  code file for each non-assembler
	      input file specified.

       -static
	      On systems that support dynamic linking, this  prevents  linking
	      with the shared libraries.  On other systems, this option has no
	      effect.

       -traditional
	      Attempt to support some aspects of traditional C compilers.

	      Specifically, for both C and C++ programs:

	  ·   In the preprocessor, comments convert to nothing at all,	rather
	      than to a space.	This allows traditional token concatenation.

	  ·   In  the  preprocessor,  macro  arguments	are  recognized within
	      string constants in a macro definition  (and  their  values  are
	      stringified,  though  without  additional quote marks, when they
	      appear in such a context).  The preprocessor always considers  a
	      string constant to end at a newline.

	  ·   The  preprocessor does not predefine the macro __STDC__ when you
	      use `-traditional', but still predefines__GNUC__ (since the  GNU
	      extensions  indicated  by	 __GNUC__ are not affected by `-tradi‐
	      tional').	 If you need to write header files that	 work  differ‐
	      ently  depending on whether `-traditional' is in use, by testing
	      both of these predefined macros you can distinguish four	situa‐
	      tions:  GNU  C,  traditional  GNU C, other ANSI C compilers, and
	      other old C compilers.

	  ·   In the preprocessor, comments convert to nothing at all,	rather
	      than to a space.	This allows traditional token concatenation.

	  ·   In  the  preprocessor,  macro  arguments	are  recognized within
	      string constants in a macro definition  (and  their  values  are
	      stringified,  though  without  additional quote marks, when they
	      appear in such a context).  The preprocessor always considers  a
	      string constant to end at a newline.

	  ·   The  preprocessor does not predefine the macro __STDC__ when you
	      use `-traditional', but still predefines__GNUC__ (since the  GNU
	      extensions  indicated  by	 __GNUC__ are not affected by `-tradi‐
	      tional').	 If you need to write header files that	 work  differ‐
	      ently  depending on whether `-traditional' is in use, by testing
	      both of these predefined macros you can distinguish four	situa‐
	      tions:  GNU  C,  traditional  GNU C, other ANSI C compilers, and
	      other old C compilers.

	  ·   String ``constants'' are	not  necessarily  constant;  they  are
	      stored  in  writable  space, and identical looking constants are
	      allocated separately.  (This  is	the  same  as  the  effect  of
	      `-fwritable-strings'.)

	      For C++ programs only (not C), `-traditional' has one additional
	      effect: assignment to this is permitted.	This is	 the  same  as
	      the effect of `-fthis-is-variable'.

       -Umacro
	      Undefine macro macro.

       -Wall  Issue  warnings  for  conditions	which pertain to usage that we
	      recommend avoiding and that we believe is easy to avoid, even in
	      conjunction with macros.

       -Wenum-clash
	      Warn when converting between different enumeration types.

       -Woverloaded-virtual
	      In  a  derived  class, the definitions of virtual functions must
	      match the type signature of a virtual function declared  in  the
	      base  class.  Use this option to request warnings when a derived
	      class declares a function that may be an	erroneous  attempt  to
	      define  a	 virtual  function: that is, warn when a function with
	      the same name as a virtual function in the base class, but  with
	      a	 type  signature that doesn't match any virtual functions from
	      the base class.

       -w     Inhibit all warning messages.

PRAGMAS
       Two `#pragma' directives are supported for GNU C++, to permit using the
       same  header  file for two purposes: as a definition of interfaces to a
       given object class, and as the full definition of the contents of  that
       object class.

       #pragma interface
	      Use  this	 directive in header files that define object classes,
	      to save space in	most  of  the  object  files  that  use	 those
	      classes.	 Normally, local copies of certain information (backup
	      copies of inline member functions,  debugging  information,  and
	      the  internal  tables  that implement virtual functions) must be
	      kept in each object file that includes class  definitions.   You
	      can  use	this  pragma to avoid such duplication.	 When a header
	      file containing `#pragma interface' is included  in  a  compila‐
	      tion,  this  auxiliary information will not be generated (unless
	      the main input source  file  itself  uses	 `#pragma  implementa‐
	      tion').  Instead, the object files will contain references to be
	      resolved at link time.

       #pragma implementation

       #pragma implementation "objects.h"
	      Use this pragma in a main input file, when you want full	output
	      from  included  header  files to be generated (and made globally
	      visible).	  The  included	 header	 file,	in  turn,  should  use
	      `#pragma	interface'.  Backup copies of inline member functions,
	      debugging information, and the internal tables used to implement
	      virtual functions are all generated in implementation files.

	      If you use `#pragma implementation' with no argument, it applies
	      to an include file with the same basename as your	 source	 file;
	      for  example,  in	 `allclass.cc',	 `#pragma  implementation'  by
	      itself is equivalent to `#pragma	implementation	"allclass.h"'.
	      Use the string argument if you want a single implementation file
	      to include code from multiple header files.

	      There is no way to split up the contents of a single header file
	      into multiple implementation files.

FILES
       file.h		  C header (preprocessor) file
       file.i		  preprocessed C source file
       file.C		  C++ source file
       file.cc		  C++ source file
       file.cxx		  C++ source file
       file.s		  assembly language file
       file.o		  object file
       a.out		  link edited output
       TMPDIR/cc∗	  temporary files
       LIBDIR/cpp	  preprocessor
       LIBDIR/cc1plus	  compiler
       LIBDIR/collect	  linker front end needed on some machines
       LIBDIR/libgcc.a	  GCC subroutine library
       /lib/crt[01n].o	  start-up routine
       LIBDIR/ccrt0	  additional start-up routine for C++
       /lib/libc.a	  standard C library, see intro(3)
       /usr/include	  standard directory for #include files
       LIBDIR/include	  standard gcc directory for #include files
       LIBDIR/g++-include additional g++ directory for #include

       LIBDIR is usually /usr/local/lib/machine/version.
       TMPDIR  comes from the environment variable TMPDIR (default /usr/tmp if
       available, else /tmp).

SEE ALSO
       gcc(1), cpp(1), as(1), ld(1), gdb(1), adb(1), dbx(1), sdb(1).
       `gcc', `cpp', `as',`ld', and `gdb' entries in info.
       Using and Porting GNU CC (for version 2.0), Richard M. Stallman, Novem‐
       ber  1990;  The	C  Preprocessor, Richard M. Stallman, July 1990; Using
       GDB: A Guide to the GNU Source-Level Debugger, Richard M. Stallman  and
       Roland  H.  Pesch,  December  1991;  Using  as: the GNU Assembler, Dean
       Elsner, Jay Fenlason & friends, March 1991; gld: the GNU linker,	 Steve
       Chamberlain and Roland Pesch, April 1991.

BUGS
       Report bugs to bug-g++@prep.ai.mit.edu.	Bugs tend actually to be fixed
       if they can be isolated, so it is in your interest to  report  them  in
       such a way that they can be easily reproduced.

COPYING
       Copyright (c) 1991 Free Software Foundation, Inc.

       Permission  is  granted	to make and distribute verbatim copies of this
       manual provided the copyright notice and	 this  permission  notice  are
       preserved on all copies.

       Permission  is granted to copy and distribute modified versions of this
       manual under the conditions for verbatim	 copying,  provided  that  the
       entire  resulting derived work is distributed under the terms of a per‐
       mission notice identical to this one.

       Permission is granted to copy and distribute translations of this  man‐
       ual into another language, under the above conditions for modified ver‐
       sions, except that this permission notice may be included  in  transla‐
       tions approved by the Free Software Foundation instead of in the origi‐
       nal English.

AUTHORS
       See the GNU CC Manual for the contributors to GNU CC.

GNU Tools			   27dec1991				G++(1)
[top]

List of man pages available for 4.4BSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
...................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net