Hi,
In article <38603F3E.FF8C4969@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:

> I don't see how streampos can be implementation-defined if it's
defined
> by the standard to be fpos<mbstate_t>. It seems to me that it has to
be
> one or the other; different parts of the standard support each
> interpretation. I wish someone would give an authoritative opinion on
> the matter. All you've given me are guesses.

Implementation defined only means that the implementation has to
document what was choosen to implement the feature. This does not
necessarily mean that there is much freedome in the choices. Since
'fpos<mbstate_t>' depends on an implementation defined type, namely
'mbstate_t', this might be sufficient to consider 'fpos<mbstate_t>' to
be implementation defined, too.

Since I can't see a different way than implementing both 'streampos' and
'wstreampos' as 'fpos<mbstate_t>', I would consider the implementation
defined types to be pretty fixed... I think there are other situations
where the standard says that things are implementation defined but in
fact there is only one choice.

If you want a more authoritive answer, you can file a defect report and
wait for its resolution. However, my guess is that it would result in
basically the same I have said already, partly because I'm working in
the library working group.


> > Sure. But the standard does not require the use of '_STATE'. This is
> > just a note (if I remember correctly; I don't have the standard
handy).
>
> Correct: 27.2 p10 is part of a note, and hence not normative. However,
> my point is that 27.2 p10 is a pointless note, if your interpretation
is
> the one intended.

Yes, it may be pointless and should potentially be removed. However, it
does not contradict anything in the standard and thus is not strictly a
defect.
--
<mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>


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              ]

Dietmar Kuehl wrote:
>
> Hi,
> In article <38603F3E.FF8C4969@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
>
> > I don't see how streampos can be implementation-defined if it's
> defined
> > by the standard to be fpos<mbstate_t>. It seems to me that it has to
> be
> > one or the other; different parts of the standard support each
.....
> Since I can't see a different way than implementing both 'streampos' and
> 'wstreampos' as 'fpos<mbstate_t>', I would consider the implementation

Section 21.1.3.2 p3 describes the relevant situation: "... if the
implementation supports no shift encoding in narrow-oriented iostreams
but supports one or more shift encodings in wide-oriented streams." In
that case, an implementation would have to implement wstreampos as
something equivalent to fpos<mbstate_t>, but which doesn't waste space
to store an mbstate_t object, since it's not needed.


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

I somehow managed to deliver the following message with many important
words accidentally deleted.

James Kuyper wrote:
>
> Dietmar Kuehl wrote:
> >
> > Hi,
> > In article <38603F3E.FF8C4969@wizard.net>,
> >   James Kuyper <kuyper@wizard.net> wrote:
> >
> > > I don't see how streampos can be implementation-defined if it's
> > defined
> > > by the standard to be fpos<mbstate_t>. It seems to me that it has to
> > be
> > > one or the other; different parts of the standard support each
> .....
> > Since I can't see a different way than implementing both 'streampos' and
> > 'wstreampos' as 'fpos<mbstate_t>', I would consider the implementation
>
> Section 21.1.3.2 p3 describes the relevant situation: "... if the
> implementation supports no shift encoding in narrow-oriented iostreams
> but supports one or more shift encodings in wide-oriented streams." In
> that case, an implementation would have to implement wstreampos as
> something equivalent to fpos<mbstate_t>, ...

The missing words were:

but streampos can be implemented as a different type which meets the
other relevant requirements,

> ... but which doesn't waste space
> to store an mbstate_t object, since it's not needed.

Sorry about the confusion. I was tired from a long drive home after
visiting relatives for Christmas.
Happy Holidays!
---
[ 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              ]

Hi,
In article <385AE968.42B3C278@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> The standard distinguishes between the "defined types" int_type,
> pos_type, off_type, and state_type, (21.1.3.1 p2, 21.1.3.2 p1) and the
> "implementation-defined" types streampos and streamoff (21.1.3.1 p3-4,
> 27.4.1 p1) and wstreampos (21.1.3.2 p2). I think this distinction
means
> that for the ones labeled implementation-defined the typedefs given
are
> to be thought of as examples, and the only requirements they actually
> have to meet are the ones for POS_T and OFF_T.

