>
> > > typedef struct {
> > >     unsigned char __parse_size:3;
> > >     unsigned char __dummy:4;
> > >     unsigned char __shift_state:1;
> > >     char __parse_buf[7];
> > > } mbstate_t;
> >
> > If that is the definition that aCC 3.30 uses, then there's no
> > justification for the reported error message. That is indeed a POD
type.
>
> I seriously doubt that aC++ 3.30 should not be able to treat the
above
> definition of mbstate_t as a POD struct, though, without acccess to
> that compiler any such judgement is pretty much subjective. Can
anyone
> who has access to aC++ 3.30 shed any light on this?
>


First, thank you to Martin, Andrei, and James for the answers.

Second, I mentioned that this happened when I attempted to compile the
code I listed.  Actually it happened when someone with whom I was
corresponding (via email) attempted to compile my code and got the
error I listed.  I will see if I can get him to send me the definition
of mbstate_t (and possibly codecvt) from aC++ 3.30.



---
[ 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.research.att.com/~austern/csc/faq.html                ]

> > Can anyone
> > who has access to aC++ 3.30 shed any light on this?
> >
>
>
> First, thank you to Martin, Andrei, and James for the answers.
>
> Second, I mentioned that this happened when I attempted to compile
the
> code I listed.  Actually it happened when someone with whom I was
> corresponding (via email) attempted to compile my code and got the
> error I listed.  I will see if I can get him to send me the
definition
> of mbstate_t (and possibly codecvt) from aC++ 3.30.

I managed to get in contact with the aC++ 3.30 developer.  He reported
to me that after he applied a compiler patch to aC++ 3.30, the
compiler error for mbstate_t went away.  Lacking the <wchar.h> and
<locale> headers (which I asked him to send me) I don't know what
caused the problem or why it went away.

At any rate, I still wondered about the portability of my code anyway.
I take away from this that I can legally do the following and expect
it to compile on all platforms
    mbstate_t st = { 0 };

Thanks again for your answers.



Joe O'




---
[ 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.research.att.com/~austern/csc/faq.html                ]

Joe O'Leary wrote:
>
> According to the standard 22.1.1.1.1, every implementation of the
> library must provide two specializations of the codecvt facet template
>
>     codecvt<char, char, mbstate_t>
>     codecvt<wchar_t, char, mbstate_t>
>
> I am using this facet and am faced with the question -- how do I
> portably initialize an 'mbstate_t' to the the "initial
> conversion state" for use.  When coding with Visual C++ and DinkumWare
> or STLPort, I do it as follows
>
>      typedef std::codecvt<wchar_t, char, mbstate_t> SSCodeCvt;
>     ...
>      SSCodeCvt::state_type st= { 0 };

This is portable and guaranteed to zero-initialize the object:

    mbstate_t state = mbstate_t ();

Regards
Martin

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Joe O'Leary" <joleary@artisoft.com> wrote in message news:<Is8V6.4156$Il5.525173@newsread1.prod.itd.earthlink.net>...

> According to the standard 22.1.1.1.1, every implementation of the
> library must provide two specializations of the codecvt facet template
>
>     codecvt<char, char, mbstate_t>
>     codecvt<wchar_t, char, mbstate_t>
>
> I am using this facet and am faced with the question -- how do I
> portably initialize an 'mbstate_t' to the the "initial
> conversion state" for use.  When coding with Visual C++ and DinkumWare
> or STLPort, I do it as follows
>
>      typedef std::codecvt<wchar_t, char, mbstate_t> SSCodeCvt;
>     ...
>      SSCodeCvt::state_type st= { 0 };
>
> I always thought that this was the proper way to initialize an
> mbstate_t variable.  However when I try to compile this on HP-UX aCC
> 3.30, I get the following error
>
>     Error 275: "StdString.h", line 484 # Cannot use
>     an initializer list with a class that is derived or has
>     a constructor, virtual functions, or private/protected
>     members
>
> So it appears that mbstate_t is not a simple POD type (or a structure
> consisting of only POD types) on this platform.

Which is utterly wrong, mbstate_t shall be a POD type (look at
21.4/2). aCC 3.30 on HP-UX appears to have a non-standard
implementation of the Standard C++ library.


> So can anyone please tell me what is a platform independent way that I
> may *initialize* an mbstate_t to the initial conversion state?

There are a few portable ways of initializing an object of type
'mbstate_t' to the initial conversion state. Given that 'mbstate_t' is
a non-array POD object type and that "a zero-valued mbstate_t object
is (at least) one way to describe the initial conversion state", you
can use such constructs as:

   mbstate_t   st1 = {   0   };
   mbstate_t   st2 = mbstate_t();

