Forward declarations and iterator_facade<>
Dear Experts, I have code something like this: struct S; class iter: public boost::iterator_facade<iter,S,......> { ... }; struct S { ... }; This used to work, but stopped recently; I believe it may have been after upgrading gcc, not after upgrading Boost itself, but I'm uncertain about that. The problem is that something inside iterator_facade calls boost::is_POD<S>, which (not unreasonably) doesn't seem to work for the forward-declared S. I've never been entirely sure what you're allowed to do with forward-declared types like that. Was I just lucky that it worked before, or is this a regression? Re-ordering the code to remove the circular dependencies will be painful, so if anyone has any other hints I would love to hear them. Thanks, Phil.
At Fri, 15 Oct 2010 17:24:42 +0100, Phil Endecott wrote:
Dear Experts,
I have code something like this:
struct S;
class iter: public boost::iterator_facade<iter,S,......> { ... };
struct S { ... };
This used to work, but stopped recently; I believe it may have been after upgrading gcc, not after upgrading Boost itself, but I'm uncertain about that. The problem is that something inside iterator_facade calls boost::is_POD<S>, which (not unreasonably) doesn't seem to work for the forward-declared S.
I've never been entirely sure what you're allowed to do with forward-declared types like that. Was I just lucky that it worked before, or is this a regression?
I guess you were just lucky, because we never tested for or intended to provide that capability.
Re-ordering the code to remove the circular dependencies will be painful, so if anyone has any other hints I would love to hear them.
I'm afraid there's not going to be any other choice for you unless we are somehow able to add that capability in Boost and you are able to wait for it. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Fri, Oct 15, 2010 at 11:02 AM, David Abrahams <dave@boostpro.com> wrote:
At Fri, 15 Oct 2010 17:24:42 +0100, Phil Endecott wrote:
Dear Experts,
I have code something like this:
struct S;
class iter: public boost::iterator_facade<iter,S,......> { ... };
struct S { ... };
This used to work, but stopped recently; I believe it may have been after upgrading gcc, not after upgrading Boost itself, but I'm uncertain about that. The problem is that something inside iterator_facade calls boost::is_POD<S>, which (not unreasonably) doesn't seem to work for the forward-declared S.
I've never been entirely sure what you're allowed to do with forward-declared types like that. Was I just lucky that it worked before, or is this a regression?
I guess you were just lucky, because we never tested for or intended to provide that capability.
Re-ordering the code to remove the circular dependencies will be painful, so if anyone has any other hints I would love to hear them.
I'm afraid there's not going to be any other choice for you unless we are somehow able to add that capability in Boost and you are able to wait for it.
Shouldn't he be able to just specialize boost::is_pod on his forward declared type as true?
At Fri, 15 Oct 2010 16:49:40 -0600, OvermindDL1 wrote:
On Fri, Oct 15, 2010 at 11:02 AM, David Abrahams <dave@boostpro.com> wrote:
At Fri, 15 Oct 2010 17:24:42 +0100, Phil Endecott wrote:
Dear Experts,
I have code something like this:
struct S;
class iter: public boost::iterator_facade<iter,S,......> { ... };
struct S { ... };
This used to work, but stopped recently; I believe it may have been after upgrading gcc, not after upgrading Boost itself, but I'm uncertain about that. The problem is that something inside iterator_facade calls boost::is_POD<S>, which (not unreasonably) doesn't seem to work for the forward-declared S.
I guess you were just lucky, because we never tested for or intended to provide that capability.
Re-ordering the code to remove the circular dependencies will be painful, so if anyone has any other hints I would love to hear them.
I'm afraid there's not going to be any other choice for you unless we are somehow able to add that capability in Boost and you are able to wait for it.
Shouldn't he be able to just specialize boost::is_pod on his forward declared type as true?
Yeah (or false If it's not actually POD). That would be a perfectly legit thing to do; good idea. namespace boost { template <> struct is_pod<MyPod> : boost::mpl::true_ {}; template <> struct is_pod<MyNonPod> : boost::mpl::false_ {}; } It might even work. No guarantees of course, but it's a pretty good bet. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (3)
-
David Abrahams -
OvermindDL1 -
Phil Endecott