I don't think that the standard gives a different choice than 'pos_type'
being 'fpos<mstate_t>' for 'char_traits<cT>' if 'cT' is 'char' or
'wchar_t'. However, the implementation is free to choose appropriate
definitions for all other character types and traits types (well, the
traits define the 'pos_type'.

My guess is that the freedome with respect to the types of 'streampos'
and 'wstreampos' is a relict from the time when the streams were not
templatized.

> Otherwise, in what sense
> are they implementation-defined? However, I have to say that this is
> very confusing. I find sections 21 (Strings library) and 27
> (Input/output library) to be the two most confusing sections in the
> entire standard.

Really? I think that Chapter 22 (locales) is the worst one. However, the
most complex class I have at least tried to implement is 'basic_filebuf'
but mostly because it has to cope with these code conversion facet.

> If you are right, then 27.2 p10 is needlessly complicated:
>
> | This synopsis suggests a circularity between streampos and
> | char_traits<char>. An implementation can avoid this by
> | substituting equivalent types. One way to do this might be
> |
> | template<class stateT> class fpos { ... }; //depends on nothing
> | typdef ... _STATE;; // implementation private declaration of stateT
> | typedef fpos<_STATE> streampos;
> |
> | template<> struct char_traits<char>{
> | typedef streampos pos_type;
> | // ...
> | }
>
> Now, if streampos were required to be fpos<mbstate_t>, then there'd be
> no need for the _STATE business. mbstate_t serves the same purpose
> (removing the circular dependencies) just as well as _STATE does.

Sure. But the standard does not require the use of '_STATE'. This is
just a note (if I remember correctly; I don't have the standard handy).
The major reason for the state business is that a different character
or traits type might use a different 'pos_type'. However, in this case
the standard make only few guarantees...
--
<mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>


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              ]

Dietmar Kuehl wrote:
....
> In article <385AE968.42B3C278@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
....
> I don't think that the standard gives a different choice than 'pos_type'
> being 'fpos<mstate_t>' for 'char_traits<cT>' if 'cT' is 'char' or

I don't see how streampos can be implementation-defined if it's defined
by the standard to be fpos<mbstate_t>. It seems to me that it has to be
one or the other; different parts of the standard support each
interpretation. I wish someone would give an authoritative opinion on
the matter. All you've given me are guesses.

....
> > very confusing. I find sections 21 (Strings library) and 27
> > (Input/output library) to be the two most confusing sections in the
> > entire standard.
>
> Really? I think that Chapter 22 (locales) is the worst one. ...

You're right; I forgot that one.

....
> > If you are right, then 27.2 p10 is needlessly complicated:
> >
> > | This synopsis suggests a circularity between streampos and
> > | char_traits<char>. An implementation can avoid this by
> > | substituting equivalent types. One way to do this might be
> > |
> > | template<class stateT> class fpos { ... };  //depends on nothing
> > | typdef ... _STATE;; // implementation private declaration of stateT
> > | typedef fpos<_STATE> streampos;
> > |
> > | template<> struct char_traits<char>{
> > |     typedef streampos pos_type;
> > |     // ...
> > | }
> >
> > Now, if streampos were required to be fpos<mbstate_t>, then there'd be
> > no need for the _STATE business. mbstate_t serves the same purpose
> > (removing the circular dependencies) just as well as _STATE does.
>
> Sure. But the standard does not require the use of '_STATE'. This is
> just a note (if I remember correctly; I don't have the standard handy).

Correct: 27.2 p10 is part of a note, and hence not normative. However,
my point is that 27.2 p10 is a pointless note, if your interpretation is
the one intended.


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

In article <385196E1.4FEBC7BF@wizard.net>,
  "James Kuyper Jr." <kuyper@wizard.net> wrote:
> The standard describes traits::off_type and std::streamoff as typedefs
> for OFF_T. The requirements for fpos<> in table 88 say that various
> things must have a type of OFF_T. However, OFF_T is nowhere actually
> defined. Is an implementation required to define a type that's
actually
> named OFF_T, or is OFF_T merely a placeholder in the standard for the
> actual type?

The first question is easy to answer: 'OFF_T' is just a placeholder, it
is not a type defined anywhere in the standard C++ library.

> Section 27.1.2 says: "The classes of clause 27 with template arguments
> charT and traits are described as if traits::pos_type and
> traits::off_type are streampos and streamoff respectively. Except as
> noted explicitly below, their behavior when traits::pos_type and
> traits::off_type are other types is implementation-defined."
>
> Now, char_traits<wchar_t>::pos_type is a typdef for wstreampos
> (21.1.3.2), which may be different from streampos (21.2p3).

Nope! In 27.2 (lib.iostream.forward) the following is listed:

  typedef fpos<char_traits<char>::state_type>    streampos;
  typedef fpos<char_traits<wchar_t>::state_type> wstreampos;

So 'streampos' and 'wstreampos' can only be different types if the
two 'state_type's in 'char_traits' are different. However, in 21.1.3.1
(lib.char.traits.specializations.char) and in 21.1.3.2
(lib.char.traits.specializations.wchar.t) it says

  typedef mbstate_t state_type;

Thus, both 'streampos' and 'wstreampos' have no other choice than being
'fpos<mbstate_t>'!

> Does this
> mean that the behavior of most of the I/O library is
> implementation-defined when traits is char_traits<wchar_t>? Does this
> mean implementation-defined, above andbeyond the already
> implementation-defined aspects of wide strings?

Since the types are effectively required to be identical, no additional
implementation specific stuff is the result.

> Also, what behavior is it referring to, when it says "Except as noted
> explicitly below"? In other words, which particular aspects of the
> behavior are not implementation-defined? I'm not sure what constitutes
a
> explicit note in this context.

This one is harder to answer... My guess is that it was just a statement
in case behavior is explicitly defined to be not implementation
defined but this statement is not really used. At least, I'm not aware
of anything which explicitly defined even if the types do not match.
--
<mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>


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              ]

Dietmar Kuehl wrote:
>
> In article <385196E1.4FEBC7BF@wizard.net>,
>   "James Kuyper Jr." <kuyper@wizard.net> wrote:
> > The standard describes traits::off_type and std::streamoff as typedefs
> > for OFF_T. The requirements for fpos<> in table 88 say that various
> > things must have a type of OFF_T. However, OFF_T is nowhere actually
> > defined. Is an implementation required to define a type that's
> actually
> > named OFF_T, or is OFF_T merely a placeholder in the standard for the
> > actual type?
>
> The first question is easy to answer: 'OFF_T' is just a placeholder, it
> is not a type defined anywhere in the standard C++ library.

As I said, that's what I think too. Is there a authoritative source for
that interpretation?

....
> > Now, char_traits<wchar_t>::pos_type is a typdef for wstreampos
> > (21.1.3.2), which may be different from streampos (21.2p3).

Sorry - that last citation should have been 21.1.3.2 p3: "The types
streampos and wstreampos may be different if the implementation supports
no shift encoding in narrow-oriented iostreams but supports one or more
shift encodings in wide-oriented streams." That seems inconsistent with
your response:

> Nope! In 27.2 (lib.iostream.forward) the following is listed:
>
>   typedef fpos<char_traits<char>::state_type>    streampos;
>   typedef fpos<char_traits<wchar_t>::state_type> wstreampos;
>
> So 'streampos' and 'wstreampos' can only be different types if the
> two 'state_type's in 'char_traits' are different. However, in 21.1.3.1
> (lib.char.traits.specializations.char) and in 21.1.3.2
> (lib.char.traits.specializations.wchar.t) it says
>
>   typedef mbstate_t state_type;
>
> Thus, both 'streampos' and 'wstreampos' have no other choice than being
> 'fpos<mbstate_t>'!

The standard distinguishes between the "defined types" int_type,
pos_type, off_type, and state_type, (21.1.3.1 p2, 21.1.3.2 p1) and the
"implementation-defined" types streampos and streamoff (21.1.3.1 p3-4,
27.4.1 p1) and wstreampos (21.1.3.2 p2). I think this distinction means
that for the ones labeled implementation-defined the typedefs given are
to be thought of as examples, and the only requirements they actually
have to meet are the ones for POS_T and OFF_T. Otherwise, in what sense
are they implementation-defined? However, I have to say that this is
very confusing. I find sections 21 (Strings library) and 27
(Input/output library) to be the two most confusing sections in the
entire standard.

If you are right, then 27.2 p10 is needlessly complicated:

| This synopsis suggests a circularity between streampos and
| char_traits<char>. An implementation can avoid this by
| substituting equivalent types. One way to do this might be
|
| template<class stateT> class fpos { ... }; //depends on nothing
| typdef ... _STATE;; // implementation private declaration of stateT
| typedef fpos<_STATE> streampos;
|
| template<> struct char_traits<char>{
| typedef streampos pos_type;
| // ...
| }

Now, if streampos were required to be fpos<mbstate_t>, then there'd be
no need for the _STATE business. mbstate_t serves the same purpose
(removing the circular dependencies) just as well as _STATE does.
---
[ 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              ]

In article <385196E1.4FEBC7BF@wizard.net>,
  "James Kuyper Jr." <kuyper@wizard.net> wrote:
> The standard describes traits::off_type and std::streamoff as typedefs
> for OFF_T. The requirements for fpos<> in table 88 say that various
> things must have a type of OFF_T. However, OFF_T is nowhere actually
> defined. Is an implementation required to define a type that's
actually
> named OFF_T, or is OFF_T merely a placeholder in the standard for the
> actual type?

The first question is easy to answer: 'OFF_T' is just a placeholder, it
is not a type defined anywhere in the standard C++ library.

> Section 27.1.2 says: "The classes of clause 27 with template arguments
> charT and traits are described as if traits::pos_type and
> traits::off_type are streampos and streamoff respectively. Except as
> noted explicitly below, their behavior when traits::pos_type and
> traits::off_type are other types is implementation-defined."
>
> Now, char_traits<wchar_t>::pos_type is a typdef for wstreampos
> (21.1.3.2), which may be different from streampos (21.2p3).

Nope! In 27.2 (lib.iostream.forward) the following is listed:

  typedef fpos<char_traits<char>::state_type>    streampos;
  typedef fpos<char_traits<wchar_t>::state_type> wstreampos;

So 'streampos' and 'wstreampos' can only be different types if the
two 'state_type's in 'char_traits' are different. However, in 21.1.3.1
(lib.char.traits.specializations.char) and in 21.1.3.2
(lib.char.traits.specializations.wchar.t) it says

  typedef mbstate_t state_type;

Thus, both 'streampos' and 'wstreampos' have no other choice than being
'fpos<mbstate_t>'!

> Does this
> mean that the behavior of most of the I/O library is
> implementation-defined when traits is char_traits<wchar_t>? Does this
> mean implementation-defined, above andbeyond the already
> implementation-defined aspects of wide strings?

Since the types are effectively required to be identical, no additional
implementation specific stuff is the result.

> Also, what behavior is it referring to, when it says "Except as noted
> explicitly below"? In other words, which particular aspects of the
> behavior are not implementation-defined? I'm not sure what constitutes
a
> explicit note in this context.

This one is harder to answer... My guess is that it was just a statement
in case behavior is explicitly defined to be not implementation
defined but this statement is not really used. At least, I'm not aware
of anything which explicitly defined even if the types do not match.
--
<mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>


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              ]

