Jeffrey D. Oldham wrote:
Richard Guenther wrote:
Jeffrey D. Oldham wrote:
There are still a lot of gcc 2.95 and related compilers in use
today. I prefer to leave them but let them rot unless there is a
compelling reason to remove them now.
I see. I'd remove them only to unclutter the source and maybe
increase maintainability if formally stating we require an ISO
conformant compiler. Oh - we do so already:
<quote README>
This version incorporates other minor source code changes to support
compilation using g++ version 3.1 and some improvements to POOMA
Fields. Compilation using g++ version 2.96 is no longer supported.
g++ version 3.1 is freely available at http://gcc.gnu.org/. POOMA has
also been tested using KAI C++ 4.0e.
</quote>
Richard.
Good point. Support for gcc 3.4 differs from support for gcc 3.x.y, x
< 4, because 3.4 will correctly parse some constructs that gcc 3.x.y
does not. What do you prefer we write in the README for a Pooma 2.5
release? That should drive our code changes.
I think we should state that we require a ISO standard conforming
compiler and standard library. But we should restrict ourselves to
using those parts of the standard that are supported by all recent
compilers (gcc 3.3, Intel 7.2). I.e. we don't use template template
parameters.
But working around missing std::min/max or std::complex. Requiring to
code like Utilities/Algorithms.h:
template <class DataIterator, class KillIterator>
inline
#if POOMA_NONSTANDARD_ITERATOR
typename std::iterator_traits<DataIterator>::distance_type
#else
typename std::iterator_traits<DataIterator>::difference_type
#endif
delete_backfill(DataIterator data_begin, DataIterator data_end,
const KillIterator kill_begin, const KillIterator kill_end,
#if POOMA_NONSTANDARD_ITERATOR
typename std::iterator_traits<DataIterator>::distance_type offset = 0)
#else
typename std::iterator_traits<DataIterator>::difference_type offset = 0)
#endif
{
...
doesn't help maintainability either.
Work on VSIPL++ demonstrates that some templated C++ code that gcc 3.4
easily supports still breaks other compilers. For example, IBM Visual
Age 6 (xlc++) can have difficulty parsing with template arguments.
Intel C++ 8.0 for IA64, which I believe is the descendant of KAI C++,
has trouble with template functions defined outside template classes.
I think we should identify a set of compilers we can test compatibility
with ourselves and formally state we require ISO conformance. We then
can list a set of tested compilers along with test results for them. A
document describing our preferred coding style along with usable
language subset would be greatly appreciated, too.
I can start a coding style / conformance document and produce an initial
readme for an upcoming release if you like.
Richard.