Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:

>Valentin Bonnard wrote:
>
>[...]
>
>> I think the answer is (1) and (2), not (3). How do you
>> implement wcout under DOS ?
>
>make char the underlying type of wchar_t, and make wcout identical
>to cout (except for using wchar_t in the interface). The code

I don't think it is necessary to bee so restrictive. If the underlying
type of wchar_t is short int, then you can use 16-bit character sets.
There is no difficulty in writing a stream of 16-bit words to a file in
DOS or most other operating systems. True, your friendly native text
editor won't understand it (it would interpret every character as two)
but you wouldn't expect it to. As far as the OS is concerned a wide
character stream is just a plain data file that just happens to have an
even number of bytes. Whether you can write wide characters to a file is
independent of whether the OS allows *file names* containing wide
characters. Thus, there is no conflict between supporting wide-
characters streams but not supporting wide-character file names. The
latter is a reasonable extension for those OS's that allow it.

One caveat: since 16-bit characters are not directly supported by many
OS's, there is always a potential portability problem stemming from
byte-order incompatabilities between systems. If the file is being used
on only on one CPU/OS combination, the issue is moot, otherwise a
standard (e.g. network byte order == big-endian) should be adopted for
representing 16-bit characters in 8-bit character streams. Reading a
stream with incompatabile newline sequences (CR vs. LF vs. CR-LF) is
positively trivial compared to reading a stream with every pair of bytes
swapped, if you don't know in advance what you're dealing with.

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.


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

Valentin Bonnard wrote:

[...]

> I think the answer is (1) and (2), not (3). How do you
> implement wcout under DOS ?

make char the underlying type of wchar_t, and make wcout identical
to cout (except for using wchar_t in the interface). The code
of cout and wcout could be shared (except for addresses, but this
can be handled with nops at the beginning of each function; the
wcout functions would then be slightly less efficient ;-))


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

Nathan Myers <ncm@nospam.cantrip.org> wrote:
: Oleg Zabluda  <zabluda@math.psu.edu> wrote:
: >Valentin Bonnard <bonnardv@pratique.fr> wrote:
: >: Nathan Myers wrote:
: >: > It is a "permitted extension" to provide more constructors,
: >: > as long as it can't change the behavior of a conforming program.
: >
: >: class SillyConverter
: >: {
: >: public:
: >:     operator const char* ();
: >:     operator const charT* ();
: >:     operator string ();
: >: } s;
: >
: >: ifstream ifs (s);
: >
: >Hmm... It seems like your example shows that the "permitted extention",
: >Nathan refers to, is actually _never_ permitted.

: It might seem that way to some people, but it doesn't seem
: that way to me.  A little thought will reveal a way to avoid
: any problems of overloading with existing constructors.

[ Slightly changing subject, hopefully nobody will notice ]

I presume for someone of your intellect it wouldn't be too hard
to explain to unworthy me why anyone needs a permission to implement
an unportable extension anyway?

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard  <bonnardv@pratique.fr> wrote:
>Nathan Myers wrote:
>> A little thought will reveal a way to avoid
>> any problems of overloading with existing constructors.
>
>The implementation can define a type:
>
>struct wchar_t_construction {};
>filebuf::filebuf (const wchar_t*, wchar_t_construction);
>
>But it would make the code completly unportable between
>implementations which support that (as they would have
>a different syntax for the same semantic: open a file).

That's the nature of extensions.  If enough different
implementors choose the same interface you get a degree
of portability.

>The intent of the standard is:
>(1) to standardise ?
>(2) to support wchar_t ?
>(3) to provide the minimum implementable on all systems ?
>
>I think the answer is (1) and (2), not (3). How do you
>implement wcout under DOS ?

The intent of the standard is the intent of the members of
the standard committee.  Nobody proposed constructors from
wstring (or string, for that matter).  Maybe at the next
round somebody will propose one or other or both.

Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



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

Nathan Myers (ncm@nospam.cantrip.org) wrote:

> The intent of the standard is the intent of the members of
> the standard committee.  Nobody proposed constructors from
> wstring (or string, for that matter).  Maybe at the next
> round somebody will propose one or other or both.

  Is there a compelling reason _not_ to use strings to pass filenames
  to fstreams? Or was it simply overlooked?

  It's surprising to me that fstreams don't take string arguments. If
  we agree that C-style strings (i.e. null-terminated char arrays) are
  evil, and that C++ Standard Library strings are good, then we should
  (in general) use strings and not char*'s. It therefore seems strange
  that the C++ Standard Library itself does not.

--------------------------------------------------------------------------
Dave Steffen                      Wave after wave will flow with the tide
Dept. of Physics                    And bury the world as it does
Colorado State University         Tide after tide will flow and recede
steffend@lamar.colostate.edu        Leaving life to go on as it was...
       - Peart / RUSH
