Of course, Comeau C++ is also Comeau C, and we strongly support Standard C as well. Actually, we support the core language features of C99, the newest revision of Standard C, as well as a Microsoft compatibility mode. There are other modes too, check the online documentation.

Also, take a sneak peak at Comeau C/C++ 4.3.9 which includes support for the upcoming C++0x standard. Currently, we've added some C++0x features to "Comeau online". Have a look!

The 4.3.3 free C/C++ upgrade adds a number of features in addition to those features already supported. Comeau C/C++ 4.3.3 continues our absolutely meticulous tracking of Standard C++ and Standard C. Don't hesitate to try these features out with "Comeau online", the online version of the Comeau C/C++ compiler. Here's some of the 4.3.3 features:

• Full core language support of C++98, C++03, C89/90, C95, C99
• Compatibility with gnu, both for gcc and g++, in addition to the plethora of gnu features already supported. Note that in some cases, GNU support may be provided as a custom port. Comeau is now highly source code compatible with gnu. Newest additions include:
  • New attributes: deprecated, used and init_priority
  • Min and max operators, <? and >? respectively
  • Statement expressions
• Initial support of the IA-64 ABI.
• Compatibility with VC++, in addition to those features already mentioned further below. Additions include:
  • Support of new VC++ 7.0 as a backend C compiler under Windows
  • Support of new VC++ 7.1 as a backend C compiler under Windows
  • The __noop feature in VC+ 7.0
  • Initial support for bracketed attributes, this may require a custom port
• Initial support of new BCB 6 as a backend C compiler under Windows
• Initial (beta) support of Mac OS X 10.3.x "Panther" with gcc 3.3
• #pragma diag_suppress
• Support of UPC (Unified Parallel C) extensions. This mode is currently only available through a custom port.

