[pooma-dev] [RFC] Removing workarounds for pre-ISO C++ compilers

[Richard Guenther]

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 testresults for them.  A 
document describing our preffered 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.