[patch] ./boost/property_tree/detail/xml_parser_read_rapidxml.hpp:117: error: non-constant `(((int)f_c) | 3072)' cannot be used as template argument

[Jan-Hein Bührman <buhrman@…>]

When compiling today's development trunk of boost, I see the following errors:

[snip]
gcc.compile.c++ bin.v2/libs/graph/build/gcc-3.4.4/release/threading-multi/graphml.o
./boost/property_tree/detail/xml_parser_read_rapidxml.hpp: In function `void boost::property_tree::xml_parser::read_xml_internal(std::basic_istream<typename Ptree::key_type::value_type, std::char_traits<typename Ptree::key_type::value_type> >&, Ptree&, int, const std::string&) [with Ptree = boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> >]':
./boost/property_tree/xml_parser.hpp:52:   instantiated from `void boost::property_tree::xml_parser::read_xml(std::basic_istream<typename Ptree::key_type::value_type, std::char_traits<typename Ptree::key_type::value_type> >&, Ptree&, int) [with Ptree = boost::property_tree::ptree]'
libs\graph\src\graphml.cpp:49:   instantiated from here
./boost/property_tree/detail/xml_parser_read_rapidxml.hpp:117: error: non-constant `(((int)f_c) | 3072)' cannot be used as template argument
./boost/property_tree/detail/xml_parser_read_rapidxml.hpp:117: error: no matching function for call to `boost::property_tree::detail::rapidxml::xml_document<char>::parse(char*)'
[snip]

bjam was generated in the follwing way:

$ ./bootstrap.sh --prefix=$HOME/local --exec-prefix=$HOME/local/${MACHTYPE=i686-pc-cygwin}

It is compiled on Windows XP machine, under a recent update of Cygwin.

$ g++ --version
g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I googled up a workaround (ref. <http://old.nabble.com/Sandia-gcc-3.4.6-error-on-Boost.Graph-td26800239.html>) that fixes the problem for me, see attached svn diff.

[Sebastian Redl]

(In [61605]) Cater to compilers too stupid to interpret a bitwise OR in a template argument as a constant.

Fixes bug 4146

[anonymous]

Looks like this patch didn't make it into release 1.43.0. :(

[Leonid Gershanovich <gleonid@…>]

using enums instead of const int template arguments

[Leonid Gershanovich <gleonid@…>]

please consider previous attachments. essentially I propose to use enums instead of const int:

--           const int f_tws = parse_normalize_whitespace
--                            | parse_trim_whitespace;
+            enum {    f_tws = parse_normalize_whitespace 
+                            | parse_trim_whitespace };

This should work with any compiler as enum is a compile time constant, while const int is a run time constant.

[Sebastian Redl]

Do you have a specific incredibly broken compiler that you want me to support with that?

[Leonid Gershanovich <gleonid@…>]

gcc 3.4.6 (RHEL 4) and gcc 4.1.2 (RHEL 5) both choking on this construct.

[buhrman@…]

Replying to Leonid Gershanovich <gleonid@…>:

gcc 3.4.6 (RHEL 4) and gcc 4.1.2 (RHEL 5) both choking on this construct.

Just to get things clear and to prevent mistakes: are these gcc versions (1) choking on the original sources where I provided a patch for, or (2) after you have applied this patch (​boost-property_tree_fix2.diff)?

In the first case (1) I would would recommend just moving to a more recent version of Boost, because despite the remark made in comment 3 by anonymous I believe the fix is now in the latest release(s).

In the latter case (2) this would mean that gcc got worse (or more picky - I don't know since I'm not a C++ standard expert) since the proposed patch did solve the problem for gcc 3.4.4.

[Leonid Gershanovich <gleonid@…>]

I am using boost 1.46.1.

Those gcc versions are chocking on "const int" used as template argument, since "const int" is not a compile time constant in a strict sense.

[buhrman@…]

Replying to Leonid Gershanovich <gleonid@…>:

I am using boost 1.46.1.

Those gcc versions are chocking on "const int" used as template argument, since "const int" is not a compile time constant in a strict sense.

Stroustrup, The C++ Programming Language, 3rd ed., 3rd printing, sect. 13.2.3, Template Parameters, states:

A template argument can be a constant expression (sect. C.5).

And sect. C.5, Constant Expressions, states:

A constant expression evaluates to an integral or enumeration constant. Such an expression is composed of literals [...], enumerators [...], and consts initialized by constant expressions.

I didn't check the official standard, but I guess, reading the above, any decent compiler should grok this.

[Leonid Gershanovich <gleonid@…>]

As I already mentioned above there is a difference between run time and compile time constants. Other than that you are right: "const int" is a constant.

However I was not looking to open a discussion about c++ standard.

Is there a reason why you believe that enum should not be used in this particular case?

In any case - please let me know if you decide to dismiss my suggestion, in which case I'll keep applying patch to local copy of your library every time boost releases new version.

Thanks

[Sebastian Redl]

buhrman is completely right. These const ints are compile-time constants, and any compiler that doesn't treat them as such is broken.

That said, my only objection to your patch is that I find enums to define non-enumerated constants to be extremely ugly, and local enums even more so. That said, I'll see about applying your patch.

It's strange, though. According to the trunk test matrix, gcc-3.4.6 works just fine (the Sandia gcc-3.4.6 tester is all green). Furthermore, 4.0.1, 4.2.1, 4.2.4, 4.3.4, 4.4.3, 4.4.4, 4.4.5, 4.5.1 and 4.5.2 all work fine. The release branch XML test also passes for every single GCC version tested.

[Jan-Hein Bührman <buhrman@…>]

Replying to cornedbee:

[...] It's strange, though. According to the trunk test matrix, gcc-3.4.6 works just fine (the Sandia gcc-3.4.6 tester is all green). Furthermore, 4.0.1, 4.2.1, 4.2.4, 4.3.4, 4.4.3, 4.4.4, 4.4.5, 4.5.1 and 4.5.2 all work fine. The release branch XML test also passes for every single GCC version tested.

This would make me very curious about the exact compiler diagnostic issued.

Since this is a different problem (though very similar), with a (must be) different compiler diagnostic, with different (newer) versions of Boost and gcc, I would like to suggest that a new ticket is opened with the new compiler diagnostic, version identifications, etc.

This makes it also easier for others having the same problem to find the right solution.

[This was my last €0,02 - I'm bailing out of this discussion now]