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

[Andy D. <dou...@la...>]

On Sun, 16 Feb 2003, Jonathan Brandmeyer wrote:

> 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.

Only sort of.  On Intel systems, g++-3.0 is not included in a standard
Woody installation.  On SPARC systems, it's not even an option.  I haven't
checked the other architectures.  The standard compiler is g++-2.95.  
(gcc-3.0 is listed as 'standard' for Intel, but it's the g++ compiler
that's relevant here, and that's listed as 'optional' for Intel.)

>                                                  On my Woody system,
> iterator traits are available when compiled with gcc-3.0. 

That's because g++-3.0 has a dependency on the libstdc++-3.0-dev package,
which is where the iterator.h header is.  The standard Woody system
without g++-3.0 has the older libstdc++-2.0, which is the one without
std::iterator<>.

In short, a standard Woody system system probably needs
std::random_access_iterator, while a newer system needs std::iterator.

> 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).

They are a function of compiler version + library version, not just
compiler version alone.  Fortunately for the end user, a good dependency
system, such as Debian's, tends to hide such details, but it does make it
harder for the developer to pin things down.

> > 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. 

No, I had it right.  Quoting from the 2002-07-22 VPython distribution,
cvisual/CXX/Include/CXX_Config.h (wrapping long lines for clarity):

#if STANDARD_LIBRARY_HAS_ITERATOR_TRAITS
#  define random_access_iterator_parent(itemtype) \
	STD::random_access_iterator<itemtype, int>
#else
#  define random_access_iterator_parent(itemtype) \
	STD::iterator<STD::random_access_iterator_tag,itemtype,int>
#endif

I'd agree with you that the name, in retrospect, probably seems backwards
and is easily confusing, but my suggested patch did exactly what I wanted
it to do, namely change the default value of the
STANDARD_LIBRARY_ITERATOR_TRAITS #define to match the current standard.
I also changed the error message in cvisual/CXX/README.htm to match that
new default value.

In short, my patch will cause compilation to fail on a standard Debian
"Woody" system without g++-3.0 (and also on RedHat 7.0), but it should
also allow compilation to succeed without this particular problem on newer
standard-conforming systems.  The failure message in the patched
README.htm advises users how to work around the compilation failure.

> 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.

Yes.  My patch just suggested toggling the default to work with newer
systems by default, and changing the documentation to match.  Sorry if my
original message was too brief to indicate I had already thought about
your valid points.

-- 
    Andy Dougherty		dou...@la...
    Dept. of Physics
    Lafayette College, Easton PA 18042