On Thu, 10 Mar 2011 13:08:32 -0800 Steven Watanabe <watanabesj@gmail.com> wrote:
That took care of that problem. Any comments on the others? The second one seems important... I had to comment all three types out of the mpl::vector to get it to even compile, once I fixed the overloaded functions to only work on things that are integers. As far as I can see, that makes those tests useless.
Ah, I see. The test will only work if you disable the operators directly. [...]
That would be simpler than the work-around I used too. I've noted it for future implementation.
Does fail_adl_detail.cpp compile on your system? It shouldn't, so far as I can see, but on mine it does. It compiles for me too. This is one of my favorite tests which almost always fails unless you've thought about it. Hang on... you're telling the main function to use the detail namespace, where that function is. Wouldn't it be found directly because of that, ignoring ADL?
No. The using directive refers to the options namespace.
Yes, I realized my mistake this morning. Sorry about that.
After removing that using line (and modifying the options), it's still being found though. It looks like it's because integer_t is inheriting from things in the xint::detail namespace. As far as I can see, that can't be eliminated without pulling more classes into the xint namespace. Do you have a solution that wouldn't require that?
That's the solution I usually use. I just make sure that they don't show up in the documentation. Another option is to use an ADL barrier namespace. [...]
Nice.
(On that note, it's generally a good idea to use (f)(x) or xint::f(x) instead of f(x) unless you intend f to be a customization point).
Sorry, you lost me. Would all function calls need that? If not, which ones is it limited to? -- Chad Nelson Oak Circle Software, Inc. * * *