Re: [Boost-users] [attn. Dave Abrahams] workaround ideas?

Subject: Re: [Boost-users] [attn. Dave Abrahams] workaround ideas?
From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2009-03-04 13:51:32

Ovanes Markarian wrote:
> Noah,
> 
> please see my answer below:
> 
> On Tue, Mar 3, 2009 at 5:59 PM, Noah Roberts <roberts.noah_at_[hidden] 
> <mailto:roberts.noah_at_[hidden]>> wrote:
> 
> 
>     template < typename FIELD, typename CDR >
>     typename FIELD::type & get(rec< FIELD, CDR > & r)
>     {
>      return r.value;
>     }
> 
> 
>  You should use the static_cast<SomeFieldSpecificType>(r) here to fix 
> the problem. The only problem is, that 'r' is the entire recordset, and 
> you can't cast it to itself, nor you can extract the SomeFieldSpecificType.

Not really.  The get function is called with an explicit template 
argument for the first argument:

get<field1>(r);

The resolution should therefore cast the rec to the correct base class 
so that r.value actually is the appropriate call.  Putting a static cast 
in the function body would actually have no effect and wouldn't resolve 
the ambiguity the compiler seems to think exists.

The type passed into the function is a rec<field3, XXX> but the explicit 
notation would require the function to expect a rec<field1,XXX>; the 
compiler is saying it can't decide between them.  I don't know where in 
the standard this would be specified but I expect it says to obey the 
explicit resolution over implicit.

> 
> Your example work with MSVC 9.

Yeah, I think they fixed the bug.  I tried it with express edition and 
it functions.  Comeau also eats it without error.

  I have rewritten it to use the
> static_cast, but did not test it with MSVC 8. Give it a try, I think 
> this should work:

This solution is what the instruction comes to in the book but isn't 
along the lines of my question.  For one thing I wanted the rec<> 
template to inherit directly from the other field recs, which my version 
(and the first example in the book) does.  Your code doesn't.

I am going to end up using something more like this version now, since I 
found what I was doing wrong earlier, but it still doesn't address the 
original problem that I'm pretty confident is a bug in the compiler.  My 
question was regarding the former technique since I thought I couldn't 
use the latter.

Anyway, thanks for the help.  I think I'm onto a solution to my original 
problem if not a workaround for making the compiler swallow the book's 
sample code.