Re: [Boost-users] [shared_ptr] Error in Constructor

Subject: Re: [Boost-users] [shared_ptr] Error in Constructor
From: David Greene (greened_at_[hidden])
Date: 2010-05-25 20:10:36

On Saturday 22 May 2010 13:12:40 Peter Dimov wrote:

> > That's really bad.  It effectively means one can't easily tell when one
> > might
> > need the full definition of a type.  I ran into this because I wanted to
> > decouple some code defining the body of one function that takes one
> > type from the body of another that takes a different type.  In terms of
> > the example, I didn't want changes to A to cause recompilation of
> > functions that take a Wrapper<B>.
> 
> I see how that might be a problem, but I don't see a solution. Either way,
> someone loses. I'd probably remove the typedef typename Tag::type type in
> this case, as it's the only thing requiring the definition of A.

Unfortunately, in the real code the typedef is needed for some 
metaprogramming.  I will see if I can work around it somehow.

Adding the cast to the ?: solves this particular problem but the real
code has a good amount of proto- and fusion-generated stuff which
assumes conversions with shared_ptr work as if they were bare
pointers.  It's not obvious where casts are needed or what the
casted-to type should be.  So it seems I have to choose between
making the code compile and keeping separate compilation.  Not
a choice but it forces one to couple the code more than should
be necessary.

Isn't a possible solution to amend the standard to require short-circuited
overload resolution?  Or would that break some other existing examples?
The committee is about to finalize the new standard.  Is this worth
discussing at this late stage?  Perhaps I will submit a comment pointing
to this thread.

Thanks for your help!

                                        -Dave