Seeing your code snippet,
>      typedef std::codecvt<wchar_t, char, mbstate_t> SSCodeCvt;
>     ...
>      SSCodeCvt::state_type st= { 0 };
however, makes me think that you are after writing generic code, since
you prefer 'SSCodeCvt::state_type' to 'mbstate_t'. If you want to
stick to that, you need to realize that the only requirements that the
Standard puts on the type 'typename char_traits<T>::state_type' is
that it be CopyConstructible (e.g. it doesn't have to be POD or a
DefaultConstructible type).

It follows that the only generic way of initializing a 'typename
char_traits<T>::state_type' object is by direct-initializing it with
an expression (that refers to an already initialized object) of type
'typename char_traits<T>::state_type' or const-qualified 'typename
char_traits<T>::state_type'.


Regards,

Andrei Iltchenko.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Joe O'Leary wrote:
...
> conversion state" for use.  When coding with Visual C++ and DinkumWare
> or STLPort, I do it as follows
>
>      typedef std::codecvt<wchar_t, char, mbstate_t> SSCodeCvt;
>     ...
>      SSCodeCvt::state_type st= { 0 };
>
> I always thought that this was the proper way to initialize an
> mbstate_t variable.  However when I try to compile this on HP-UX aCC
> 3.30, I get the following error
>
>     Error 275: "StdString.h", line 484 # Cannot use
>     an initializer list with a class that is derived or has
>     a constructor, virtual functions, or private/protected
>     members
>
> So it appears that mbstate_t is not a simple POD type (or a structure
> consisting of only POD types) on this platform.

I think that's a non-conforming implementation. The definition of
mbstate_t is not provided by the C++ standard. It's included only by
reference from the C90 standard. That in itself should be sufficient to
guarantee that mbstate_t must be a POD type.

> So can anyone please tell me what is a platform independent way that I
> may *initialize* an mbstate_t to the initial conversion state?

I don't have a copy of the C90 standard, but 7.24.6p3 of the C99
standard specifies:

"The initial conversion state corresponds, for a conversion in either
direction, to the beginning of a new multibyte character in the initial
shift state. A zero-valued mbstate_t object is (at least) one way to
describe an initial conversion state. A zero-valued mbstate_t object can
be used to initiate conversion involving any multibyte character
sequence, in any LC_CTYPE category setting."

Therefore the one absolutely portable way to initialize an mbstate_t is
with a value of 0. Since C doesn't have constructors, I don't think a
mbstate_t can be a structure, it has to be a scalar type - otherwise
referring to it as "zero-valued" makes no sense in a C context. That
means that the "{}" around your initializer is redundant.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Martin Sebor <sebor@roguewave.com> wrote in message news:<3B257F87.7627E461@roguewave.com>...
> Joe O'Leary wrote:
> >
> > According to the standard 22.1.1.1.1, every implementation of the
> > library must provide two specializations of the codecvt facet template
> >
> >     codecvt<char, char, mbstate_t>
> >     codecvt<wchar_t, char, mbstate_t>
> >
> > I am using this facet and am faced with the question -- how do I
> > portably initialize an 'mbstate_t' to the the "initial
> > conversion state" for use.  When coding with Visual C++ and DinkumWare
> > or STLPort, I do it as follows
> >
> >      typedef std::codecvt<wchar_t, char, mbstate_t> SSCodeCvt;
> >     ...
> >      SSCodeCvt::state_type st= { 0 };
>
> This is portable and guaranteed to zero-initialize the object:
>
>     mbstate_t state = mbstate_t ();
>

Yes, that's correct if the object type is a POD type.

In the case of HP-UX aCC 3.30 implementation of the Standard C++
library, however, that doesn't seem to be the case, so all bets are
off.


Cheers,

Andrei Iltchenko.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

According to the standard 22.1.1.1.1, every implementation of the
library must provide two specializations of the codecvt facet template

    codecvt<char, char, mbstate_t>
    codecvt<wchar_t, char, mbstate_t>

I am using this facet and am faced with the question -- how do I
portably initialize an 'mbstate_t' to the the "initial
conversion state" for use.  When coding with Visual C++ and DinkumWare
or STLPort, I do it as follows

     typedef std::codecvt<wchar_t, char, mbstate_t> SSCodeCvt;
    ...
     SSCodeCvt::state_type st= { 0 };