Hi,
In article <385196E1.4FEBC7BF@wizard.net>,
  "James Kuyper Jr." <kuyper@wizard.net> wrote:
> The standard describes traits::off_type and std::streamoff as typedefs
> for OFF_T. The requirements for fpos<> in table 88 say that various
> things must have a type of OFF_T. However, OFF_T is nowhere actually
> defined. Is an implementation required to define a type that's
actually
> named OFF_T, or is OFF_T merely a placeholder in the standard for the
> actual type?

The first question is easy to answer: 'OFF_T' is just a placeholder, it
is not a type defined anywhere in the standard C++ library.

> Section 27.1.2 says: "The classes of clause 27 with template arguments
> charT and traits are described as if traits::pos_type and
> traits::off_type are streampos and streamoff respectively. Except as
> noted explicitly below, their behavior when traits::pos_type and
> traits::off_type are other types is implementation-defined."
>
> Now, char_traits<wchar_t>::pos_type is a typdef for wstreampos
> (21.1.3.2), which may be different from streampos (21.2p3).

Nope! In 27.2 (lib.iostream.forward) the following is listed:

  typedef fpos<char_traits<char>::state_type>    streampos;
  typedef fpos<char_traits<wchar_t>::state_type> wstreampos;

So 'streampos' and 'wstreampos' can only be different types if the
two 'state_type's in 'char_traits' are different. However, in 21.1.3.1
(lib.char.traits.specializations.char) and in 21.1.3.2
(lib.char.traits.specializations.wchar.t) it says

  typedef mbstate_t state_type;

