Modify

Ticket #8418 (closed Bugs: fixed)

Opened 12 months ago

Last modified 12 months ago

Boost Fusion foreach works for std::tuple OR boost::tuple depending on inclusion order

Reported by: bugs@… Owned by: djowel
Milestone: To Be Determined Component: fusion
Version: Boost 1.53.0 Severity: Problem
Keywords: fusion tuple adapted Cc: bugs@…, william@…

Description

As my attached repro sample shows can't adapt std::tuple and boost::tuple at the same time.

The headers

#   include <boost/fusion/adapted/boost_tuple.hpp>
#   include <boost/fusion/adapted/std_tuple.hpp>

seem to mutually exclude each other (at least in this code sample). Which ever header of the two gets included _first_, determines which type of tuple will be usable as a fusion sequence in that TU.

In the case of the 'blanket' include boost/fusion/adapted.hpp this means that std::tuple is not usable as a Fusion Sequence - unless one explicitely include boost/fusion/adapted/std_tuple.hpp _ahead_ of that.

This is rather surprising, and obviously causes problems for people mixing std::tuple and boost::tuple within a sinlge TU.

Also, although I haven't looked too deeply into the mechanics of it, I worry a bit that this may be a signal that ODR violations could be lurking when different TUs include the headers in different order.

Attachments

test.cpp Download (544 bytes) - added by bugs@… 12 months ago.
Simple reproducer for ticket #8418
fusion.patch Download (666 bytes) - added by william@… 12 months ago.
Patch

Change History

Changed 12 months ago by bugs@…

Simple reproducer for ticket #8418

comment:1 Changed 12 months ago by anonymous

  • Owner set to djowel
  • Component changed from None to fusion

comment:2 Changed 12 months ago by anonymous

Hi,

I believe the issue behind this is that the header guards for the following 2 files have the SAME header guard value of BOOST_FUSION_CATEGORY_OF_IMPL_09272006_0726.

  1. boost/fusion/adapted/boost_tuple/detail/category_of_impl.hpp
  2. boost/fusion/adapted/std_tuple/detail/category_of_impl.hpp

Changed 12 months ago by william@…

Patch

comment:3 Changed 12 months ago by William Lynch <william@…>

  • Cc william@… added

comment:4 follow-up: ↓ 6 Changed 12 months ago by anonymous

Amazing! I had this hunch, but on looking at the header guards, I concluded they looked like they are automatically generated :|

On that ground I dismissed the possibility of a collision... How did you 'make up' a new 'unique' header guard name?

Thanks!

comment:5 Changed 12 months ago by djowel

  • Status changed from new to closed
  • Resolution set to fixed

(In [84000]) Fixes #8418

comment:6 in reply to: ↑ 4 Changed 12 months ago by William Lynch <william@…>

Replying to anonymous:

Amazing! I had this hunch, but on looking at the header guards, I concluded they looked like they are automatically generated :|

On that ground I dismissed the possibility of a collision... How did you 'make up' a new 'unique' header guard name?

Thanks!

The tail end of the header guard appears to be a datetime string, so I changed that to today's date. I imagined that if I was wrong with that assumption, that Joel would have used a different one.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.