I always thought that this was the proper way to initialize an
mbstate_t variable.  However when I try to compile this on HP-UX aCC
3.30, I get the following error

    Error 275: "StdString.h", line 484 # Cannot use
    an initializer list with a class that is derived or has
    a constructor, virtual functions, or private/protected
    members

So it appears that mbstate_t is not a simple POD type (or a structure
consisting of only POD types) on this platform.

So can anyone please tell me what is a platform independent way that I
may *initialize* an mbstate_t to the initial conversion state?

Thanks

Joe O'


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Andrei Iltchenko wrote:
>
...
> > So it appears that mbstate_t is not a simple POD type (or a structure
> > consisting of only POD types) on this platform.
>
> Which is utterly wrong, mbstate_t shall be a POD type (look at
> 21.4/2). aCC 3.30 on HP-UX appears to have a non-standard
> implementation of the Standard C++ library.

I'm not sure where in 21.4 it says that mbstate_t shall be a POD type,
but even if it did, I'm not seeing any problems compiling either form
of initialization with 3.30, though. mbstate_t is defined in <cwchar>
like so

typedef struct {
    unsigned char __parse_size:3;
    unsigned char __dummy:4;
    unsigned char __shift_state:1;
    char __parse_buf[7];
} mbstate_t;

The bogus definition provided in the private header rw/iotraits
is there for backward compatibility reasons and should be #ifdef'ed
out.

Btw., the mbstate_t you get on HP-UX 11.00 isn't of much use since
there are no reentrant C library functions that take it as an argument.
HP-UX 11i provides these.

Regards
Martin

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Martin Sebor wrote:
>
> Andrei Iltchenko wrote:
> >
> ...
> > > So it appears that mbstate_t is not a simple POD type (or a structure
> > > consisting of only POD types) on this platform.
> >
> > Which is utterly wrong, mbstate_t shall be a POD type (look at
> > 21.4/2). aCC 3.30 on HP-UX appears to have a non-standard
> > implementation of the Standard C++ library.
>
> I'm not sure where in 21.4 it says that mbstate_t shall be a POD type,

21.4p2 says "The contents of these headers are the same as the Standard
C library headers <ctype.h>, <wctype.h>, <string.h>, <wchar.h>, and
<stdlib.h> respectively, with the following modifications:". mbstate_t
is defined in <wchar.h>, and none of the listed modifications affect
that type. Since there's no way to define a type in C that doesn't
qualify as a C++ POD type, it is implied that mbstate_t must be a POD
type. I think this is basically true, but I suspect there may be a hole
somewhere in that logic.

> typedef struct {
>     unsigned char __parse_size:3;
>     unsigned char __dummy:4;
>     unsigned char __shift_state:1;
>     char __parse_buf[7];
> } mbstate_t;

If that is the definition that aCC 3.30 uses, then there's no
justification for the reported error message. That is indeed a POD type.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3B26ACD0.EBD94510@wizard.net>...
> Martin Sebor wrote:
> >
> > Andrei Iltchenko wrote:
> > >
>  ...
> > > > So it appears that mbstate_t is not a simple POD type (or a structure
> > > > consisting of only POD types) on this platform.
> > >
> > > Which is utterly wrong, mbstate_t shall be a POD type (look at
> > > 21.4/2). aCC 3.30 on HP-UX appears to have a non-standard
> > > implementation of the Standard C++ library.
> >
> > I'm not sure where in 21.4 it says that mbstate_t shall be a POD type,
>
> 21.4p2 says "The contents of these headers are the same as the Standard
> C library headers <ctype.h>, <wctype.h>, <string.h>, <wchar.h>, and
> <stdlib.h> respectively, with the following modifications:". mbstate_t
> is defined in <wchar.h>, and none of the listed modifications affect
> that type. Since there's no way to define a type in C that doesn't
> qualify as a C++ POD type, it is implied that mbstate_t must be a POD
> type. I think this is basically true, but I suspect there may be a hole
> somewhere in that logic.

This reasoning is absolutely correct and I meant exactly that.


> > typedef struct {
> >     unsigned char __parse_size:3;
> >     unsigned char __dummy:4;
> >     unsigned char __shift_state:1;
> >     char __parse_buf[7];
> > } mbstate_t;
>
> If that is the definition that aCC 3.30 uses, then there's no
> justification for the reported error message. That is indeed a POD type.

I seriously doubt that aC++ 3.30 should not be able to treat the above
definition of mbstate_t as a POD struct, though, without acccess to
that compiler any such judgement is pretty much subjective. Can anyone
who has access to aC++ 3.30 shed any light on this?


Cheers,

Andrei Iltchenko.

---
[ 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.research.att.com/~austern/csc/faq.html                ]