DEFECTS MECHANISM ----------------- A proposal for unified handling of deviations from c++ standard compliance, and differences in standard libraries and header file organization. PROPOSAL SUMMARY: To develop a package to standardize C++ library and language feature access across multiple platform/compiler combinations. The goal is to let users develop in standard C++, and to take care of all the platform and compiler idiosyncrasies via a single unified scheme. The proposal is detailed below. What is urgent is a response from the steering committee about the go-ahead to do this. WHAT WE NEED FROM THE RUN II STEERING COMMITTEE: There is general agreement among CDF and D0 people, the C++ working group, and ZOOM people on the approach and most technical features of the proposed solution. However, doing this will not be resource-free. What is needed from the Run II committee quickly is a strong "go-ahead" specifying: * That the proposal as outlined below is acceptable. * Who will do this. The C++ working group is in agreement that the proposed scheme will require somebody to keep things organized, define the defects, create and collect platform-specific clean workarounds, and organized some form of automated checking for known possible defects. If an existing person with Run II duties is designated, the committee should also specify which present duties are to be delayed until after the mechanism is in place. * Preliminary estimates of the effort required are in the 6-10 person-week range. Of this, at least half needs to be done as soon as possible. The go-ahead and designation needs to be in hand by January 20 so that the basic mechanism and most accommodations on most platforms might be in place by the end of February or early March. CDF has a major milestone release planned around May, by which time all parts of the off-line reconstruction system (and most Level-3 trigger software) and associated infrastructure are expected to be in place and functional. If we are to accommodate some level of compliance with the standard, and require specific small accommodations on the users' part, these must be in place by the time that substantial coding effort commences. Moreover, the lack of a unified scheme is being felt in terms of extra work for the experiments and ZOOM, and extraneous complications for the already difficult SRT efforts. If this proposal is not given the go-ahead, or the designation of manpower to implement it is delayed, the consequences in terms of trying to provide cross-platform comparability would be severe. For example, the prospects of people using the native SKI compiler with standard code written for Run II would become very long-term at best. And if the defects mechanism is not in place, ZOOM will have great difficulty continuing to support NT without doing much of the work that the proposed scheme would involve. PROPOSAL BACKGROUND and RATIONALE: This proposal originates from a preliminary assessment of the work required to make the existing CDF/Zoom C++ code base compile and operate satisfactorily with the SGI CC-7.2.1a compiler under IRIX6.5. In short, we wished to port our code to a new environment, a task highly likely to be performed again and again as our operating systems and compilers evolve. While numerous Fermilab developers have recognized this problem for some time, past mitigation efforts have been developed in a decentralized fashion, employing several philosophically-distinct and technically-overlapping methods. For example, CDF initially developed the "DEFECT macro" approach. Zoom has produced a "ZMutility" package, and has recently adapted a BaBar package, "STLUtility." Other developers have still other favorites. We also note that the C++ Working Group has developed an automated test suite to identify common defects. While all this has led to some duplication of effort, it is a far greater burden that the approaches are not at all well-integrated, and so each of the techniques requires significant independent attention when it comes time to port, or at any other time a new defect is identified. Finally, it is important to assure that all the approaches can smoothly co-exist and do not interfere with each other, since client code can easily incorporate library code from distinct sources and so inherit two or more of these approaches. However, none of the current efforts has proven entirely satisfactory. We recognize certain inadequacies in all the current approaches that will require both development and maintenance efforts in the near future. For example, as C++ compilers move closer to the standard, existing measures prove to be insufficiently finely-grained. In addition, we generally prefer less-intrusive methods of handling compiler defects than some of the current approaches advocate. Thus, it has become apparent that the effort needed to write, maintain, and port C++ code suitable for use in many different platform/compiler combinations could be substantially reduced. GENERAL PROPOSAL: In order to address Fermilab's need for multi-environment production C++ code, we propose to produce and promote a Fermilab-standard methodology to deal with C++ compilers that fail to comply with the language standard, and with other, related, defects in the development and operating environments. In particular, we propose to consolidate the best features of several of the approaches outlined above into a new package, tentatively named the "Defects package." The main goal of the new package is to allow developers at all levels of activity to program in a way as close to standard C++ as possible with a minimum of intrusion into user code. In addition, this package is intended to work both within and without the SoftRelTools framework. SELECTED DETAILS: 1. We will adopt the concept of DEFECT macros, but intend to phase out the current definitions in favor of a more finely-grained set of definitions. 2. We intend to provide, for each mandated environment, one file containing a sequence of all DEFECT #defines applicable to that environment. These files will be named DEFECTS_FOR_. 3. Either SoftRelTools (automatically) or the user (manually) will provide, at compile time, a preprocessor symbol defining the compilation environment. We envision the defined value of this symbol to be based upon the current value of BFARCH. Developers' code will have a line such as: #include In turn, Fermilab.hh will load the applicable set of DEFECT #defines from the DEFECTS_FOR_ file whose is based upon the macro derived from BFARCH. 4. To alleviate the numerous compiler defects dealing with the standard C++ library, we will extend the functionality of the ZMutility and STLUtility packages by providing DEFECT-aware headers as replacements for all parts of the standard C++ library, including the forward declaration headers. Developers' code will #include our headers in place of the standard library headers and will thus be insulated from such issues as versus , ios:: versus ios_base::, the stringstreams issues, and the like. Our headers will match the names of the standard headers, possibly with a directory or other symbol as a prefix to disambiguate. 5. To mitigate absent or defective compiler support for C++ features (e.g., namespaces), we will maintain and extend the support now provided by the ZMutility package in the form of language-feature macros [such as ZM_USING(...) as a compiler-insensitive version of using declarations]. Developers will need to use our macros as consistent replacements for the language features they are designed to supplant. While such measures are somewhat intrusive, past experience suggests they will be only infrequently needed. 6. We do not believe that we can mitigate all possible compiler defects. However, we do believe that we can at least make developers aware of possible erroneous behavior. For example, several compilers do not support covariant return types; ZMutility includes a macro that, if consistently used, will at least allow such code to compile consistently and give correct behavior in a substantial percentage of the time. 7. The sum of the above details shield developers from putting in large conditional blocks, and from the terrible time sink of having to retro-fit code due to (a) a compiler becoming closer to the C++ standard in some unforeseen way, or (b) porting to a new environment. For example, using the current DEFECT macro system, one would do: #ifdef DEFECT_NO_IOSFWD_HEADER class ostream; #else #include #ifndef DEFECT_NO_NAMESPACES #ifndef DEFECT_NO_IOSTREAM_NAMESPACES using std::ostream; #endif #endif #endif All this would be replaced by: #include "Portability/portability.h" #include "Portability/iosfwd" ZM_USING( NS_IOSTREAM::ostream ); That last line would ideally be the more standard using std::ostream; however the ZM_USING macro would likely be necessary because it is hard to cope with compilers that don't understand namespaces without it. The substitution of NS_IOSTREAM:: for std:: in the case of streams might or might not be necessary; when workarounds for each platform are examined, we would try to come as close to the standard as possible.