Thus, both 'streampos' and 'wstreampos' have no other choice than being
'fpos<mbstate_t>'!

> Does this
> mean that the behavior of most of the I/O library is
> implementation-defined when traits is char_traits<wchar_t>? Does this
> mean implementation-defined, above andbeyond the already
> implementation-defined aspects of wide strings?

Since the types are effectively required to be identical, no additional
implementation specific stuff is the result.

> Also, what behavior is it referring to, when it says "Except as noted
> explicitly below"? In other words, which particular aspects of the
> behavior are not implementation-defined? I'm not sure what constitutes
a
> explicit note in this context.

This one is harder to answer... My guess is that it was just a statement
in case behavior is explicitly defined to be not implementation
defined but this statement is not really used. At least, I'm not aware
of anything which explicitly defined even if the types do not match.
--
<mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>


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              ]

The standard describes traits::off_type and std::streamoff as typedefs
for OFF_T. The requirements for fpos<> in table 88 say that various
things must have a type of OFF_T. However, OFF_T is nowhere actually
defined. Is an implementation required to define a type that's actually
named OFF_T, or is OFF_T merely a placeholder in the standard for the
actual type?

Section 27.1.2 says: "The classes of clause 27 with template arguments
charT and traits are described as if traits::pos_type and
traits::off_type are streampos and streamoff respectively. Except as
noted explicitly below, their behavior when traits::pos_type and
traits::off_type are other types is implementation-defined."

Now, char_traits<wchar_t>::pos_type is a typdef for wstreampos
(21.1.3.2), which may be different from streampos (21.2p3). Does this
mean that the behavior of most of the I/O library is
implementation-defined when traits is char_traits<wchar_t>? Does this
mean implementation-defined, above andbeyond the already
implementation-defined aspects of wide strings?

Also, what behavior is it referring to, when it says "Except as noted
explicitly below"? In other words, which particular aspects of the
behavior are not implementation-defined? I'm not sure what constitutes a
explicit note in this context.
---
[ 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              ]