ignis@SoftHome.net (Guy) wrote
> 2. Since the contents of argv[]/filename are already implementation
>    defined couldn't the type be too?

Think about what "compatibility" means. You want to write a program that
will work anywhere. What parameter types do you use? The standard says
that if you use int and char*[], it will work -- that's compatibility.
Vendors are already free to add ADDITIONAL signatures for main(),
provided that they ALSO support the int/char** combination.

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

kuyper@wizard.net ("James Kuyper Jr.") wrote in message news:<3DCB1D41.1000205@wizard.net>...
> Guy wrote:
> > 1. Whould it break compatibility to make the character string
> >    passed to fstream::open() and main() functions
> >    implementation defined? (char/wchar_t)
>
> Yes. Any code which passed the wrong type would no longer work.
>
> > 2. Since the contents of argv[]/filename are already implementation
> >    defined couldn't the type be too?
>
> Yes. With corresponding breakage of existing, legal code.
>

I didn't mean changing existing compilers / environments, to use
'wchar_t' instead of 'char'.

Only changing the definition to allow implementation defined behavior.

If your environment doesn't use 'wchar_t', than no change to main()
is needed, but why should an environment that only uses 'wchar_t'
be required to pass its arguments in a 'char' using an unspecified conversion.

Unfortunately, you cannot make 'char' a wide character and solve the problem,
you have to deal with two character types that have different signatures.

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

Guy wrote:
> kuyper@wizard.net ("James Kuyper Jr.") wrote in message news:<3DCB1D41.1000205@wizard.net>...
>
>>Guy wrote:
....
>>>2. Since the contents of argv[]/filename are already implementation
>>>   defined couldn't the type be too?
>>
>>Yes. With corresponding breakage of existing, legal code.
>>
>
>
> I didn't mean changing existing compilers / environments, to use
> 'wchar_t' instead of 'char'.
>
> Only changing the definition to allow implementation defined behavior.

Which means that currently legal code would break when ported to an
implementation that took advantage of that change.

> If your environment doesn't use 'wchar_t', than no change to main()
> is needed, but why should an environment that only uses 'wchar_t'
> be required to pass its arguments in a 'char' using an unspecified conversion.

An implementation which only uses wchar_t should redefine char to have
the same representation as wchar_t.

> Unfortunately, you cannot make 'char' a wide character and solve the problem,
> you have to deal with two character types that have different signatures.

Character types don't have signatures. Functions that take char
arguments have a different signature from functions that have wchar_t
arguments. Is that what you mean?

There's no reason why an implementation can't choose to define char and
wchar_t as having exactly the same representation.

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

""James Kuyper Jr."" <kuyper@wizard.net> wrote
> Guy wrote:
>
> > Unfortunately, you cannot make 'char' a wide character and solve the
problem,
> > you have to deal with two character types that have different
signatures.
>
> Character types don't have signatures. Functions that take char
> arguments have a different signature from functions that have wchar_t
> arguments. Is that what you mean?
>
> There's no reason why an implementation can't choose to define char and
> wchar_t as having exactly the same representation.
>

Except that char has the unfortunate duality of being both a character type
and the basic BYTE object of the underlying system. Making char a 16-bit or
32-bit quantity on a byte adressable machine, like the x86, would IMO be a
remedy worse than the original problem.



Bo Persson
bop2@telia.com

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

1. Whould it break compatibility to make the character string
   passed to fstream::open() and main() functions
   implementation defined? (char/wchar_t)

2. Since the contents of argv[]/filename are already implementation
   defined couldn't the type be too?

3. For an environment that uses wide chars for the shell and file names:
   "int main(int argc, wchar_t* argv[])"
   "basic_filebuf<>* basic_filebuf::open(const wchar_t* s,
                                         ios_base::openmode mode)"

4. For all others:
   "int main(int argc, char* argv[])"
   "basic_filebuf<>* basic_filebuf::open(const char* s,
                                         ios_base::openmode mode)"

5. If supported, wide char environments might supply the char version for
   basic_filebuf::open() that will do "widening" of char to wchar_t but
   it is an implementation's choice.

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

In article <6c1310be.0211070809.2d0ef5b2@posting.google.com>,
 ignis@SoftHome.net (Guy) wrote:


This particular "holy war" was fought recently, but here we go again.

> 1. Whould it break compatibility to make the character string passed
>    to fstream::open() and main() functions implementation defined?
>    (char/wchar_t)

Yes, although in both cases, vendors are free to add aditional
signatures.

> 2. Since the contents of argv[]/filename are already implementation
>    defined couldn't the type be too?

No, but in both cases, vendors are free to add additional signatures.

> 3. For an environment that uses wide chars for the shell and file names:
>    "int main(int argc, wchar_t* argv[])"
>    "basic_filebuf<>* basic_filebuf::open(const wchar_t* s,
>                                          ios_base::openmode mode)"

These would both (AFAICS) be permissable as conforming extentions, but
should be in addition to (rather than instead of) the currently
specified signatures.

> 4. For all others:
>    "int main(int argc, char* argv[])"
>    "basic_filebuf<>* basic_filebuf::open(const char* s,
>                                          ios_base::openmode mode)"

Those are the signatures as currently specified, and I've see no
compelling argument to break all the code that currently uses them.

> 5. If supported, wide char environments might supply the char version for
>    basic_filebuf::open() that will do "widening" of char to wchar_t but
>    it is an implementation's choice.

That's permissable right now since, as you point out, the contents of
the filename parameter are implementation specific. _How_ you widen
char to wchar_t is another matter altogether...

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

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

Guy wrote:
> 1. Whould it break compatibility to make the character string
>    passed to fstream::open() and main() functions
>    implementation defined? (char/wchar_t)

Yes. Any code which passed the wrong type would no longer work.

> 2. Since the contents of argv[]/filename are already implementation
>    defined couldn't the type be too?

Yes. With corresponding breakage of existing, legal code.

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