Boost logo

Boost :

Subject: Re: [boost] [challenge!] find a common domain
From: Eric Niebler (eric_at_[hidden])
Date: 2010-05-19 18:02:26

On 5/19/2010 2:47 PM, Jeremiah Willcock wrote:
> On Wed, 19 May 2010, Eric Niebler wrote:
>> On 5/19/2010 2:25 PM, Jeremiah Willcock wrote:
>>> How do the rules for default_domain (and domains derived from it) fit
>>> into that picture? Expressions from different domains not derived from
>>> default_domain produce not_a_domain in the case of conflicts,
>> Right.
>>> while a
>>> pair in which one element is derived from default_domain will always
>>> choose that element as the domain of the new expression.
>> Here, you mean "the other element" -- that is, the domain that is not a
>> sub-domain of default_domain. The family of domains rooted at
>> default_domain is weaker than all others.
> OK. I implemented it the other way around -- choose the
> default_domain-derived domain if the other one isn't derived from that
> base. The two cases to flip to fix that are the second and third
> specializations of deduce_domain2_cases.


>>> In my
>>> implementation, if both domains derive from default_domain but are
>>> otherwise incompatible, the result will be default_domain,
>> That's not right for the reason I stated above. And that's the case that
>> hung me up for a while.
> What do you want there? not_a_domain?


> Is default_domain itself a
> domain that's accessible to users (i.e., they can have an element with
> default_domain as its domain)?


> In that case, when do two domains that
> both derive from default_domain conflict? They have a common ancestor,
> namely default_domain. Or should default_domain be special in that
> regard, with a rule such as "if the merger of two domains is
> default_domain but one of them isn't default_domain, replace the result
> with not_a_domain"?

Close. Yes, default_domain is special. If the merger of two domains is
default_domain and /neither of them/ is default_domain, the result is
not_a_domain. Otherwise, the one that's not default_domain dominates.
So, if lambda_domain is a sub-domain of default_domain, it is stronger
than default_domain and should dominate. I.e., "_1 + 42" should be a
lambda expression.

default_domain should *never* be the answer when any domain is not

Gotta pass all the test cases I sent! :-)

>>> but normal
>>> domains do not derive from default_domain and so end up with the
>>> not_a_domain behavior in the case of conflicts.
>> This part is right.
> OK.

Eric Niebler
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at