In article <39047D35.8302F8BE@magma.ca> Jim Cobban <jcobban@magma.ca> writes:
>In the C++ standard the actual way that numbers are formatted for output
>is not defined in absolute terms, but rather in terms of what printf and
>scanf do according to the C89 standard.  Since the use of printf and
>scanf is discouraged in C++, among other reasons because they are error
>prone and do not support user defined types, this seems to me a strange
>way to do business.  In my own case I have not used printf for several
>years and the memory of its arcana is slipping away, and I found that
>last week the failure to recall one of those details, even though I was
>working with an ostream, resulted in unexpected output which took me a
>couple of days to figure out.
>
>I therefore suggest that the next time this standard is opened for
>maintenance that the references to the behavior of printf and scanf be
>removed, at least from the main body of the standard, you can leave them
>in an appendix if you like.

Although I agree there are issues with printf et al, the thing is that
if you removed their references, the way the numbers are formatted
would still need to be explained, so it's unclear how describing
it in some other form would be superior?

- Greg
--
Comeau Computing, Producers of Comeau C/C++ 4.2.42 (4.2.43 BETA starting)
Try Comeau C++ online at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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:
>
> In the C++ standard the actual way that numbers are formatted for output
> is not defined in absolute terms, but rather in terms of what printf and
> scanf do according to the C89 standard.  Since the use of printf and
> scanf is discouraged in C++, among other reasons because they are error
> prone and do not support user defined types, this seems to me a strange
> way to do business.  In my own case I have not used printf for several
> years and the memory of its arcana is slipping away, and I found that
> last week the failure to recall one of those details, even though I was
> working with an ostream, resulted in unexpected output which took me a
> couple of days to figure out.
>
> I therefore suggest that the next time this standard is opened for
> maintenance that the references to the behavior of printf and scanf be
> removed, at least from the main body of the standard, you can leave them
> in an appendix if you like.
>

That would require writing their equivalent as part of the standard,
with a non-negligible chance that the result would accidentally differ
from the current requirements. Even then, I don't see how this would
solve your problem. If you forgot how the formatting specifiers work,
then you forgot how they work, regardless of where they are documented.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

---
[ 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              ]

Pete Becker <petebecker@acm.org> writes:

|>  Jim Cobban wrote:

|>  > In the C++ standard the actual way that numbers are formatted for o=
utput
|>  > is not defined in absolute terms, but rather in terms of what print=
f and
|>  > scanf do according to the C89 standard.  Since the use of printf an=
d
|>  > scanf is discouraged in C++, among other reasons because they are e=
rror
|>  > prone and do not support user defined types, this seems to me a str=
ange
|>  > way to do business.  In my own case I have not used printf for seve=
ral
|>  > years and the memory of its arcana is slipping away, and I found th=
at
|>  > last week the failure to recall one of those details, even though I=
 was
|>  > working with an ostream, resulted in unexpected output which took m=
e a
|>  > couple of days to figure out.

|>  > I therefore suggest that the next time this standard is opened for
|>  > maintenance that the references to the behavior of printf and scanf=
 be
|>  > removed, at least from the main body of the standard, you can leave=
 them
|>  > in an appendix if you like.

|>  That would require writing their equivalent as part of the standard,
|>  with a non-negligible chance that the result would accidentally diffe=
r
|>  from the current requirements. Even then, I don't see how this would
|>  solve your problem. If you forgot how the formatting specifiers work,
|>  then you forgot how they work, regardless of where they are documente=
d.

I agree partially.  First, of course, the C++ standard is not designed
as a tutorial, or even an everyday reference, and the fact that it
describes formatting in terms of printf doesn't mean that a tutorial, or
even a less formal reference should.

The real question is, IMHO, one of intent.  If the intent is that the
formatting be indentical, then the only correct way of attaining this is
by reference -- otherwise, it won't be identical.  Personally, I don't
see any pervasive argument why it must be identical, but I don't know
what the attitude of the C++ committee was on this.  And as Pete points
out, fully specifying the conversions is a lot of work, with a lot of
possibilities for error.  In this case, I guess one could speak of
standardization reuse, rather than code reuse.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 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.
--------------345CC3DE8DB9DA82F0B93793
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Pete Becker wrote:

> That would require writing their equivalent as part of the standard,
> with a non-negligible chance that the result would accidentally differ
> from the current requirements. Even then, I don't see how this would
> solve your problem. If you forgot how the formatting specifiers work,
> then you forgot how they work, regardless of where they are documented.

But the problem is that I have to remember something which I am doing my
darndest to forget:  How those wierd format strings worked.  Moreover  the
contributors to this and other forums frequently suggest that "real C++
programmers don't use printf and scanf".

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


--------------345CC3DE8DB9DA82F0B93793
Content-Type: text/x-vcard; charset=us-ascii;
 name="jcobban.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jim Cobban
Content-Disposition: attachment;
 filename="jcobban.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

--------------345CC3DE8DB9DA82F0B93793--

---
[ 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.
--------------BA2DB20FE07EFE4AFCC95878
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

In the C++ standard the actual way that numbers are formatted for output
is not defined in absolute terms, but rather in terms of what printf and
scanf do according to the C89 standard.  Since the use of printf and
scanf is discouraged in C++, among other reasons because they are error
prone and do not support user defined types, this seems to me a strange
way to do business.  In my own case I have not used printf for several
years and the memory of its arcana is slipping away, and I found that
last week the failure to recall one of those details, even though I was
working with an ostream, resulted in unexpected output which took me a
couple of days to figure out.

I therefore suggest that the next time this standard is opened for
maintenance that the references to the behavior of printf and scanf be
removed, at least from the main body of the standard, you can leave them
in an appendix if you like.

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


--------------BA2DB20FE07EFE4AFCC95878
Content-Type: text/x-vcard; charset=us-ascii;
 name="jcobban.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jim Cobban
Content-Disposition: attachment;
 filename="jcobban.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

--------------BA2DB20FE07EFE4AFCC95878--

---
[ 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              ]