 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Daniel Krügler
Guest
|
 Posted: Fri Sep 17, 2004 8:04 am Post subject: Traces left of ios in current C++ Standard |
 |
|
Hello,
This morning I stumbled about several sprinkles of probably unintended
occurrences of historical traces of ios which is now defined by the typedef
typedef basic_ios<char> ios;
instead of the probably intended ios_base in Our most
recent Holy Standard (ISO/IEC 14882 2nd ed 2003). Strictly speaking all
these occurrences are still correct because ios_base is a public superclass
of the class template basic_ios, but also strictly speaking they cause
unnecessary
dependences on the basic_ios<char> class instead of the more neutral
ios_base class.
I couldn't find any similar report in
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html
so here is the list of occurrences I found:
21.3.7.9/p. 2a "[..], it calls is.setstate(ios::failbit),[..]"
23.3.5.3/p. 6 "If no characters are stored in str, calls
is.setstate(ios::failbit)[..]"
26.2.6/p. 13 "[..]If bad input is encountered, calls
is.setstate(ios::failbit) (which may throw
ios::failure (27.4.4.3)."
27.6.1.2.1/p. 1: "[..]If an exception is thrown during input then
ios::badbit is turned on (281)
in *this’s error state.[..]"
Footnote 281: "This is done without causing an ios::failure to be thrown."
27.6.1.3/p. "[..]If an exception is thrown during input then ios::badbit
is turned on (284)
in *this’s error state."
Footnote 284: "This is done without causing an ios::failure to be thrown."
(27.6.1.3/p. 22 In the given example)
27.6.2.5.1/p. 1: "[..]then the formatted output function does
setstate(ios::failbit),
which might throw an exception. If an exception is thrown during output,
then ios::badbit is turned
on (294) in *this’s error state.[..]"
Footnote 294: "without causing an ios::failure to be thrown."
27.6.2.6/p. 1: "[..]If an exception is thrown during output, then
ios::badbit is turned on (297a) in
*this’s error state.[..]"
Footnote 297a: "without causing an ios::failure to be thrown."
Table 104, table 105
D.7.1.3/p. 16: "[..]
— If (which & ios::in) != 0, positions the input sequence.
— If (which & ios::out) != 0, positions the output sequence.
[..]"
Recommended resolution: Replace the corresponding occurrences of ios by
by ios_base.
Greetings from Bremen,
Daniel Krügler
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
 |
Jonathan Turkanis
Guest
|
| Posted: Sat Sep 18, 2004 12:04 am Post subject: Re: Traces left of ios in current C++ Standard |
|
|
""Daniel Krügler (ne Spangenberg)"" <dsp (AT) bdal (DOT) de>:
| Quote: | Hello,
This morning I stumbled about several sprinkles of probably unintended
occurrences of historical traces of ios which is now defined by the typedef
typedef basic_ios<char> ios;
instead of the probably intended ios_base in Our most
recent Holy Standard (ISO/IEC 14882 2nd ed 2003). Strictly speaking all
these occurrences are still correct because ios_base is a public superclass
of the class template basic_ios, but also strictly speaking they cause
unnecessary
dependences on the basic_ios<char> class instead of the more neutral
ios_base class.
|
<snip>
| Quote: | so here is the list of occurrences I found:
21.3.7.9/p. 2a "[..], it calls is.setstate(ios::failbit),[..]"
|
<snip other examples>
I use ios in place of ios_base to access the ios_base's nested types and
constants because it saves typing five characters, one of which requires a shift
(on my keyboard). I think this use is idiomatic, and I don't see anything wrong
with the standard using it.
The real defect, IMO, is that these types and constants are defined in a class
rather than a namespace, and so cannot be made available in <iosfwd>.
Jonathan
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Daniel Krügler
Guest
|
| Posted: Mon Sep 20, 2004 10:44 am Post subject: Re: Traces left of ios in current C++ Standard |
|
|
Good morning Jonathan Turkanis,
Jonathan Turkanis schrieb:
| Quote: | I use ios in place of ios_base to access the ios_base's nested types and
constants because it saves typing five characters, one of which requires a shift
(on my keyboard). I think this use is idiomatic, and I don't see anything wrong
with the standard using it.
|
I don't find such a reasoning very convincing. Just because you don't
like to type five more characters is
not a rule which must be manifested into the standard. Actually the
proposed change does not influence
your personal style of writing and you can write as much ios as you want 
The reasons for the proposed changes are:
- Consistency of the standard itself (Don't use ios here and Ios_base
there, if both occurences should
have equivalent meanings)
- Not to introduce unnecessary dependencies on a specialized class template.
| Quote: | The real defect, IMO, is that these types and constants are defined in a class
rather than a namespace, and so cannot be made available in <iosfwd>.
|
Maybe, but such a change is somewhat stronger than the proposed one.
Furtheron: I am not sure, whether
the usage of a namespace would be better, than a complete class
definition, **which only** provides
the type and constant definitions of ios_base. This could be realized by
separating the current contents
of ios_base into a structure containing these typedefs and constants
(That structure could be provided in
<iosfwd> without introducing to much coupling) and the remaining part of
ios_base which is placed in
<ios> as before.
Greetings from Bremen,
Daniel
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Jonathan Turkanis
Guest
|
| Posted: Tue Sep 21, 2004 1:01 am Post subject: Re: Traces left of ios in current C++ Standard |
|
|
""Daniel Krügler (ne Spangenberg)"" <dsp (AT) bdal (DOT) de> wrote
| Quote: | Good morning Jonathan Turkanis,
Jonathan Turkanis schrieb:
I use ios in place of ios_base to access the ios_base's nested types and
constants because it saves typing five characters, one of which requires a
shift
(on my keyboard). I think this use is idiomatic, and I don't see anything
wrong
with the standard using it.
I don't find such a reasoning very convincing. Just because you don't
like to type five more characters is
not a rule which must be manifested into the standard.
|
I failed to mention a better reason: it also saves reading five more characters.
:-)
| Quote: | Actually the
proposed change does not influence
your personal style of writing and you can write as much ios as you want
|
Of course. But it is not just my style of writing. Josuttis has this to say:
"Of course, it is also possible to use a class derived from ios_base [to access
the constants]. These constants were defined in the class ios in old
implementations. Because ios is a type derived from ios_base and its use
involves less typing, the use often looks like this:
std::ios::eofbit"
(The C++ Standard Librar. p 598)
| Quote: | The reasons for the proposed changes are:
- Consistency of the standard itself (Don't use ios here and Ios_base
there, if both occurences should
have equivalent meanings)
- Not to introduce unnecessary dependencies on a specialized class template.
The real defect, IMO, is that these types and constants are defined in a
class
rather than a namespace, and so cannot be made available in <iosfwd>.
Maybe, but such a change is somewhat stronger than the proposed one.
|
I wasn't suggesting a defect report would be possible. Perhaps a future version
of the standard could define these types and constants in namespace std::io, and
let the associated members of ios_base be typedefs.
| Quote: | Furtheron: I am not sure, whether
the usage of a namespace would be better, than a complete class
definition, **which only** provides
the type and constant definitions of ios_base.
|
A namespace would be better because you could then say
using namespace io;
within a function definition and then use openmode, seekdir, etc freely.
| Quote: | Greetings from Bremen,
Daniel
|
Greetings from (dare I say?) Salt Lake City,
Jonathan
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