Of course, previous releases of Comeau C++ were also packed with features. The below features list contains features already available in previous releases including support for the following major C++ features (using Ellis and Stroustrup's "ARM" as baseline):

• Polymorphic covariant return types on virtual functions. (So the return type of virtuals can differ if they're in the same inheritance hierarchy.)
• Koenig lookup aka argument-dependent lookup is now implemented for function calls and overloaded operators. Can be controlled by --[no_]arg_dep_lookup. Microsoft and cfront modes preclude this feature. (Argument-dependent lookup finds instances of the named functions in the classes and namespaces associated with the argument types, and adds them to the set of functions considered by overload resolution.)
• Friend injection: A friend function in a class in a namespace scope must literally be declared in the namespace to be visible. This can be controlled via --[no_]friend_injection. Microsoft and cfront modes preclude this feature.
• Class name injection, in strict mode. Can be controlled by --[no_]class_name_injection.
• So-called "placement" delete.
• Enhanced Templates:
• The export keyword, and its full semantics, for exporting templates. (And who do you think will have it first? :) Besides, our previous automatic template instantiation technology weakly mimics various aspects of the export semantics.)
• Out-of-class member template partial specializations.
• Koenig lookup, aka the argument-dependent lookup rules, are now implemented for templates. This is enabled in strict mode, but disabled in relaxed mode and Microsoft mode, and can also be controlled via --[no_]dep_name. This is significant because much existing code will break. This is so because templates must now be parsed differently. To wit, previously, the named of the function to be called were looked up in the context of the template definition. But with dependent name calls, the function is also look up in the context of the point of instantiation, via argument-dependent lookup. This means more template parsing than previously need to occur, including parsing template definitions at their points of definition. This implies providing names not yet declared, making names visible, and using typename properly.
• So-called explicit specification of function template arguments (in declaration contexts *and* in expression contexts), therefore the template parameter need not have to be used in the signature of the function template as it was required to be in the original specification of templates.
• Use of the template keyword in qualified names and class member access, so that dependent names can be considered to be a template.
• Template argument deduction, including "nondeduced" contexts (as described in the Standard).
• Unnamed template parameters are now allowed.
• Member templates (classes and functions).
• Class template partial specialization
• Function template partial ordering
• Function template's can have their arguments explicitly specified
• New template specialization syntax: template<>.
• Explicit instantiation directive.
• Recognition and use of the typename keyword.
• Template parameters with default arguments.
• Templates with additional nontype template parameters (but not template parameters that are literally templates themselves).
• So-called two-phase name binding in templates, as described in sections [temp.res] and [temp.dep] of the Standard.
• Template template parameters. This is not referring to classes based upon templates, but template arguments that are literally templates themselves. Here's an example:

  // Regular type and non-type template args
  template <typename T, int size>
  class xyz { T array[size]; };
  // New template template arg syntax!
  template <template <typename T, int size> class TT>
  class blah { TT<int, 99> mem; };
  blah<xyz> whatever; // Pass xyz, a template itself
  

• Member function cv-qualifiers on the typedef of a function type.
• Out-of-class partial specialization definitions of existing class member template partial specialization declarations.
• Explicit instantiation directives with throw specifications are allowed, and checked.
• Nondeduced array bounds are now accepted.
• New name mangling for templates.
• Template friend declarations/definitions in class template/class defs.
• Automatic template instantiation (not available on all platforms).
• New ::template and ->template syntax
• You can now say &T::x, where T is a template parameter.
• We supported partial ordering already. However, a change of their specification during standardization means we needed to re-sync, and so have now done so by not removing reference qualifiers.
• Compilation integrity has been enhanced so that template information is not corrupted or out of sync with source files.
• Etc.
• Exception handling:
• Features: try, catch, throw.
• Functions: terminate(), unexpected(), uncaught_exception().
• So-called function-try-blocks, that is, try and catch blocks surrounding a whole constructor, destructor or function, is now supported.
• Exception specifications on the return type of functions are now allowed. (This is not referring to the type of the current function, which is already allowed, but also of its return type.)
• namespaces, using directives, using declarations.
• RTTI (run time type identification), dynamic_cast, typeid.
• New-style casts: static_cast, reinterpret_cast, const_cast and dynamic_cast
• "condition declarations" allowed in if, switch, for and while
• New keywords:
  • mutable,
  • bool
  • wchar_t
  • explicit keyword to indicate non-converting constructors.
• Operator overloading on enums
• Array new and array delete (operator new[]/operator delete[])
• [static data] "member constants".
• New template optimizations:
• Further optimization of template instantiation with less iteration.
• Optimization where template static data members are only instantiated if referenced.
• Optimization of template instantiation by using less memory(for instance, in the case of simultaneous instantiations)
• Optimization via one instantiation per object file, so that a compilation of one source file may produce several object files with better template instantiation granularity. That is, all instantiation don't need to be brought into the executable. This is useful in writing libraries. The --one_instantiation_per_object option will enable this feature. Furthermore, in order to process this, the compiler's memory requirements have been reduced.
• Optimization where default arguments are now instantiated only when the default argument is used in a call. This is so for function templates, and of member functions of class templates.
• Optimization to reduce multiple superfluous type_info objects in -tlocal mode (previously, template classes and their members were given internal linkage in -tlocal mode, now the template class is given external linkage).
• Enhancements to catch template recursions, also user-defined control via --pending_instantiations
• New general optimizations:
• Optimization of an empty base class, to not take up any space in the layout of a derived object.
• Optimization of inlining, to avoid generating temporaries, and furthermore, to try to reuse any temporaries generated, therefore reducing inlining requirements on the executable code. For instance: when the argument expression can be used directly, say when it is a constant, or when an auto variable cannot change its value across a function call, or if there are no side-effects, a global variable passed as a parameter can just be used as itself, or if an argument that is a field selection on a call that has no side effects, or pointer-to-member-function constants are considered constant arguments and can therefore be used directly in place of the corresponding parameter within the inlined function call (no copy to a temporary is needed).
• Optimization of name lookup in the presence of namespaces.
• Quality of implementation:
• Diagnostics when "impossible" types are used in a catch clause (for instance, an abstract class, a pointer/reference to an incomplete type).
• Duplicate diagnostics when instantiating templates are now suppressed.
• Names used from an unnamed namespace need to be defined. Also warn on unused static and non-virtuals. (But don't warn about constructors, destructor, or operator=()'s because they might be on purpose)
• Compile time to perform the empty base class optimization has been drastically reduced.
• extern inline functions now integrated into our template instantiation mechanism (To wit, if needed, the address of out-of-line inline functions is supposed to remain constant.) This is not available on all ports.
• Templates in unnamed namespaces are now integrated with "one instantiation per object" mode.
• As an optimization, no temporary is created in some cases where there is no user-declared (so bitwise) copy constructor, as it's elided.
• Loops in operator->s are now diagnosed as an error.
• Warning about cast from integral to pointer of smaller size
• Carriage returns are now allowed in non-Windows ports so as to accept DOS/Windows source files that were either copied or are being compiled through a network.
• Warning about extraneous text at the end of a preprocessing directive
• Operator functions can now be overloaded on enum types.
• Enums might be stored as integer types larger than int (except in Microsoft mode). The type selected is the smallest integer type greater than int that is large enough to contain the largest of the enumeration constants. This may not be available on all platforms and/or may require a custom port.
• String literals are now const, in specific, they are static const char[]s. Wide string literals are now static const wchar_t[]s.
• void functions can now return void expressions.
• When not in strict ANSI-C mode, __STDC__ can now be redefined.
• A linkage specification such as extern "C" is now permitted with inlines.
• The expression in expression->sm and expression.sm where sm is a static member will now unconditionally evaluate the left hand expression.
• Support for long long. This may not be available on all platforms and/or may require a custom port.
• Support long double. This may not be available on all platforms and/or may require a custom port. Ditto for being able to output double instead of long double for back ends that don't support long double yet.
• The --preinclude option to automatically add a file at the beginning of a compilation. This may not be available on all platforms and/or may require a custom port.
• Header files w/o suffixes (which we've always supported) can now be assumed to really have a suffix implicitly added. The default suffixes tried include .h. User control is allowed via -incl_suffixes. This permits a "fighting chance" level of backward compatibility with new style code using old style headers. This may not be available on all platforms and/or may require a custom port.
• Warnings from "systems" include files can now be suppressed. Said files include those specified in directories with --sys_include or the USR_INCLUDE environment variable, and not from those specified via -I or --include_directory. This may not be available on all platforms and/or may require a custom port.
• A diagnostic is generated if main() is not declared to return int.
• So-called universal character names, aka UCNs, (e.g., \u0401) are now accepted in C++ mode in identifiers, character literals, and string literals (they have always been accepted in comments because they have no special meaning there)
• Nested class definitions allowed outside of enclosing class, nontemplate and template.
• Identifiers declared in the initialization section of a for loop are only in the scope of the for statement (the old way will still be supported with a compiler switch).
• const/volatile qualifiers on the types of class rvalues are now retained on function returns
• "Trivial" AND "nontrivial" constructors. Also, PODs and non-PODs with trivial constructors.
• Linkage specifications are involved in a function's type.
• extern inline functions. Also, default linkage for inline functions is external.
• Explicit destructor calls can be via typedef names.
• Digraphs, also alternative token keywords.
• Implicit return 0; from main(), respectively.
• Casting a pointer to member constant of one class to that of another unrelated class with reinterpret_cast.
• typedefs of const member functions
• Function-style macros now allowed on command line with -D option
• Enforcing diagnostic when reinterpret_casting a pointer to function to a pointer to an object in strict mode. This is allowed in non-relaxed mode if the destination type is large enough.
• "MSC keywords" (near/far/etc), in microsoft mode. This may not be available for all ports.
• Support for so-called EC++, "Embedded C++" via a command line switch --embedded_c++ to allow reporting of features to be excluded from normal C++. In this mode, the preprocessor symbol __embedded_cplusplus is also defined. This may not be available on all platforms and/or may require a custom port.
• Compatibility modes for: cfront, Microsoft C++, pcc, etc. when appropriate. This may not be available for all ports.
• Compatibility with gnu, although not a specific dialect of Comeau C++ per se, some features are available:
  • g++ can treat std and the global namespace as aliases. We support this behavior when --ignore_std is specified.
  • Support for gcc's #include_next in non-strict mode. This starts at the include search path directory after the one in which the current file was found. This is useful to "hijack" a header file. This may not be available in all ports.
  • A detailed list of Comeau C++'s support for compatibility with gcc and g++ language extensions can be found here.
• A new dialect, Sun mode, is now supported via --sun and --no_sun for compatibility with Sun CC 5.0. This option may not be supported in all ports. Here's some aspects to it:
  • Undeclared function templates allowed in class templates.
  • As an extension, a static_cast of a void * to a pointer to a function is allowed (similarly for compatibility with Microsoft).
  • A non-tag from one scope hides a tag from another scope when the former is visible through a using directive, instead of being ambiguous.
  • An unqualified friend class is look up'd in the outer scope, not the innermost enclosing namespace scope.
  • An extern "C" name made visible with a using may be redeclared or redefined without qualification.
  • An inline function, which implies static in Sun mode, that appears in an extern "C" block now acquires extern "C" name linkage.
• Rehosting as a cross-compiler for embedded systems et al, when appropriate. This of course must be done by Comeau as a custom port.
• K&R C/ANSI C/C++ selectable integrated preprocessor (an output file can be obtained too). This may not be available in all ports.
• Precompiled headers, when appropriate.
• #pragmas.
• Etc.

Support for all of the features mentioned above means that Comeau C/C++ is COMPLETELY up to date in language features. We're proud to say that we are language compliant, and then some. Consider this:

• This free C++ upgrade includes all of the language features that the ANSI/ISO C++ committee agreed upon for Standard C++. This includes C++98 and C++03. It even addresses some of the defect reports detected by the committee since the last Standard.
• This free C++ upgrade includes all of the language features that the ANSI/ISO C committee agreed upon for Standard C. This includes C89/C90, C95, and C99. It even addresses some of the defect reports detected by the committee since the last Standard.
• A multi-way transition model, for "old" or non-standard code, is available for many features (for instance, bool can be enabled or disabled, or, there is a cfront mode, and so on).
• Comeau C/C++ is high quality, robust and stable.
• Comeau C/C++ is available for multiple platforms.
• Comeau can customize Comeau C/C++ for you! Email us with your customization needs!
• Comeau can port Comeau C/C++ to new platforms for you! Email us about your platform needs!
• Comeau has been in business over 20 years. Tap into our experience now!

• UNKNOWN!
• Furthermore, as of Comeau C/C++ 4.3.9, you can even find features in the next upcoming C++ standard, currently known as "C++0x". Take a sneak peek of what we have supported for C++0x; currently you can try it out yourself via "Comeau online"!

In October 1999, a new ISO Standard for C, aka C99, was accepted by the ISO/ANSI C committee as the next revision of Standard C (ISO/IEC 9899:1999). In addition to our strong support of Standard C ("C89/C90") via --c, and the new Standard C++ features that 4.3.3 supports as listed above, it also supports many of the C99 features provided by this new revised ISO Standard for C. These features may be supported in "C99 mode" via --c99 of Comeau C/C++ on some platforms as follows:

• So-called variable length arrays. Users can opt for this by using --[no_]vla in non-C99 C modes. This may not be available on all platforms and/or may require a custom port.
• So-called compound literals. User control is via --[no_]compound_literals in non-C99 C modes. This may not be available on all platforms and/or may require a custom port.
• So-called designated initializers. Users can opt for this by using --designators in non-C99 C modes. Additionally, by using --extended_designators it will allow field_name: instead of .file_name =, as well as a new array range designator of the form [i...j]. Finally, when --microsoft is specified, non-array designator initializers may be a function call. This may not be available on all platforms and/or may require a custom port.
• So-called variadic macros, macros taking a variable number of arguments. Two flavors are supported. The first form can be enabled with --variadic_macros. This form is as per the C99 Standard. The second form can be enabled with --extended_variadic_macros and is an extension to C99, allowing for the removal of some non-whitespace that is sometimes undesirable as the outcome of the first form (for instance, a trailing comma). This may not be available on all platforms and/or may require a custom port. This can also be accepted in C++ mode if specified on the command line.
• Here's a list of some of the C99 (ISO/IEC 9899:1999) additions in Comeau C99:
  • New C99 mode controlled via --c99 command line option.
  • Designated initializers

    struct xyz { int a; int b; int c[99]; };
    // DI allow for that members can be named in initializer lists
    struct xyz AnXyz = { .b = 99, .a = -99 };
    struct xyz AnXyz2 = { .b = 99 };
    
    // DI's ok for array objects too
    struct xyz AnXyz3 = { .c[2] = 44 };
    int array[99] = { [33] = 33, [66] = 66 };
    struct xyz AnXyz3b[] = { [5].c[2] = 44 };
    
    struct abc { int d; struct xyz xyzmem; };
    // DIs ok subobject too
    struct abc AnAbc = { .d = 11, .xyzmem.b = 33 };
    
    // "weird" stuff too: take last DI, but eval all
    struct abc AnAbc2 = { .d = 11, .d = 22 };
    int foo() { /* Computing Something... */ return 0; }
    void bar()
    {
        // Function necessary because foo() is not constant
        struct abc AnAbc3 = { foo(), .d = 22 };
    }
    
    int main()
    {
        // unions ok too
        union U { int intmem; float floatmem; };
        union U u = { .floatmem = 99.99 };
        union U u2 = { .intmem = AnXyz2.b + 99 };
        return 0;
    }
        

  • Compound literals

    // Compound literals avoid needing to create "funny named" object that
    // might otherwise serve no other purpose but to be pointed to, etc.
    // Some argue they are similar in nature to C++ construct calls.
    //
    // Compound literals are composed with a cast-like-kinda construct
    // with a brace'd initializer to create unnamed array's.
    
    int foo() { return 99; }
    
    struct xyz { int i; int j; };
    void bar(struct xyz dummy_arg) { }
    void baz(struct xyz* dummy_arg) { }
    
    // Initializers for the literals are required to be constant if in file scope
    // Unnamed array is static if in file scope
    int *p = (int []){ 1, 2 }; // p points to unnamed array of int[2]
    
    int main()
    {
        // non-constant initializers ok in enclosing block
        // unnamed array is auto here
        // foo() only done once
        int *p2 = (int []){ 1, foo() }; // ok
    
        (int []){ 1, 2 } = 99; // Error
        *(int []){ 1, 2 } = 99; // Ok, but yuck
    
        // Note the literal need not always just be an array
        p = &(int){ 1 }; // ok, but be careful
    
        // const compound literals need not be distinct
        const int *cix = (const int []){ 1, 2 };
        const int *ciy = (const int []){ 1, 2 }; // Same literal?
    
        // String literals do not have const in C. This alternative
        // might help in some cases (perhaps wrapped in a macro??):
        const char *ccp = (const char []){ "Comeau C/C++" };
    
        // Pass a compound literal to a function
        bar((struct xyz){ 123, 456 });
        // Combo'd with DI's from above:
        bar((struct xyz){ .i = 123, .j = 456 });
    
        // Pass addr of literals:
        baz(&(struct xyz){ 456, 789 });
    }
        

  • Variable length arrays, aka, VLAs (using VLA requires a C compiler which supports VLAs, which is usually the case when for the platforms we support where gcc is the backend compiler used).

    #include <stdio.h>
    #include <stdlib.h>
    void funcWithVLA(int n)
    {
        // Note that during the lifetime of a vla, its size does not change
        int vla[n];
        // sizeof eval'd at run-time not compile-time
        printf("%d\n", sizeof(vla)); // sizeof(int) * n
    }
    // Use * only in prototype, not def
    // * indicates unspecified dimension
    void funcTakingVLA(int size, int a[*]);
    
    int Global = 99; // boo hiss
    int GlobalVLA[Global]; // Error: VLA can't be extern
                           // extern's need constant for dimension
    
    int main()
    {
        int n = 99;
        int m = 999;
        extern int externVla[n]; // Error: VLA still can't be extern
        static int staticVla[n]; // Error: VLA can't be static either
        static int (*p)[n]; // ok: p has block scope and is *ptr* to a VLA
        int unknownSize[*]; // Error: VLA with unspecified bounds
                            // only allowed in function prototype scope
        struct blah {
            int vlamember[n]; // Error: struct members can't be VLAs
        };
    
        // Eval n at runtime, therefore autoVLA is a VLA
        int autoVLA[n]; // ok
        int twoD[n][m]; // ok: 2d array, and so on
    
        int randVla[rand()]; // :)  size expression not constant, watch out for 0
    
        n = -99;
        int negVla[n]; // Error: size shall evaluate > 0
                       // This will normally be a runtime thing, not compile time
    
        // n eval'd here, not when VlaTD used
        typedef int VlaTD[n]; // ok: has block scope
        VlaTD  someid; // ok
     
        funcWithVLA(n);
        funcTakingVLA(n, autoVLA);
    
        // Remember, const is readonly in C, not as constant'y as in C++
        const int dimension = 99;
        int StillAVLA[dimension]; // Therefore, this is a VLA
    
        // VLA in for loop just fine:
        for(int VLAInForLoop[dimension], i = 0; i < dimension; i++) {
            // ...
            // code apparently using VLAInForLoop
            // ...
        }
    }
    void funcTakingVLA(int size, int a[size])
    {
    }
        

  • Flexible array members (incomplete array struct members without bounds)

    #include <stdlib.h>
    struct flex {
        int mem; // Flex array must have a named member
        int arrayWoBoundsSpecified[]; // Flex member must be last member
    };
    struct NotAflex {
        int a[]; // Error: Flex member must be last member
                        // Therefore incomplete type should be complete
        int mem;
    };
    
    int main()
    {
       // "as if" len = offsetof(struct flex, arrayWoBoundsSpecified)
       size_t len = sizeof(struct flex); 
    
       // Flexible array members might be useful for reading record
       // from a comm line, or getting variable length information.
       //
       // The struct object "containing" with the flex array cannot be
       // longer than actual underlying object being accessed.
       //
       // These examples use malloc().  It shouldn't have to 
       // be limited to just that, but will be where it will be
       // used most
       //
       // (Do examples with DIs and CLs??)
    
       struct flex *p = malloc(len + 100);
       // This tends to product a dynamic type.
       // That is it is now "as if":
       // struct {
       //     int mem;
       //     // Assuming sizeof(int) is 2, then 100 / sizeof(int) is 50
       //     int arrayWoBoundsSpecified[50];
       // };
       p->arrayWoBoundsSpecified[49]; // ok
    
       struct flex *p2 = malloc(len + 80);
       // This is now "as if":
       // struct {
       //     int mem;
       //     // Assuming sizeof(int) is 2, then 80 / sizeof(int) is 40
       //     int arrayWoBoundsSpecified[40];
       // };
       p2->arrayWoBoundsSpecified[39]; // ok
    
       struct flex *p3 = malloc(len + 3);
       // This is now "as if":
       // struct {
       //     int mem;
       //     // Assuming sizeof(int) is 2, then 3 / sizeof(int) is 1
       //     int arrayWoBoundsSpecified[1];
       // };
       p3->arrayWoBoundsSpecified[0]; // ok
    
       struct flex *p4 = malloc(len + 1);
       // This is now "as if":
       // struct {
       //     int mem;
       //     // Assuming sizeof(int) is 2, then 1 / sizeof(int) is 0
       //     // The bounds therefore becomes 1
       //     int arrayWoBoundsSpecified[1];
       // };
       //  Even though the bounds became 1, these are undefined
       p4->arrayWoBoundsSpecified[0]; // undefined behavior
       int *pi = &p4->arrayWoBoundsSpecified[1]; // undefined behavior
    }
        

  • boolean type via _Bool and <stdbool.h>

    #include <stdio.h>
    int main()
    {
        // _Bool can hold 0 or 1
        // _Bool is an unsigned integer type
        _Bool b = 1;
        struct xyz {
             _Bool mem : 1; // _Bool bitfields allowed
        };
    
        printf("%d\n", b); // 1
        b = 0;
        printf("%d\n", b); // 0
    
        _Bool *pb = &b;
        // If the expression evaluates to 0, then it converts to _Bool as 0, else 1
        b = pb;
        printf("%d\n", b); // 1
        b = -1;
        printf("%d\n", b); // 1
        b = (pb == 0);
        printf("%d\n", b); // 0
        return 0;
    }
    
    // #define's bool, true, false, __bool_true_false_are_defined macros
    // as _Bool, 1, 0, and 1 respectively
    #include <stdbool.h>
    void foo()
    {
        int this = 99;
        int that = -99;
        bool b;
        if (this || that)
            b = true;
        else
            b = false;
    }
        

  • Static array parameters

    void foo(int array[static 99]);
        

  • __func__, indicates the name of the current function, as a static const char[?]

    #include <stdio.h>
    int main()
    {
        printf("%s\n", __func__); // output "main"
        return 0;
    }
        

    Because __func__ was uttered, then main is written by the compiler "as if":

    int main()
    {
        // This line implicitly added by the compiler:
        static const char __func__[] = "main";
        printf("%d\n", __func__);
    }
    

  • New keywords
    • restrict keyword (using restrict requires a C compiler which supports restrict, so our emitting restrict requires a custom port).
    • long long type, and unsigned long long
      • Support for ll, ull, LL, and ULL constant suffixes, with warnings on use of Ll or lL in strict mode. It available for your platform, it is assumed that the C compiler supports a %lld in the printf and scanf families.
    • inline keyword

      // SomeFile.c
      
      static int internalId = 99;
      
      // inline is a hint, not a requirement to honor.
      // An external definition has not been provided for foo
      // Other translation unit's don't find this definition
      inline void foo()
      {
          // External linkage inline function can't ref a modifiable static
          static int modifiable = 99; // Error
          // External linkage inline function can't reference internal linkage id's
          int i = internalId; // Error
      }
      extern inline void foo(); // ok, now an external definition provided
      
      static inline int bar() { return 99; } // ok
      inline int baz() { return 99; } // ok
      
      
      inline void NotDefined(); // Error: Needs to be defined in this translation unit
      
      int main()
      {
          /* May or may not use inline definition */
          foo();
          int i = baz(); // if inline'd, then "as if": int i = 99;
      }
            

  • For C99 __STDC_VERSION__ is 199901L instead of C95's 199409L
  • Support for STDC pragmas
    • Control whether "contracting" expressions are dis/allowed
      • #pragma STDC FP_CONTRACT ON
      • #pragma STDC FP_CONTRACT OFF
      • #pragma STDC FP_CONTRACT DEFAULT
    • Test floating point flags, etc.
      • #pragma STDC FENV_ACCESS ON
      • #pragma STDC FENV_ACCESS OFF
      • #pragma STDC FENV_ACCESS DEFAULT
    • Complex *, /, abs treatment of infinity, under/over/flow
      • #pragma STDC CX_LIMITED_RANGE ON
      • #pragma STDC CX_LIMITED_RANGE OFF
      • #pragma STDC CX_LIMITED_RANGE DEFAULT
  • Support for Variadic macros.

    #include <stdio.h>
    
    // In C89/90, you need multiple macros with "funny" names to do this.
    // Anyway, in this example, the arguments passed (those represented
    // by the ...) replace the __VA_ARGS__ when the substitution occurs.
    #define DoLogFile(...) fprintf(stderr, __VA_ARGS__)
    
    // Variadic macros also help out if you want to effectively
    // pass one argument  that contains commas
    #define MakeName(...)  #__VA_ARGS__
    
    // Of course, the macro can also take other args, so long as
    // the ... is last
    #define output(FILEptr, ...) fprintf(FILEptr, __VA_ARGS__)
    
    // This is not right, since this is NOT a variadic macro
    #define mac(arg) foo(arg, __VA_ARGS__)
    
    int main()
    {
        int bound = 99;
        int current_index = 88;
        int linenumber = 77;
    
        DoLogFile("Detected array out of bounds\n");
        DoLogFile("Bound = %d, current index =%d\n", bound, current_index);
        DoLogFile("Missing semicolon on line %d\n", linenumber);
        output(stderr, "Detected array out of bounds\n");
    
        char *p;
        p = MakeName(Mary);
        p = MakeName(Doe, John);
        p = MakeName(Martin Luther King, Jr.);
        // Combo two variadic macros
        DoLogFile("MakeName=%s\n", MakeName(This is a test, yes it is));
    }
        

  • Support for Complex and imaginary numbers, new floating types. Routines such as cacos(), etc., are expected to be implemented by the underlying C compiler.
    • _Complex float
    • _Complex double
    • _Complex long double
    • _Imaginary float
    • _Imaginary double
    • _Imaginary long double
    • __I__

    // _Complex and _Imaginary are not required in freestanding implementations
    int main()
    {
        _Complex double cd = -99.99; // imaginary part is zero
        // either order ok
        double _Complex cda[] = {
            cd, -cd, cd, 1.23 * __I__
        };
        double d = cda[1]; // imaginary part tossed
    
        _Imaginary double id = 99.99 * __I__;
        double x = id; // _Imaginary -> real --> 0
    }
    
    #include <complex.h>
    void foo()
    {
        double complex c = 1 + 2.3 * __I__; // 1.0+2.3i
    }
        

  • C++ style for loop initialization

    #include <stdio.h>
    int main()
    {
        for (register int i = 0; i < 99; i++)
    	printf("%d\n", i);
        i = 0; // Error: i no longer in scope
    }
        

  • Mixed declarations with code, ala C++ For examples, see some code samples above. The requires a C compiler which also support mixed decls with code.
  • Implicit return 0; from main(), respectively.
  • // style comments
  • So-called universal character names, aka UCNs, (e.g., \u0401) are accepted in identifiers, character literals, and string literals (they have always been accepted in comments because they have no special meaning there)
  • The va_copy() macro, for copying va_lists.
  • Hex floating point constants.
  • Etc.

Numerous additional Microsoft(r) compatibility features are also available in "Microsoft mode" of Comeau C++ 4.3.3. Supporting these features is important because it means that not only is Comeau C++ for Windows available for compiling Standard C++ while running under Windows, but also because it is now able to compile many MS-Windows specific apps. (Note that many of these features are not standard, but supported for MS-Windows source code compatibility. These features are only supported under our Windows port, in Microsoft mode. All of the MS-compatible features mentioned below may not be available in the generally available Windows port, and may require a custom port. As well, these features may be added to non-Windows ports through a custom port. Last but not least, note that there is no guarantee that Comeau C++ supports all MSVC++ features, or even that those we support are 100% compatible.) MS-VC++ features that we try to be compatible with include:

• A --microsoft option to specify "Microsoft mode". This is currently the default with Comeau C++ under MS-Windows. A --no_microsoft turns it off. Note too that --microsoft implies --microsoft_bugs mode which supports code which makes use of bugs in the VC++ compiler. The latter can be turned off with --no_microsoft_bugs, which then just supports VC++ extensions.
• A --microsoft_version option to specify the version of the Microsoft compiler than should be emulated, intended to match the Microsoft compiler's predefined macro _MSC_VER.
• Suffixes on integral constants, , like 15i32 including output of 64-bit constants as 1i64 and not as 1LL.
• So-called inheritance kinds: __virtual_inheritance, __single_inheritance, etc
• Support for Microsoft so-called zero-length arrays which are implicitly extern
• MS allows some conversions functions that should be ambiguous.
• MS allows a new call, on a member of a class, to change the type of the subobject to a derived class. In other words, it allows subobject types to be dynamic.
• MS allows = 0 pure specification on a pure virtual function at the same time as the definition of the function's body is specified.
• MS templates:
• MS treats some nontype template parameters of pointer type something like a reference to pointer type.
• extern template directive, an extension which suppresses instantiation, accepted with a warning.
• Support for Microsoft template function guiding declarations (instead of the explicit specialization syntax required).
• Support MS-style explicit specification of template arguments in specialization declaration which does not require template <> syntax.
• Support MS bug which ignores qualifiers when comparing class template argument lists.
• __uuidof is allowed on a template parameter, and a nontype template argument.
• MS allows redeclaration of template parameters (for instance, as a typedef)
• MS allows template parameters to be visible even in class specialization.
• MS allows some invalid template default arguments, including on function templates where they do not even serve a purpose, to be specified.
• MS allows the redeclaration of a template, with an incompatible template parameter list as the original had, w/o an error diagnostic.
• MS allows an explicit template instantiation directive to be used on an incomplete type.
• MS allows __declspec on the explicit specialization of a template.
• MS allows a member function template to be specialized within the class in which the member is declared.
• MS allows inline to be used as a function qualifier (as in like a const member function) but ignores it. We give a warning.
• When bool is a keyword in MS mode, then the macro __BOOL_DEFINED is predefined.
• MS considers bool to be a predeclared typedef, in global scope, rather than a keyword (and can be declared in other scopes as an identifier)
• MS allows a member of a friend to be literally qualified (C::foo), which may cause it to refer to an entity in namespace scope.
• MS expands a line splice (backslash) into a carriage-return, therefore, we must be able to process (and ignore) multiple (and not just one as previous) carriage returns before a newline too.
• MS allows calling conventions, such as __stdcall, to be specified on constructor declarations.
• MS allows a rather weird syntax in which the initializer for a scalar is specified with multiple brace-enclosed values.
• MS allows a static member function to override an inherited virtual member function.
• MS allows a function declared as __declspec(dllimport) to be defined as __declspec(dllexport).
• Class name injection now allowed in MS mode.
• MS allows incompatible extern "C" declarations in different namespaces.
• MS allows constant expressions of the form p->k where k is an enumerator of an enum of the respective class of *p.
• MS C allows a declaration to be redeclared yet differ in signedness.
• MS C allows parameter lists even in old-style function declarations (that is, even with no prototypes).
• MS allows string literals initializing arrays to be enclosed in parenthesis.
• MS still allows old-style concatenation macros in addition to the ## preprocessor operator.
• MS allows (and ignores) a -D or -U of a macro identifier that has an invalid name.
• MS supports forward declarations of enums
• MS does not look for user-defined conversions to pointer types for relational operators.
• size_t is now predeclared.
• MS allows the definition of a static member of a base class by using the derived class name in the qualification.
• An "array new" request using so-called placement syntax (...new(BLAH) T[xx]) will call the globally declared non-array placement new if a desired array new is not declared.
• MS allows a static member of type pointer-to-member to be redeclared to a different type upon its definition.
• __declspec, and similar MS declaration modifiers, now allowed in class declarations as well as definitions.
• New __declspec(selectany) and __declspec(nothrow)
• New __declspec(uuid("...")) and __uuidof(...)
• __declspec(dllimport) implies extern, and __declspec(dllexport)
• __declspec(property(...)) for nonstatic data members
• __declspec(allocate(...)) for variables of static storage duration
• __declspec(noreturn)
• __declspec(novtable) for attribute of class
• declspec modifiers also allowed on class template declarations.
• An unrecognized __declspec produces a warning.
• mutable in a declarator (and not just as a storage class).
• __based allowed in cast
• Calling conventions (__stdcall et al) can now be applied to a typedef
• Support for __forceinline accepted wherever inline is accepted.
• Support for __assume(expr) accepted wherever inline is accepted.
• __asm xxx instead of __asm("xxx")
• Comments in Microsoft asm statements are discarded.
• $ allowed in identifiers by default
• cv-qualifiers following a comma
• Branching into a Microsoft try block is now allowed in "bugs mode", with a warning.
• Implicit conversion between pointer and integral, with a warning.
• long to int conversion is considered a promotion as per MSVC++ 4.2 and 5.0.
• MS C allows an lvalue cast of a pointer to a integral of different size.
• MS C allows implicit conversion, with warning, of a pointer to a pointer of another type.
• MS C++ allows cast of pointer to integral type of smaller size is allowed, with warning
• MS C++ allows function parameters of pointer or reference to array of unknown bounds.
• MS C++ allows conversion of a pointer to a function to a void * and back again through a static_cast, all with warning.
• MS allows a friend declaration to be treated as a guiding declaration.
• #import, depending on the fact that the Microsoft compiler generates a header file (with a .TLH suffix) in the object directory when it processes an #import directive. We treat #import as a #include of the previously-generated file. The directory for such files can be specified via --import_dir.
• The idiom L#param is now accepted as requesting a wide string literal for the value of the indicated macro parameter.
• Implicit pointer conversions are allowed to drop const and volatile qualifications, with a warning.
• Local block extern function declarations can be declared as inline.
• (int)0 is not considered a null pointer constant
• Accept floating point constants which are too small.
• Accept type specifiers (inline, virtual, const, explicit) for union, class, struct, enum.
• A template class name is not injected into its own scope.
• explicit specializations allowed inside a class templates.
• The definition of a member of a class template many declare a nontype template parameter with a different type than the declaration.
• An unqualified friend class is looked up in the outer scope, not the innermost enclosing namespace scope.
• When emulating VC++ 6.0+ __int8, __int16, __int32 and __int64 are considered distinct built-in types. In other Microsoft modes, they are synonyms for the respective type.
• MS instantiates inline functions at the end of a translation unit, not when first referenced.
• Cast to abstract classes allowed.
• Use non-array new if no new[] matches, for VC++ 7.0.
• When MSVC++ is the backend C compiler, we output __int64 instead of long long. This may need to be enabled through a custom port.
• In C mode, only warn about incompatible function types, however give an error when return types differ.
• An empty __declspec is now allowed.
• MSVC++ 7.0 now allows "void returns" as per Standard C++, so when --microsoft_mode=1300 or higher, this is now allowed.
• Saying virtual virtual is now a warning not an error.
• Saying inline inline is now a warning not an error.
• const and/or volatile anonymous unions are now allowed.
• A constructor declaration may start with struct/class/union.
• An extern "C" name made visible with a using may be redeclared or redefined without qualification.
• MS's non-standard anonymous unions allow named nested types (not intro'd with a typedef) as an extension.
• throw(...) to indicate that a function may thrown any exception
• __FUNCTION__, indicates the name of the current function, as a const char[?], just like C99's __func__
• __FUNCDNAME__, indicates the mangled name of the current function
• __declspec now allowed on enum definitions
• Missing parens in a pragma pack are now diagnosed with warnings.
• Warn about invalid pragma pack values.
• Warn about extern or static used on parameter declarations.
• Mimic uuid template behavior where uuid of __uuidof(A<B>) is B not A.
• Warn when .*ing or ->*ing a call of a non-const member function on a const object.
• __forceinline and __inline accepted on explicit template specializations or explicitly template instantiations.
• Warn about using a member function template or a member function of a template class that is explicitly specialized after it has been used.
• Support for #@, MS's "char'izing" macro operator
• Etc.