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

attachment set

Sat, 24 Apr 2010 16:33:42 GMT

attachment → boost-property_tree_fix2.diff

summary changed

Mon, 26 Apr 2010 09:20:38 GMT

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

status changed; resolution set

Sebastian Redl — Tue, 27 Apr 2010 08:59:36 GMT

status new → closed
resolution → fixed

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

Fixes bug 4146

anonymous — Sun, 08 Aug 2010 11:10:03 GMT

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

attachment set

Sun, 20 Mar 2011 18:05:03 GMT

attachment → xml_parser_read_rapidxml.hpp.patch_1_46_0

using enums instead of const int template arguments

Sun, 20 Mar 2011 18:14:11 GMT

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 — Sun, 20 Mar 2011 19:26:50 GMT

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

Mon, 21 Mar 2011 15:10:55 GMT

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

buhrman@… — Mon, 21 Mar 2011 15:38:04 GMT

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.

Mon, 21 Mar 2011 16:03:15 GMT

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@… — Mon, 21 Mar 2011 19:53:16 GMT

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.

Mon, 21 Mar 2011 20:58:34 GMT

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 — Tue, 22 Mar 2011 09:23:11 GMT

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.

Tue, 22 Mar 2011 09:49:37 GMT

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]