This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/17057] problems disambiguating std::allocator::rebind
- From: "mark at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 17 Aug 2004 16:22:34 -0000
- Subject: [Bug c++/17057] problems disambiguating std::allocator::rebind
- References: <20040817040042.17057.bkoz@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From mark at codesourcery dot com 2004-08-17 16:22 -------
Subject: Re: problems disambiguating std::allocator::rebind
bkoz at gcc dot gnu dot org wrote:
>------- Additional Comments From bkoz at gcc dot gnu dot org 2004-08-17 16:10 -------
>
>With all due respect, I think the preliminary analysis is not absolutely correct.
>
>First of all, it makes no difference what the EDG/icc flags are: both chug
>through this code without error or warning. I'm using Version 8.1 Beta Build
>20040602Z with gnu headers, but I'm not quite sure this really matters.
>
>Second, Andrew's summation is not what the code details. My apology:
>Perhaps I attached the wrong pre-processed code the first time. I've tried
>again, see mt_allocator.ii.
>
>To recap:
>
> template<typename _Tp, typename _PoolTp>
> class __mt_alloc : public _PoolTp
> {
> public:
>
> template<typename _Tp1, typename _PoolTp1 = _PoolTp>
> struct rebind
> {
>#if 1
> // ok with edg
> typedef _PoolTp1::_M_rebind<_Tp1>::other pool_type;
>#else
> // as g++ suggests but cannot compile
> typedef _PoolTp1::template _M_rebind<_Tp1>::other pool_type;
>#endif
> typedef __mt_alloc<_Tp1, pool_type> other;
> };
> };
>
>None of these work with g++. If I just keep on adding junk, say
>
> typedef typename _PoolTp1::template _M_rebind<_Tp1>::other pool_type;
>
>
>this compiles with both g++ and EDG. Syntax only a mother could love (could this
>really get any uglier?), but hey, it works.
>
The last version is definitely valid.
I do not believe the case in "#if 1" is valid.
There are DRs in the works that might make it valid, though; there has
been some suggestion that in "type contexts" (like the first operand to
"typedef") "typename" should be assumed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17057