Re: [Boost-users] Can not compile a program that uses typeof package by gcc?

Subject: Re: [Boost-users] Can not compile a program that uses typeof package by gcc?
From: Peng Yu (pengyu.ut_at_[hidden])
Date: 2008-10-22 22:21:12

On Wed, Oct 22, 2008 at 9:01 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
> AMDG
>
> Peng Yu wrote:
>>>
>>> What I meant to say was that if library B contains a function
>>> that needs to deduce the result type of a multiplication, then
>>> it should put a typeof based multiply_traits in B::detail.
>>>
>>
>> BOOST_TYPEOF does not work with the current version of GCC, the
>> compiler that I use. That is why I have to use multiply_traits. Then
>> where I put multiply_traits?
>
> Boost.Typeof *does* work on gcc--as long as you don't
> try to use it in a function signature.

Because of a bug in GCC, BOOST_TYPEOF (which essentially is a macro
for 'typeof') does not work for the attached code. I tried GCC 4.1.1,
somebody else tried GCC 4.3.0. Neither of them work for the attached
code.

>>> If you have a different multiply_traits for every type, then
>>> it is completely useless in generic code.
>>>
>>
>> I don't quite understand what you mean. Since users have their choice
>> to define whatever classes to be used of B::Y, they have to have a way
>> to define multiply_traits if they want. I don't understand why "it is
>> completely useless in generic code". What you mean by generic code?
>>
>
> By generic code I mean any template that wants to take two arbitrary
> types, multiply instances of them together, and find the result type.
>
> If you have two separate multiply_traits in different namespaces,
> then as far as the compiler is concerned, they are two completely
> separate entities.  The compiler resolves which multiply_traits is
> used when the template using it is defined.  It is impossible to
> dispatch based on the namespace of the template arguments.

Since BOOST_TYPEOF is does not work for the attached code, then I'll
have to define multiply_traits for user defined types, X1, X2, in the
namespace of B::detail. This is not a prefect solution. But it is
probably the most satisfiable solution based on the constraints that
we have.

Thanks,
Peng