In article <863dorqcay.fsf@gabi-soft.de>,
  kanze@gabi-soft.de wrote:
> Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:
>
> |>  It would certainly be a hassle to _require_ support for
> |>  other bases. But to _allow_ support for other bases, it would
> |>  be enough to add "If the function is called with a value other
> |>  than 8, 10 or 16, the behaviour is undefined".
>
> "If the function is called with a value other than 8, 10, 16, or 0,
the
> behavior is undefined."

Yes, yes, very important. I can't tell you how often I've needed
support for base-0 numbers, but so few libraries support it! :-)

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jim Cobban wrote:
>
> The description of the setbase iomanipulator provides some pseudocode
> which specifies that if the parameter is not 8, 10, or 16, then the
> basefield formatting flags are to be all cleared.  Is this pseudocode
> normative?.  If it is then it would make any implementation which wanted
> to support bases other than those three non-compliant to the standard.
> That is a program which was written to assume standard compliant
> behavior for setbase(2), for example that the value 0101 is octal for
> 65, would fail if the compiler was enhanced so the integer was
> interpreted as binary 5, even though that would seem to be a reasonable
> extension.

That code is not merely an example; the standard specifies that
setbase() returns a value 's' such that "out<<s behaves as if f(s) were
called", and then it defines f(). So yes, the text of f() is normative,
insofar as it describes the behavior that must occur. Rather annoying,
really. It means that if you can't allow extra bases even as extension
to the standard library; you have to create your own unrelated facility
for implementing it. Why was it done this way?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:
> That code is not merely an example; the standard specifies that
> setbase() returns a value 's' such that "out<<s behaves as if f(s) were
> called", and then it defines f(). So yes, the text of f() is normative,
> insofar as it describes the behavior that must occur. Rather annoying,
> really. It means that if you can't allow extra bases even as extension
> to the standard library; you have to create your own unrelated facility
> for implementing it. Why was it done this way?

Actually, since that code is completely erroneous (look at the variable
names), the effects of setbase aren't really defined at all. My defect
report about that has already been accepted; you may want to submit an
addendum about allowing other bases.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hyman Rosen wrote:
>
> James Kuyper <kuyper@wizard.net> writes:
> > That code is not merely an example; the standard specifies that
> > setbase() returns a value 's' such that "out<<s behaves as if f(s) were
> > called", and then it defines f(). So yes, the text of f() is normative,
> > insofar as it describes the behavior that must occur. Rather annoying,
> > really. It means that if you can't allow extra bases even as extension
> > to the standard library; you have to create your own unrelated facility
> > for implementing it. Why was it done this way?
>
> Actually, since that code is completely erroneous (look at the variable
> names), the effects of setbase aren't really defined at all. My defect

Yes, I remember the 'base'/'n' confusion. Well, the intent was clear, so
fixing it should be easy.

> report about that has already been accepted; you may want to submit an
> addendum about allowing other bases.

Not really - I suspect that it would be a major hassle to make the
change now. Allowing arbitrary bases would require storage of the base
value, and not merely a few bit flags, which I think would be a
significant change in the implementation of a key component of the
iostreams library. I'm not suggesting it be changed, I'm merely
inquiring why it was done that way in the first place.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
>
> Hyman Rosen wrote:
> >
> > James Kuyper <kuyper@wizard.net> writes:
> > > That code is not merely an example; the standard specifies that
> > > setbase() returns a value 's' such that "out<<s behaves as if f(s) were
> > > called", and then it defines f(). So yes, the text of f() is normative,
> > > insofar as it describes the behavior that must occur. Rather annoying,
> > > really. It means that if you can't allow extra bases even as extension
> > > to the standard library; you have to create your own unrelated facility
> > > for implementing it. Why was it done this way?
> >
> > Actually, since that code is completely erroneous (look at the variable
> > names), the effects of setbase aren't really defined at all. My defect
>
> Yes, I remember the 'base'/'n' confusion. Well, the intent was clear, so
> fixing it should be easy.
>
> > report about that has already been accepted; you may want to submit an
> > addendum about allowing other bases.
>
> Not really - I suspect that it would be a major hassle to make the
> change now.

It would certainly be a hassle to _require_ support for
other bases. But to _allow_ support for other bases, it would
be enough to add "If the function is called with a value other
than 8, 10 or 16, the behaviour is undefined".

Since implementations are allowed to define undefined
behaviour, they would be able to offer arbitrary bases
as extension.

[...]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:

|>  It would certainly be a hassle to _require_ support for
|>  other bases. But to _allow_ support for other bases, it would
|>  be enough to add "If the function is called with a value other
|>  than 8, 10 or 16, the behaviour is undefined".

"If the function is called with a value other than 8, 10, 16, or 0, the
behavior is undefined."

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

This is a multi-part message in MIME format.
--------------CFF0CBC96DAC3985AA02797C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The description of the setbase iomanipulator provides some pseudocode
which specifies that if the parameter is not 8, 10, or 16, then the
basefield formatting flags are to be all cleared.  Is this pseudocode
normative?.  If it is then it would make any implementation which wanted
to support bases other than those three non-compliant to the standard.
That is a program which was written to assume standard compliant
behavior for setbase(2), for example that the value 0101 is octal for
65, would fail if the compiler was enhanced so the integer was
interpreted as binary 5, even though that would seem to be a reasonable
extension.

--
Jim Cobban   jcobban@magma.ca
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438


--------------CFF0CBC96DAC3985AA02797C
Content-Type: text/x-vcard; charset=us-ascii;
 name="thesnaguy.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jim Cobban
Content-Disposition: attachment;
 filename="thesnaguy.vcf"

begin:vcard
n:Cobban;James
tel;fax:+1-613-592-9438
tel;home:+1-613-592-9438
x-mozilla-html:FALSE
url:http://www.magma.ca/~jcobban
version:2.1
email;internet:thesnaguy@hotmail.com
title:Consultant
adr;quoted-printable:;;34 Palomino Dr.=0D=0A;Kanata;ON;K2M 1M1;Canada
fn:Jim Cobban
end:vcard

--------------CFF0CBC96DAC3985AA02797C--

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]