Your message dated Sun, 16 Nov 2003 21:11:40 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Not a bug: Cannot subtract from streampos
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 4 Apr 2003 15:15:29 +0000
>From [EMAIL PROTECTED] Fri Apr 04 09:15:29 2003
Return-path: <[EMAIL PROTECTED]>
Received: from smtpzilla3.xs4all.nl [194.109.127.139]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 191Sue-0005Io-00; Fri, 04 Apr 2003 09:15:29 -0600
Received: from liacs.nl ([132.229.137.201])
by smtpzilla3.xs4all.nl (8.12.9/8.12.9) with ESMTP id h34FFR4Y029399
for <[EMAIL PROTECTED]>; Fri, 4 Apr 2003 17:15:27 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
Date: Fri, 04 Apr 2003 17:15:22 +0200
From: Bart Samwel <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030327
Debian/1.3-4
X-Accept-Language: en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
Subject: Cannot subtract from streampos
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-1.5 required=4.0
tests=HAS_PACKAGE,SPAM_PHRASE_00_01,USER_AGENT,
USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG
version=2.44
X-Spam-Level:
Package: g++
Version: 3.2.3-20030331
If I have the following code:
#include <sstream>
int foo()
{
std::streampos pos;
pos - 1;
}
When I compile this with "g++ -Wall test.cc", this gives me:
test.cc: In function `int foo()':
test.cc:6: ISO C++ says that `std::fpos<_StateT>
std::fpos<_StateT>::operator-(long int) [with _StateT = mbstate_t]'
and `
operator-' are ambiguous even though the worst conversion for the
former is
better than the worst conversion for the latter
I think this means that there are both a global operator- and a member
operator- defined for std::fpos<_StateT>. I can work around this (I can
do pos -= 1 and afterwards pos += 1), but I'd much rather be able to
simply subtract from the streampos.
---------------------------------------
Received: (at 187599-done) by bugs.debian.org; 16 Nov 2003 20:17:31 +0000
>From [EMAIL PROTECTED] Sun Nov 16 14:17:30 2003
Return-path: <[EMAIL PROTECTED]>
Received: from mail.cs.tu-berlin.de [130.149.17.13]
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1ALTKs-0000cG-00; Sun, 16 Nov 2003 14:17:30 -0600
Received: from bolero.cs.tu-berlin.de ([EMAIL PROTECTED] [130.149.19.1])
by mail.cs.tu-berlin.de (8.9.3p2/8.9.3) with ESMTP id VAA00554;
Sun, 16 Nov 2003 21:11:41 +0100 (MET)
Received: (from [EMAIL PROTECTED])
by bolero.cs.tu-berlin.de (8.12.10+Sun/8.12.8/Submit) id hAGKBeie026293;
Sun, 16 Nov 2003 21:11:40 +0100 (MET)
From: Matthias Klose <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <[EMAIL PROTECTED]>
Date: Sun, 16 Nov 2003 21:11:40 +0100
To: [EMAIL PROTECTED]
CC: Phil Edwards <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Not a bug: Cannot subtract from streampos
X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-5.7 required=4.0
tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT
version=2.53-bugs.debian.org_2003_11_15
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_11_15
(1.174.2.15-2003-03-30-exp)
[ok, re-found this (german) message in my mailbox, trying to translate
it ... and closing the report]
g++-3.4 reports:
bug-187599.cc: In function `int foo()':
bug-187599.cc:6: error: ambiguous overload for 'operator-' in 'pos - 1'=
/usr/include/c++/3.4/bits/postypes.h:236: note: candidates are: std::fp=
os<_StateT> std::fpos<_StateT>::operator-(const std::streamoff&) const =
[with _StateT =3D mbstate_t]
/usr/include/c++/3.4/bits/postypes.h:248: note: std::st=
reamoff std::fpos<_StateT>::operator-(const std::fpos<_StateT>&) const =
[with _StateT =3D mbstate_t]
There exists a conversion from streampos to streamoff, so that the
expression can be interpreted as
=09(streamoff)pos - 1
or
=09pos.operator-(1)
In both cases conversions are used (from streampos to streamoff, and
from int to long). The ambiguouity can be resolved be writing
=09pos - 1L
Martin wrote:
> Kein Bug (glaube ich). Ich glaube (ohne es noch mal kontrolliert
> zu haben), dass ISO C++ diese Operation tats=E4chlich als mehrdeutig=20=
> ablehnt. Der Submitter hat =FCbersehen, dass es eine Konvertierung
> von streampos nach streamoff gibt, so dass man das ganze als
>=20
> (streamoff)pos - 1
>=20
> (streamoff ist ein primitiver Typ) oder als
>=20
> pos.operator-(1)
>=20
> verstehen kann. In beiden F=E4llen sind Konvertierungen im Spiel:
> Einmal von streampos nach streamoff, beim anderen von int nach
> long. Der Submitter wird die Mehrdeutigkeit los, indem er schreibt
>=20
> pos - 1L
>=20
> Er sollte ber=FCcksichtigen, dass das Ergebnis jeweils ein anderes
> ist: Mal ein streampos, und mal ein streamoff.
>=20
