Re: [Boost-bugs] [Boost C++ Libraries] #2069: #elif behaviour in gcc 4.4 (was: compile mpl with gcc-4.4)

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #2069: #elif behaviour in gcc 4.4 (was: compile mpl with gcc-4.4)
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2008-08-20 19:53:33

#2069: #elif behaviour in gcc 4.4
---------------------------------------------+------------------------------
  Reporter:  tim blechmann <tim_at_[hidden]>  |       Owner:  no-maintainer
      Type:  Bugs                            |      Status:  new          
 Milestone:  Boost 1.37.0                    |   Component:  preprocessor 
   Version:  Boost 1.35.0                    |    Severity:  Problem      
Resolution:                                  |    Keywords:               
---------------------------------------------+------------------------------
Changes (by danieljames):

  * owner:  agurtovoy => no-maintainer
  * component:  mpl => preprocessor

Comment:

 The following is copied from:
 http://lists.boost.org/Archives/boost/2008/07/139765.php


 A recent change to the development version of the gcc preprocessor
 changes the way it processes '#elif' directives and breaks a common
 use of the preprocessor library. We've already had reports of this
 causing problems in MPL, and it might also affect: variant,
 function_types, python, fusion, xpressive and phoenix. Details of the
 change are at:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36320


 With this change, the argument to an '#elif' directive is processed
 even if a previous '#if'/'#elif' directive was true. This causes the
 example use of BOOST_PP_ITERATION_DEPTH to break:

 http://www.boost.org/doc/libs/1_35_0/libs/preprocessor/doc/ref/iteration_depth.html


 In this example, the first time the header is included,
 BOOST_PP_ITERATION_DEPTH is not yet defined, so it causes the
 develoment gcc to fail when the #elif directives are evaluated (which
 are skipped with existing versions, because the first #if directive
 evaluates to true).

 Looking at the standard, I think their interpretation is correct
 (although I'm not familiar with it and could be missing something) but
 it isn't clear that this was the intent of the authors. Any opinions
 on this?

 I think it's quite easy to work around, we can replace:

 {{{
 #if !BOOST_PP_IS_ITERATING
 // ....
 #elif BOOST_PP_ITERATION_DEPTH() == 1
 // ....
 #elif BOOST_PP_ITERATION_DEPTH() == 2
 // ....
 #endif
 }}}

 with:

 {{{
 #if !BOOST_PP_IS_ITERATING
 // ....
 #else
 # if BOOST_PP_ITERATION_DEPTH() == 1
 // ....
 # elif BOOST_PP_ITERATION_DEPTH() == 2
 // ....
 # endif
 #endif
 }}}

 So that the calls to BOOST_PP_ITERATION_DEPTH are skipped - or we
 could just include the necessary header before including the file. But
 it does seem a pity that any code which uses this technique might need
 to be changed for gcc 4.4. We should probably write to them about this
 (it doesn't look like they realised this would be a problem), but I'm
 writing here first in case anyone has any ideas.

-- 
Ticket URL: <http://svn.boost.org/trac/boost/ticket/2069#comment:2>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.