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

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

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

My exposure to the STL has mostly included libstdc++, whose releases
have been coupled to g++, but I understand the difference.  This
particualar feature required support from the compiler for partial
template specialization.  In each of the cases that I mentioned, I was
referring to the compiler + library combination that was shipped from
the compiler vendor.

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

I apologize, see below.

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

The name was exactly backwards and was confusing.  When I put the flag
back in, I named it STL_HAS_ITERATOR_TRAITS, and implemented it with the
right meaning.

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

Yes, exactly.

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

I think that we have ended up saying the same thing.  Take a look at
what I imported over the weekend.  I think you will see that the
behavior is as you suggested, and the flag defauts to true for
ISO-compliant compilers.

-Jonathan