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

Ovanes Markarian wrote:

Noah,

please see my answer below:

On Tue, Mar 3, 2009 at 5:59 PM, Noah Roberts mailto:roberts.noah@gmail.com> 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 but the explicit notation would require the function to expect a rec; 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.