I am a newbie and have started using different compilers and tools to make myself familiar with their workings. I wanted to know that how compliant is gcc with the C++ standards. It is pretty obvious that no compiler is close to being completely compliant, but if there are some things which are not according to the ANSI/ISO standard; what are they in gcc?
I will be very grateful if someone who is an expert user of gcc can answer this doubt of mine?
There is a section on ANSI support. 4.4.1 does provide full ANSI support, except in specialty environments like embedded Linux or ARM, or in really old releases of gcc.
For C++ issues mostly boil down to extensions and implementation defined behaviors (semantics). You have read a lot, there is no way to shortcut that.
gcc can be told comply with standards, lots of them. Pick your favorite:
$ man gcc
GCC(1) GNU GCC(1)
NAME
gcc - GNU project C and C++ compiler
SYNOPSIS
gcc [-c|-S|-E] [-std=standard]
[-g] [-pg] [-Olevel]
[-Wwarn...] [-pedantic]
[-Idir...] [-Ldir...]
[-Dmacro[=defn]...] [-Umacro]
[-foption...] [-mmachine-option...]
[-o outfile] infile...
Only the most useful options are listed here; see below for the remain-
der. g++ accepts mostly the same options as gcc.
...
-std=
Determine the language standard. This option is currently only
supported when compiling C or C++. A value for this option must be
provided; possible values are
c89
iso9899:1990
ISO C90 (same as -ansi).
iso9899:199409
ISO C90 as modified in amendment 1.
c99
c9x
iso9899:1999
iso9899:199x
ISO C99. Note that this standard is not yet fully supported;
see <http://gcc.gnu.org/gcc-4.1/c99status.html> for more infor-
mation. The names c9x and iso9899:199x are deprecated.
gnu89
Default, ISO C90 plus GNU extensions (including some C99 fea-
tures).
gnu99
gnu9x
ISO C99 plus GNU extensions. When ISO C99 is fully implemented
in GCC, this will become the default. The name gnu9x is depre-
cated.
c++98
The 1998 ISO C++ standard plus amendments.
gnu++98
The same as -std=c++98 plus GNU extensions. This is the
default for C++ code.
Even when this option is not specified, you can still use some of
the features of newer standards in so far as they do not conflict
with previous C standards. For example, you may use "__restrict__"
even when -std=c99 is not specified.
The -std options specifying some version of ISO C have the same
effects as -ansi, except that features that were not in ISO C90 but
are in the specified version (for example, // comments and the
"inline" keyword in ISO C99) are not disabled.
gcc also has lots of language extensions, but you don't need to use them.
I have been using VS2005 for some time and also did a lot of reading on other compilers.
Well I observed that, each platform is providing extensions and libraries based only for their system/platform and at the same time even if you are able to port these platform-specific libraries to other compilers, still the compliance issue is lost to some extent.
Maybe I was wrong in generalizing it, but it was just an opinion.
Moving an application from Microsoft C++ to another C++ environment is nearly always challanging. Build failures usually comes down to (1) the silent non-standard compiler extensions that Microsoft supports by default (for example lvalue casts, zero length structure members) and (2) the fact that common C++ libraries have yet to be fully standardized. It is rarely the core C++ compiler itself.
I'd finger the project autogenerator as the main culprit. It treats Microsoft's custom environment as the golden standard. It's possible to write portable code in Visual C, but they don't make it easy for you!