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

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

You can read the comments in CVS here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/visualpython/
in cvisual/CXX/Include/
and /cvisual/CHANGELOG.

I will update the documentation comment, too.

-Jonathan

----- Original Message -----
From: "Andy Dougherty" <...>
To: "Jonathan Brandmeyer" <...>
Sent: Friday, February 14, 2003 8:44 AM
Subject: Re: [Visualpython-users] Re: compiling vpython with gcc 3.2 (linux)


> On Fri, 14 Feb 2003, Jonathan Brandmeyer wrote:
>
> > It's fixed in CVS as of last night.
>
> Do you mean the CXX_Config.h comment is updated, or you've changed the
> default value of the STANDARD_LIBRARY_HAS_ITERATOR_TRAITS #define?
>
> --
>     Andy Dougherty dou...@la...
>     Dept. of Physics
>     Lafayette College, Easton PA 18042
>
>
>

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

    #if 0
    using __STD::iterator;
    #endif

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
 
 #ifdef MS_WIN32
 #undef STANDARD_LIBRARY_HAS_ITERATOR_TRAITS
diff -r -u VPython/cvisual/CXX/README.htm VPython-andy/cvisual/CXX/README.htm
--- VPython/cvisual/CXX/README.htm	Mon Jul 22 16:03:01 2002
+++ VPython-andy/cvisual/CXX/README.htm	Fri Feb 14 15:41:30 2003
@@ -13,6 +13,19 @@
 set the environment variables LINKCC to 'g++' and LDSHARED to 'g++ -shared'
 or whatever is appropriate for your C++ compiler.
 <h2>
+std iterator problems</h2>
+<p>
+Cvisual uses std::iterator from the standard library.  
+If you encounter error messages such as
+<pre>no class template named `iterator' in `std'</pre>
+then edit Include/CXX_Config.h and change
+<pre>#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 0</pre> to
+<pre>#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 1</pre>.
+This will cause cvisual to use random_access_iterator instead.
+This was present in early draft C++ standards, and is implemented in
+the C++ libraries in a number of Linux distributions, including RedHat
+7.0 and Debian 3.0.
+<h2>
 Version 4 (February, 2000)</h2>
 CXX compiles with gcc - 2.95. Includes new version of extension portion
 by Barry Scott.&nbsp; I have personally only tested this on RH Linux 6.&nbsp;

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

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 

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

> 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