Re: [boost] �

Subject: Re: [boost] �
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-08-13 13:03:10

----- Original Message ----- 
From: "Jeffrey Lee Hellrung, Jr." <jhellrung_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, August 13, 2010 6:49 PM
Subject: Re: [boost] �

> 
> On 8/13/2010 9:16 AM, vicente.botet wrote:
>> Hi,
>> ----- Original Message -----
>> From: "Jeffrey Lee Hellrung, Jr."<jhellrung_at_[hidden]>
>> To:<boost_at_[hidden]>
>> Sent: Friday, August 13, 2010 5:35 PM
>> Subject: Re: [boost] [chrono] v0.4.5 Documentation update + warnings removal + bug fixes
>>
>>
>>>
>>> On 8/10/2010 11:00 AM, vicente.botet wrote:
>>>> Hi,
>>>>
>>>> I have made some minor modifications to the Boost.Chrono library as requested on these mailing lists. The implementaton is stable.
>>> ...
>>>> Even if the review's date is not annonced yet, it will be great if some of you make a pre-review, so the conflicting issues are managed before the review.
>>>
>>> Is it necessary for common_type to fallback to Boost.TypeOf in the
>>> absence of decltype?  In what situations is (bool ? T : U) not either T,
>>> U, or some additional const/volatile qualifications on T or U, possibly
>>> transposed with some reference or pointer qualifiers?
>>>
>>> In other words, when does (bool ? T : U) manufacture some new "3rd type"
>>> out of the blue?
>>
>> (bool ? T : U) is incorrect as the ?: operator don't works on types but on expression. This is exactle the role of typeof. Are I'm missing something?
> 
> Okay, sorry, my fault for being lazy ;)  Replace (bool ? T : U) with (b 
> ? t : u); b of type bool; t of type T; u of type U; and t and u are 
> rvalues unless T and U (respectively) are (lvalue) reference types.

This is exactly what is in the code, other than I use functions instead of variables.

            static bool m_f();  // workaround gcc bug; not required by std
            static T m_t();
            static U m_u();
        public:
            typedef BOOST_TYPEOF_TPL(m_f() ? m_t() : m_u()) type;

We need however to transform the expression "(b ? t : u)" on a type and I don't see how to achieve it without typeof. Do you?

> Additionally, common_type operates on types, not expressions, so you 
> know the types you're working with in the hypothetical conditional 
> expression.

This is correct, but I don't see how this is related to your concern.

Vicente