regex and g++ 3.4.2 problem

Hi, $ g++ --version g++ (GCC) 3.4.2 [FreeBSD] 20040728 (boost version 1.32) When compiling a very simple example for the regex library, I've got the following error: In file included from /usr/local/include/boost_1_32_0/boost/regex/v4/regex.hpp:99, from /usr/local/include/boost_1_32_0/boost/regex.hpp:34, from regex.cc:1: /usr/local/include/boost_1_32_0/boost/regex/v4/instances.hpp:71: error: ISO C++ forbids the use of `extern' on explicit instantiations *** Error code 1 A short investigation points to the following code in the instances.hpp file: #elif (defined(BOOST_MSVC) && defined(_MSC_EXTENSIONS)) || defined(__GNUC__) # ifndef BOOST_REGEX_INSTANTIATE # define template extern template // (*) # endif # ifdef BOOST_MSVC # pragma warning(push) # pragma warning(disable : 4251 4231 4660) # endif template class BOOST_REGEX_DECL reg_expression< BOOST_REGEX_CHAR_T >; IMHO (and rather guessing), the #define in (*) is performed unnecessarily for g++ 3.4.2, but is executed just because of too generic __GNUC__ a little bit higher. As a temporary solution, I have just uncommented the following line in boost/regex/user.hpp: #define BOOST_REGEX_NO_EXTERNAL_TEMPLATES Now the simple program compiles and works fine. What influence will the above change in user.hpp have on bigger programs? Is this a known problem? -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/

On Sun, Nov 28, 2004 at 10:49:07PM +0100, Maciej Sobczak wrote:
Hi,
$ g++ --version g++ (GCC) 3.4.2 [FreeBSD] 20040728
(boost version 1.32)
When compiling a very simple example for the regex library, I've got the following error:
In file included from /usr/local/include/boost_1_32_0/boost/regex/v4/regex.hpp:99, from /usr/local/include/boost_1_32_0/boost/regex.hpp:34, from regex.cc:1: /usr/local/include/boost_1_32_0/boost/regex/v4/instances.hpp:71: error: ISO C++ forbids the use of `extern' on explicit instantiations *** Error code 1
Where you compiling with -pedantic ? AFAIK all versions of GCC reject this with -pedantic, but otherwise allow it as a GNU extension.
IMHO (and rather guessing), the #define in (*) is performed unnecessarily for g++ 3.4.2, but is executed just because of too generic __GNUC__ a little bit higher.
libstdc++ uses _GLIBCXX_EXTERN_TEMPLATE (or _GLIBCPP_EXTERN_TEMPLATE) in bits/istream.tcc to test whether to use the extern template syntax. That should probably be used by Boost.Regex too. jon -- This space left intentionally blank.

When compiling a very simple example for the regex library, I've got the following error:
A short investigation points to the following code in the instances.hpp file:
As a temporary solution, I have just uncommented the following line in boost/regex/user.hpp:
#define BOOST_REGEX_NO_EXTERNAL_TEMPLATES
Now the simple program compiles and works fine. What influence will the above change in user.hpp have on bigger programs?
They'll take longer to compile, have bigger object files, and if you're linking to the shared library, be a larger program as well.
Is this a known problem?
It is now :-) I can only reproduce this when compiling with -pedantic, the following fix will be going into cvs shortly: Index: instances.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/regex/v4/instances.hpp,v retrieving revision 1.10 diff -u -r1.10 instances.hpp --- instances.hpp 12 Mar 2004 13:12:25 -0000 1.10 +++ instances.hpp 29 Nov 2004 13:42:52 -0000 @@ -60,7 +60,11 @@ #elif (defined(BOOST_MSVC) && defined(_MSC_EXTENSIONS)) || defined(__GNUC__) # ifndef BOOST_REGEX_INSTANTIATE -# define template extern template +# ifdef __GNUC__ +# define template __extension__ extern template +# else +# define template extern template +# endif # endif # ifdef BOOST_MSVC John.

John Maddock wrote:
I can only reproduce this when compiling with -pedantic
This is what I routinely do. :)
the following fix will be going into cvs shortly:
It already went onto my local copy. Works fine now (g++ 3.4.2 -pedantic, boost 1.32). Thank you very much. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/
participants (3)
-
John Maddock
-
Jonathan Wakely
-
Maciej Sobczak