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

[Richard Guenther]

Jeffrey D. Oldham wrote:
> Richard Guenther wrote:
> 
>> 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.
> 
> 
> Yes, I think this is a good approach, but it's probably sufficient for 
> now to write one or two paragraphs in the README file describing 
> compilation requirements.  Compilation and conformance is probably more 
> important and easier to write and more useful to user than a coding 
> style document so I would prefer to put our energies into the former if 
> we do not have energy for both.
> 
> gcc 3.3 and gcc 3.4 differ significantly in parsing because 3.3 uses an 
> LALR-based parser while 3.4 uses recursive descent.  The difference is 
> more than just template-template parameters.  Despite this, I think we 
> should support gcc 3.2 or 3.3 if we can.
> 
> The amount of testing is non-trivial since we have several variables:
> 
> serial v. distributed
>   distributed: MPI-only, Cheetah+MPI, Cheetah+MM
> various compilers
> 
> I would prefer to keep the compiler list relatively short and containing 
> the most popular compliant compilers.
> 
> Would you be willing to start modifying the README file for a release?

Yes, I can start writing up something along with removing notes for 
releases preceding 2.4 - the information therein is somewhat misleading 
now (maybe we can rotate the README file into docs/README-2.3).

Richard.