"The reason that our people suffer in this way....
is that our ancestors failed to rule wisely".   -General Choi, Hong Hi




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

Oleg Zabluda  <zabluda@math.psu.edu> wrote:
>Valentin Bonnard <bonnardv@pratique.fr> wrote:
>: Nathan Myers wrote:
>: > It is a "permitted extension" to provide more constructors,
>: > as long as it can't change the behavior of a conforming program.
>
>: class SillyConverter
>: {
>: public:
>:     operator const char* ();
>:     operator const charT* ();
>:     operator string ();
>: } s;
>
>: ifstream ifs (s);
>
>Hmm... It seems like your example shows that the "permitted extention",
>Nathan refers to, is actually _never_ permitted.

It might seem that way to some people, but it doesn't seem
that way to me.  A little thought will reveal a way to avoid
any problems of overloading with existing constructors.

Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Nathan Myers wrote:
>
> Oleg Zabluda  <zabluda@math.psu.edu> wrote:
> >Valentin Bonnard <bonnardv@pratique.fr> wrote:
> >: Nathan Myers wrote:
> >: > It is a "permitted extension" to provide more constructors,
> >: > as long as it can't change the behavior of a conforming program.
> >
> >: class SillyConverter
> >: {
> >: public:
> >:     operator const char* ();
> >:     operator const charT* ();
> >:     operator string ();
> >: } s;
> >
> >: ifstream ifs (s);
> >
> >Hmm... It seems like your example shows that the "permitted extention",
> >Nathan refers to, is actually _never_ permitted.
>
> It might seem that way to some people, but it doesn't seem
> that way to me.  A little thought will reveal a way to avoid
> any problems of overloading with existing constructors.

Glad to see that you are more intelligent then other people,
Nathan. I am even MORE intelligent !            ;-)
The implementation can define a type:

struct wchar_t_construction {};

filebuf::filebuf (const wchar_t*, wchar_t_construction);

But it would make the code completly unportable between
implementations which support that (as they would have
a different syntax for the same semantic: open a file).

The intent of the standard is:
(1) to standardise ?
(2) to support wchar_t ?
(3) to provide the minimum implementable on all systems ?

I think the answer is (1) and (2), not (3). How do you
implement wcout under DOS ?

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Nathan Myers wrote:
>
> Valentin Bonnard  <bonnardv@pratique.fr> wrote:
> >fstreams ctors only take const char*, not wstring
> >or at least const charT*. Is it intentionnal ?
> >Is it an oversight ?
>
> It is a "permitted extension" to provide more constructors,
> as long as it can't change the behavior of a conforming program.

class SillyConverter
{
public:
    operator const char* ();
    operator const charT* ();
    operator string ();
} s;

ifstream ifs (s);

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard  <bonnardv@pratique.fr> wrote:
>Nathan Myers wrote:
>> (somebody) wrote:
>> >fstreams ctors only take const char*, not wstring
>> >or at least const charT*. Is it intentionnal ?
>>
>> It is a "permitted extension" to provide more constructors,
>> as long as it can't change the behavior of a conforming program.
>
>class SillyConverter
>{
>public:
>    operator const char* ();
>    operator const charT* ();
>    operator string ();
>} s;
>ifstream ifs (s);

All this means is that the additional constructors need more than one
argument.  The safest for an implementor is for that argument to be
a proprietary type (or pointer to one) so that any extensions by later
standards committees won't break customers' programs.

Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard <bonnardv@pratique.fr> wrote:
: Nathan Myers wrote:
: >
: > Valentin Bonnard  <bonnardv@pratique.fr> wrote:
: > >fstreams ctors only take const char*, not wstring
: > >or at least const charT*. Is it intentionnal ?
: > >Is it an oversight ?
: >
: > It is a "permitted extension" to provide more constructors,
: > as long as it can't change the behavior of a conforming program.

: class SillyConverter
: {
: public:
:     operator const char* ();
:     operator const charT* ();
:     operator string ();
: } s;

: ifstream ifs (s);

Hmm... It seems like your example shows that the "permitted extention",
Nathan refers to, is actually _never_ permitted.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

fstreams ctors only take const char*, not wstring
or at least const charT*. Is it intentionnal ?
Is it an oversight ?

Why isn't there a way to open file with an NTMBS ?

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Valentin Bonnard  <bonnardv@pratique.fr> wrote:
>fstreams ctors only take const char*, not wstring
>or at least const charT*. Is it intentionnal ?
>Is it an oversight ?

It is a "permitted extension" to provide more constructors,
as long as it can't change the behavior of a conforming program.
On systems that support wide-character file names, it is also
a "reasonable extension".

It would be silly to require such support where it is not possible.

>Why isn't there a way to open file with an NTMBS ?

I don't think the standard forbids multibyte-string file names.

Nathan Myers
ncm@nospam.cantrip.org
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]