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. 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.

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

""Daniel Kr   gler (ne Spangenberg)"" <dsp@bdal.de> wrote in message
news:414e8dd7$0$298$4d4ebb8e@businessnews.de.uu.net...
> 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.
:-)

> 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)

> 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.

> 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.

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

Hello,

This morning I stumbled about several sprinkles of probably unintended
occurrences of historical traces of ios which is now defined by the typed=
ef

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 supercla=
ss
of the class template basic_ios, but also strictly speaking they cause=20
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=20
is.setstate(ios::failbit)[..]"

26.2.6/p. 13 "[..]If bad input is encountered, calls=20
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=20
ios::badbit is turned on (281)
in *this=92s 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=20
is turned on (284)
in *this=92s 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=20
setstate(ios::failbit),
which might throw an exception. If an exception is thrown during output,=20
then ios::badbit is turned
on (294) in *this=92s 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=20
ios::badbit is turned on (297a) in
*this=92s error state.[..]"

Footnote 297a: "without causing an ios::failure to be thrown."

Table 104, table 105

D.7.1.3/p. 16: "[..]
=97 If (which & ios::in) !=3D 0, positions the input sequence.
=97 If (which & ios::out) !=3D 0, positions the output sequence.
[..]"


Recommended resolution: Replace the corresponding occurrences of ios by=20
by ios_base.

Greetings from Bremen,

Daniel Kr=FCgler

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

""Daniel Kr   gler (ne Spangenberg)"" <dsp@bdal.de>:
> 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>

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