C++ Compiler Standards and Sanctioning

• Compiler Features Required
• Debugger Features Required

There will be a mechanism for this set of required features to slowly evolve as compilers more nearly apprach the ANSI standard, and/or if the draft standard evolves in important ways.

There must also be an available debugger meeting certain standards. Many debuggers with or without graphical front end enhancements will substantially exceed these requirements, improving the desirability of the compiler; but for the purposes of deciding whether to avoid a compiler in the Fermilab environment, only this minimal functionallity matters.

Comments on the contents of this page are solicited, for distribution to the working group.

View the collected comments.

Send a comment.

Compiler Features Required

The compiler features are based on the following considerations:

• Portability: people writing for a sanctioned platform/compiler can safely assume their code will work on all the santioned compilers.
• Standards: users adhering to these features should not be coding in a different way that the world in general, due to differences between the sanctioned feature set and standards in broad use.
• Practical Considerations: there may be instances where a standard or draft standard exists but too few compilers support some esoteric or new features at this time to include those features in our requirements.
• Stability: modulo the above considerations, it is preferable to have our requirements change as infrequently as possible, so users can become familiar with them and not have to keep up with lots of changes.

Based on these considerations, the following compiler sanctioning features and rules for evolution are presented. Note that this scheme involves two stages of additions to requirements, bringing the final requirements up to full ANSI C++ compliance.

• After the C++ Working Group of the Run2 computing committee disbands, CD/CDF/D0 will designate an arbiter of compiler sanctioning and continuing compiler standards evolution. This may be a designated person or small group; if it is a single person provsion should be made for calling on technical help in applying validation criteria to changed compilers.
• At the time the C++ Working Group disbands,
  the compiler standards will consist of support for the C++ features recommended for interim use.
  (The document of that title is available now.)
• The most important compromise in that interim document concerned namespace.
  When in the judgement of the standards arbiter enough compilers support namespace, then
  a new definition of needed features, including namespace and based on the ANSI draft standard and commonly available features at that time, will be issued.
  
• When the draft becomes an ANSI STANDARD for C++ the arbiter will set a date, based on practical lab considerations, at which time
  the ASNI C++ standard will be adopted as our standard. This will be about 3-6 months from ANSI standard acceptance; most compilers will be up to date by then (since the standard will not have evolved for quite a while). At that point,
  the set of required features for a sanctioned compiler will coincide with the ANSI standard for C++,
  and this should remain stable for quite a while.
• Along with requiring the ANSI standard features, we will require that there be some flag or way to cause the compiler to reject non-standard extensions (such as >?). By demanding adherence to the strict non-extended standard, the user can produce code which should work on all the sanctioned compilers/platforms.
• Note that the mere presence of a few minor bugs should not, per se, exclude a compiler (though massive bugginess would!). Users will be encouraged to submit copies of bug reports to the arbiter, so that warnings about specifics and/or general problems may be issued to the community.

Debugger Features Required

To be sanctioned and supported for use in Run 2 development, a particular compiler/platform combination must support a debugger meeting certain standards. We don't anticipate many modern compilers not meeting this requirement; but this list will tell people what sorts of operations they can safely become dependant upon.

Note that nothing is said about how each capability is to be invoked. In fact, different debuggers will have different interfaces and we will not try to standardize on a particular one. When we say some capability is present, we do require that it can be used without unduly awkward operations on the part of the user.

Also, it is conceivable that a compiler will be acceptable because a combination of two debuggers gives all the needed features. For example, debugger A may do everything except understand a dump format, which can be looked at by debugger B. Again, we require that each of those be reasonable to use.

In listing these requirements, a debugger was pictured as having a graphical or windowing front end. For example, the ddd debugger appears to meet these standards, as to the Borland and Microsoft debuggers. In principle, a single-window text-based debugger could also satisfy these requirements (though it is hard to see how in some cases). Availbility of a text-based, command-line-based mode, (which could be run on a VT100, for example) may be a desirable option, even if this mode does not support all the standard features. But this is not a requirement imposed on every sanctioned compiler.

The debugger must have the following properties and convenient support features:

1. It must be based on the C++ source:
   • allowing the user to see where in the source the program is up to
   • properly handling includes
   • coping with instances where the source of some portion is unavailable
   • coping with cases where some portions were written in Fortran or another non-C++ language (it is not required that the "foreign" source be displayed by the debugger)
2. Knowledge of the compiler's naming (and "name-mangling") conventions, so that the user need not enter names beyond the names seen in the source.
3. It must deal well with classes and inheritance, exploding is-a, has-a and defined-within (inheritance, aggregation and sub-class) relationships appropriately.
4. Show and show-always on variables and structures. Examination of variables must not rely on the user typing invoved formatting strings (e.g. print "%d" myvar).
5. Watch (show and break when it changes) on multiple variables.
6. Deposit into variables and structures.
7. Break points and conditional break points at:
   • Function name (entrance to function)
   • Line number or line number in some file
8. Single step, both into and over functions.
9. Assembler-level capability: view and step through code at assembler level; examine registers and ranges of absolute (virtual) addresses.
10. goto (run starting from) and function call capability from the debugger.
11. Examine arrays of arbitrary size and individual elements of arrays and classes/structures.
12. Properly accept and handle command line arguments, environment variables, and piped and standard input.
13. Deal with signals in a meaningful way, providing options beyond merely always ignoring or always aborting on a particular signal.
14. Examination of dump or core files if those are produced by the system when programs die. However, a sanctioned compiler/debugger combination on a platform which does not provide dumps will not be declared obsolete or non-sanctioned merely because a new release of the system now provides dumps which the debugger doesn't deal with yet.

This page was written by Mark Fischler.