[C++-sig] Re: method_call_expr not supported by dump_expr
Ralf W. Grosse-Kunstleve
rwgk at yahoo.com
Fri May 23 21:04:47 CEST 2003
--- David Abrahams <dave at boost-consulting.com> wrote:
> I doubt it. Everything interesting happens in evaluating the sizeof
> expression. If they're not having problems now, they're not likely
> to start.
>
> > , while Romain's fix is
> > minimally intrusive and does not change the code seen by compilers other
> than
> > gcc 3.3.
> > Your choice: adventurous or conservative?
>
> adventurous.
Ay-ay, sir!
I am already in trouble, so I backed up:
- checked out current boost CVS (~1 hour ago)
- compiled my scitbx with default Redhat 8 gcc 3.2: no problems
- trying to compile with gcc 3.3 under Redhat 8 after completely disabling the
assertion at line 28 of as_to_python_function.hpp. Here is the full
stlfilt'ered error message:
http://cci.lbl.gov/~rwgk/tmp/gcc33_linux_flex_scitbx_ext_error
The file being compiled is here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/array_family/boost_python/flex_scitbx_ext.cpp?rev=1.7&content-type=text/vnd.viewcvs-markup
The error message ends with:
boost::python::optional<
const
double &, boost::mpl::void_, boost::mpl::void_, ... boost::mpl::void_>
>::sequence2' is private
I remember that this worked before you checked in the fairly massive set of
fixes a couple of days ago. Did something nasty creep in?
Ralf
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
More information about the Cplusplus-sig
mailing list