Comeau Computing Home

Bursting With So Much Language Support It Hurts!
Comeau C/C++TM 4.3.3 Compiler Front-End!
Your Cross Platform C++ and C Compiler Solution Based On The Language Clauses Of ANSI/ISO Standard C++ and Standard C
NOW -- 4.3.3 Available For Windows, LINUX, SunOS and Online
Now With C99 Language Support!!
Check Out libcomoTM!

export implementation released!
Comeau C/C++:
 4.3.3 Upgrade Form
 Test Comeau C/C++ Online!!
 Online Documentation
 Minor patch information
 License Agreement
 About Comeau C/C++
 Custom Ports
 General C/C++ Issues
 Comeau Training Courses

Order worksheets:

C++ Committee:
 Meeting updates
 Committee "Issues Lists"
 Standard C++ Press release
 How to obtain Standard C++

CCsh, UNIX Shell Compiler:
 CCsh literature
 CCsh Documentation
 License Agreement

 Contacting Us
 Thoughts from Greg Comeau
 LINKS to C++ sites
 C and C++ Tech Talk
 Comeau Templates FAQ
 Comeau C99 FAQ
 Book authors
 Change your Email path

* * * 4.3.3 Features * * *

Comeau C/C++ 4.3.3 includes a number of new features and enhancements in addition to the wide span of Standard C++ and Standard C features that we already support. Comeau C/C++ 4.3.3 continues our serious tracking of all the ANSI/ISO C++ committee and ANSI/ISO C committee deliberations to date. These additions bring us, yet again, past compliance language-wise, as we now support C++03, and then some.

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!

Bursting With So Much Language Support It Hurts!

What's new in Comeau C/C++ 4.3.3?

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.

Bursting With So Much Language Support It Hurts!

What features were already available in Comeau C/C++?

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 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:
  • 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.

Bursting With So Much Language Support It Hurts!

What features still need to be added to Comeau C/C++?

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!
The only major or minor C or C++ language features of substance missing include: Although not a C or C++ feature, Comeau C/C++ does not generate multi-threading aware code, although you can surely write code or use functions/classes that implement such things.
Bursting With So Much Language Support It Hurts!

What C99 features does Comeau C/C++ support?

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:

Bursting With So Much Language Support It Hurts!

What MSVC++ features does Comeau C/C++ support?

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 ( 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.
/* the end, for now :) */

[ Home | About Us | Contact Us | Comeau C++ Documentation | C++ Committee | C++ Resources ]

(c) © 1992-2013 Comeau Computing. All Rights Reserved.
Comments and issues about the Comeau Web site should be addressed to here
Last updated July, 2013. Thanks, and come back soon!
C++ parsing; C++ syntax analysis; C parsing; C syntax analysis; EDG; C++ to C translation; Convert from C++ to C; Translate C++ to C; C++ to C tool; hand conversion; cfront replacement; AT&T; Standard C++; near compliant C++; standard conforming; ANSI; ISO; embedded systems; multi-platform; cross-platform; cross-compiler; portable compiler; target platform; templates; C++ resources; C++ links; UNIX compiler; DSP compiler; savvy; track record; free technical support; free compiler upgrade; 8-bit; 16-bit; 32-bit; 64-bit; 128-bit; VC++; MSVC++; commercial; inexpensive; free; PD; public domain; C++ information; Commeau; Comeaus; Comeaux; Commeaux