Re: [boost] Proposal for standard header fixes (was IRIX)

From: wb_at_[hidden]
Date: 2000-12-15 19:12:26

John Maddock <John_Maddock_at_[hidden]> wrote on Fri Dec 15 06:30:32 2000:

| As well as the perennial problem of a missing <limits> there are problems
| appearing with non-standard (old style) iostreams, and missing <cheader>
| files, as a starting suggestion how about the following workaround:
<details snipped>

This proposal is along the lines of a project I have previously
mentioned on this list:  ISOcxx, also known as the C++ "portability"
project.

From the Introduction section of the ISOcxx documentation:

  "ISOcxx is a softare package to incorporate fixes to C++ development
  platforms to account for environments that do not comply with the ISO
  C++ language and library standard....

  "Each C++ language or library feature that is not compliant is known
  as a defect....

  "In this package, each defect is defined by one or more test programs
  that demonstrate a specific area of non-compliance.  To the extent
  possible, each such defect (or group of defects) is accompanied by
  compliance code, additional software that addresses the defect and
  attempts to cure (remedy or ameliorate) some or all of its
  consequences....

  "The intent of the package is to permit client code to be written in
  such a manner as to be maximally compliant with the international C++
  standard, yet still be acceptable in as many defective environments
  as possble."

I am writing at this time because it has become very clear that lots of
us have been and are continuing to reinvent, in an ad hoc fashion,
solutions to the problems caused by defective C++ environments.  Each
of SGI, STLport, Blitz++, boost, etc., as well as ISOcxx, has more or
less independently come up with the notion of preprocessor symbols
defining compiler features/defects, for example.

To my knowledge, only ISOcxx supplies test programs and a protocol for
probing and dynamically configuring an environment according to its
response to actual attempted compilations of the various test programs,
together with a repository of workarounds ("cures").  This, of course,
is a one-time job per environment; however, we have found the automated
configuration of the package to be its most attractive feature.

I have today made available, with my supervisor's permission, a version
of ISOcxx for general inspection by boost subscribers.  Please note
that, in its present form, a particular local build environment (known
as SoftRelTools, for historical reasons) is assumed in the supplied
makefile.

The URL for this version of ISOcxx is
    http://www-pat.fnal.gov/personal/wb/boost/ISOcxx/

We have emphasized, to date, the environments on platforms that we use
most heavily.  These include various versions of the KAI compiler and
of gcc 2.95.2 under various releases of Linux, IRIX, SunOS, and
Cygwin/Windows/NT, as well as VC++6 with various of its service packs.
Adding a new compiler/platform combination is also a one-time job; it
takes anywhere from 1/2 day to 1/2 week, depending mostly on
familiarity with the new compiler/platform.

While I would be happy to arrange for a formal contribution of this
package to boost, if there is interest, I believe the model that ISOcxx
demonstrates is its greatest asset.  Ad-hoc, decentralized, workarounds
ought, we feel, to be actively discouraged in favor of some centralized
mechanism for detecting defects and an accompanying repository of cures
for these defects.

We have been following this model for almost two years now, and have
found it to be a maintenance blessing.  While not perfect, we have been
able to factor a very substantial percentage of defect-handling code
out of our users' code, and into ISOcxx.  After initial implementation,
maintenance has been minimal, and consists largely of updating ISOcxx
with new tests and cures as new defects are reported.  Along the way,
we have a regression suite (for free!) to look at the behavior of new
releases for supported compilers.

There are some idiocyncracies with respect to our workplace, and some
names have historic significance, but overall I am very comfortable in
inviting the boost community to have a look.

Please feel free to correspond with me directly about details, if you
would like to reduce the boost mailing list traffic.

Best wishes of the season,

        - WEB