That makes sense, thanks. That's the key piece I was missing.
--
John R. DailyProgeny Linux Systems
Consultant [EMAIL PROTECTED]
Master of the ephemeral epiphany
> What I do not understand is why the compiler does _not_ find
> ambiguity when the C++ class header is slimmed down to just the
> necessary parts: the operator overload and a constructor.
Because you've removed the ambiguity in simple.h. If you add the line
operator const char*()const;
back
At (time_t)712734125 "Martin v. Loewis" wrote:
> As you can see from PR#3747, this apparently comes from ptrdiff_t
> being signed on some architecture and unsigned on another. What part
> of the explanation in this PR is unclear to you?
I understand (more or less) why the compiler finds ambiguity
> > See PR#3747 at http://gcc.gnu.org/cgi-bin/gnatsweb.pl
> >
> > The fix is to not use unsigned int as a type in an overridden []
> > operator. changing the [] operator to have type int works.
>
> That fix did allow ftpgrab to compile under hppa, but I'm baffled
> as to how this can not be consi
> See PR#3747 at http://gcc.gnu.org/cgi-bin/gnatsweb.pl
>
> The fix is to not use unsigned int as a type in an overridden []
> operator. changing the [] operator to have type int works.
That fix did allow ftpgrab to compile under hppa, but I'm baffled
as to how this can not be considered a bug.
John had mentioned this bug to me on irc... after looking at this a
bit more, it looks like someone else had reported this to the gcc folks
and they determined it's not a bug.
See PR#3747 at http://gcc.gnu.org/cgi-bin/gnatsweb.pl
The fix is to not use unsigned int as a type in an overridden []
op
6 matches
Mail list logo
