Re: [Visualpython-users] Re: compiling vpython with gcc 3.2 (linux)

[Jonathan B. <jbr...@ea...>]

On Fri, 2003-02-14 at 15:43, Andy Dougherty wrote: 
> On Fri, 14 Feb 2003, Jonathan Brandmeyer wrote:
> 
> > The option to inherit Py::SeqBase::iterator from
> > std::random_access_iterator<> has been removed, now it inherits from
> > std::iterator<>.  STANDARD_LIBRARY_ITERATOR_TRAITS is no longer needed, and
> > has been removed.  This should comply with the standard, and has been tested
> > with g++ 3.2.1
> 
> I was afraid that's what you meant :-(.  I don't think it will work with
> somewhat older systems.  For example, in both Debian 3.0 ("woody") and
> RedHat 7.0 systems the 'std::iterator<>' stuff in
> /usr/include/g++-3/iterator.h is surrounded by
Woody includes gcc 3.0.4 in addition to 2.95.4.  On my Woody system,
iterator traits are available when compiled with gcc-3.0.  ABI
differences between compiler versions seem to be glossed-over by using
extern C {} functions to reveal cvisualmodule.so to the interpreter. 

Iterator traits' availability has been tested with gcc-3.0.4, 3.2.1, and
MSVC6.  Indirect reports show that iterator traits are available under
CodeWarrier7, and gcc-2.95 (Apple special). 
 
> I think a better "fix" would be to leave the comment and #define in
> CXX_Config.h, but change the default value of the
> STANDARD_LIBRARY_ITERATOR_TRAITS #define to match the current standard.
> 
> Specifically, I had in mind something like this:
> 
> diff -r -u VPython/cvisual/CXX/Include/CXX_Config.h VPython-andy/cvisual/CXX/Include/CXX_Config.h
> --- VPython/cvisual/CXX/Include/CXX_Config.h	Mon Jul 22 16:03:01 2002
> +++ VPython-andy/cvisual/CXX/Include/CXX_Config.h	Thu Feb 13 15:52:02 2003
> @@ -2,7 +2,7 @@
>  #define __py_config_hh__
>  // Macros to deal with deficiencies in compilers
>  #define COMPILER_SUPPORTS_NAMESPACES 1
> -#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 1
> +#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 0
Backwards.  STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 1 is the ISO-compliant
answer.  Otherwise, the header will cause inheritance from
std::random_access_iterator. 

So long as it does not continue to cause problems on the ISO-comliant
compilers, I think we can keep the macro as an available option.  I
thought about using __GNUC__ < 3 as an identifier for non-compliance,
except that an older Mac GCC was a 2.95 build that supported iterator
traits.  It is currently much harder to determine which compilers are
not in compliance than those which are. Therefore, I plan to not add any
automatic detection, and let the user manually flip the value if
absolutely required (ex. RH 7). 

Alternatively, I would prefer to use an autoconf test for the job.  It
is an area I have marked for research, and a contributed configure.in
would be gratefully accepted.  Using ./configure && make is an
intermediate-term goal that the team is persuing for source
distributions. 

-Jonathan