std::wcout and const char *

[Erik Knudsen]

Hi!

In converting applications from ansi to unicode, it is a problem that
the std::wcout accepts a const char * without complaining compile time.

This compiles and runs:
------------------------------
const char *lookup()
{
return "Hello world";
}
std::wcout << lookup();
------------------------------

I would like it to fail compile time, so I can properly convert cases
like this to unicode in a meaningful way.

Any ideas?
Regards,
Erik Knudsen

[Stefan Naewe]

On 12/11/2007 10:16 AM, Erik Knudsen wrote:

Hi!

In converting applications from ansi to unicode, it is a problem that
the std::wcout accepts a const char * without complaining compile time.

This compiles and runs:
------------------------------
const char *lookup()
{
return "Hello world";
}
std::wcout << lookup();
------------------------------

I would like it to fail compile time, so I can properly convert cases
like this to unicode in a meaningful way.

Any ideas?

Declare and do not define std::operator<< (wostream&, char const*) yourself?

namespace std
{
inline
wostream& operator<<(wost ream& wos, const char*);
}
Just an idea...
S.
--
Stefan Naewe stefan dot naewe at atlas-elektronik dot com
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html

[Erik Knudsen]

Stefan Naewe wrote:

>I would like it to fail compile time, so I can properly convert cases
like this to unicode in a meaningful way.

Any ideas?

Declare and do not define std::operator<< (wostream&, char const*) yourself?

namespace std
{
inline
wostream& operator<<(wost ream& wos, const char*);
}
Just an idea...

Thanks, but wouldn't that just give me a linker error, with no reference
to code lines?
Regards,
Erik Knudsen

[Stefan Naewe]

On 12/12/2007 10:01 AM, Erik Knudsen wrote:

Stefan Naewe wrote:

>>I would like it to fail compile time, so I can properly convert cases
like this to unicode in a meaningful way.

Any ideas?

Declare and do not define std::operator<< (wostream&, char const*)
yourself?

namespace std
{
inline
wostream& operator<<(wost ream& wos, const char*);
}
Just an idea...

Thanks, but wouldn't that just give me a linker error, with no reference
to code lines?

Yes...but:

If I call 'g++ -g' the linker gives me the file and line number:
g++ -g -Wall wchar.cc -o wchar
/tmp/ccLf8VPM.o: In function `main':
wchar.cc:37: undefined reference to `std::operator< <(std::basic_os tream<wchar_t, std::char_trait s<wchar_t&, char const*)'
collect2: ld returned 1 exit status
make: *** [wchar] Fehler 1
HTH

S.
--
Stefan Naewe stefan dot naewe at atlas-elektronik dot com
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html

[Stefan Naewe]

On 12/12/2007 10:11 AM, Stefan Naewe wrote:

On 12/12/2007 10:01 AM, Erik Knudsen wrote:

>Stefan Naewe wrote:

>>>I would like it to fail compile time, so I can properly convert cases
like this to unicode in a meaningful way.

Any ideas?
Declare and do not define std::operator<< (wostream&, char const*)
yourself?

namespace std
{
inline
wostream& operator<<(wost ream& wos, const char*);
}
Just an idea...

Thanks, but wouldn't that just give me a linker error, with no reference
to code lines?

Yes...but:

If I call 'g++ -g' ...

and remove the 'inline'...

the linker gives me the file and line number:
g++ -g -Wall wchar.cc -o wchar
/tmp/ccLf8VPM.o: In function `main':
wchar.cc:37: undefined reference to `std::operator< <(std::basic_os tream<wchar_t, std::char_trait s<wchar_t&, char const*)'
collect2: ld returned 1 exit status
make: *** [wchar] Fehler 1

I don't know why I put 'inline' there a all...

S.
--
Stefan Naewe stefan dot naewe at atlas-elektronik dot com
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html

[James Kanze]

On Dec 11, 10:51 am, Stefan Naewe <nos...@please. netwrote:

On 12/11/2007 10:16 AM, Erik Knudsen wrote:

In converting applications from ansi to unicode, it is a
problem that the std::wcout accepts a const char * without
complaining compile time.

This compiles and runs:
------------------------------
const char *lookup()
{
return "Hello world";
}
std::wcout << lookup();
------------------------------

I would like it to fail compile time, so I can properly
convert cases like this to unicode in a meaningful way.

Any ideas?

Declare and do not define std::operator<< (wostream&, char
const*) yourself?

namespace std
{
inline
wostream& operator<<(wost ream& wos, const char*);
}

Just an idea...

That's undefined behavior. You're not allowed to define new
free functions in a std::.

The standard std::wostream defines an operator<< for char
const*. You have to assume that some of the other operator<<
for wostream may use it, so you really have to leave it.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Stefan Naewe]

On 12/12/2007 1:41 PM, James Kanze wrote:

On Dec 11, 10:51 am, Stefan Naewe <nos...@please. netwrote:

>On 12/11/2007 10:16 AM, Erik Knudsen wrote:

>>In converting applications from ansi to unicode, it is a
problem that the std::wcout accepts a const char * without
complaining compile time.

>>This compiles and runs:
------------------------------
const char *lookup()
{
return "Hello world";
}
std::wcout << lookup();
------------------------------

>>I would like it to fail compile time, so I can properly
convert cases like this to unicode in a meaningful way.

>>Any ideas?

>Declare and do not define std::operator<< (wostream&, char
const*) yourself?

>namespace std
{
inline
wostream& operator<<(wost ream& wos, const char*);
}

>Just an idea...

That's undefined behavior. You're not allowed to define new
free functions in a std::.

I knew someone would say that...

But really: Who cares in this case if it just works (with some
modifications and only (?) with g++ (see my other post)) ?

The standard std::wostream defines an operator<< for char
const*. You have to assume that some of the other operator<<
for wostream may use it, so you really have to leave it.

S.
--
Stefan Naewe stefan dot naewe at atlas-elektronik dot com
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html

[James Kanze]

On Dec 12, 2:40 pm, Stefan Naewe <nos...@please. netwrote:

On 12/12/2007 1:41 PM, James Kanze wrote:

On Dec 11, 10:51 am, Stefan Naewe <nos...@please. netwrote:

On 12/11/2007 10:16 AM, Erik Knudsen wrote:

>In converting applications from ansi to unicode, it is a
problem that the std::wcout accepts a const char * without
complaining compile time.

>This compiles and runs:
------------------------------
const char *lookup()
{
return "Hello world";
}
std::wcout << lookup();
------------------------------

>I would like it to fail compile time, so I can properly
convert cases like this to unicode in a meaningful way.

>Any ideas?

Declare and do not define std::operator<< (wostream&, char
const*) yourself?

namespace std
{
inline
wostream& operator<<(wost ream& wos, const char*);
}

Just an idea...

That's undefined behavior. You're not allowed to define new
free functions in a std::.

I knew someone would say that...

But really: Who cares in this case if it just works (with some
modifications and only (?) with g++ (see my other post)) ?

Does it work? It might, or it might not. Or it might work some
of the time, and not others. There are things you can
reasonably define in std::, and expect to get away with it. But
this isn't one of them.

The standard std::wostream defines an operator<< for char
const*. You have to assume that some of the other
operator<< for wostream may use it, so you really have to
leave it.

And that is why. If you declare your version of the function,
either:

-- The only version in the standard library is the template
version. Your version overloads it, and since it is not a
template, has precedence in operator overload resolution.
If the library has overloaded the << operator for, say,
complex with something like:

template< typename Float, typename CharT ... >
std::basic_ostr eam< CharT ... >&
operator<<( std::basic_ostr eam< CharT ... >& dest,
std::complex< Float const& z )
{
dest << "(" << z.real() << "," << z.imag() << ")" ;
return dest ;
}

then this function may call your version, rather than the
standard one; which one will be chosen more or less
randomly.

-- If the standard library has also declared the function
(which would seem a more or less likely "optimizati on" for
the usual cases of std::ostream and std::wostream), then
your declaration just duplicates the one in the standard
library, and doesn't change anything.

The standard limits what you can do in std:: for a very real
reason.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Pete Becker]

On 2007-12-12 10:28:09 -0500, James Kanze <ja*********@gm ail.comsaid:

On Dec 12, 2:40 pm, Stefan Naewe <nos...@please. netwrote:

>But really: Who cares in this case if it just works (with some
modification s and only (?) with g++ (see my other post)) ?

Does it work? It might, or it might not. Or it might work some
of the time, and not others. There are things you can
reasonably define in std::, and expect to get away with it. But
this isn't one of them.

But as a short-term debugging aid, this is fine: if it detects
problems, you fix them. Once you've done that, you remove it. I've
occasionally gone so far as to add #error statements to standard
headers when I couldn't figure out why some header was being included
in a bogus context. (One of the Windows headers pulls in <stdlib.h>
while inside an extern "C" block. Sigh.)

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Erik Knudsen]

Pete Becker wrote:

>
But as a short-term debugging aid, this is fine: if it detects problems,
you fix them. Once you've done that, you remove it. I've occasionally
gone so far as to add #error statements to standard headers when I
couldn't figure out why some header was being included in a bogus
context. (One of the Windows headers pulls in <stdlib.hwhil e inside an
extern "C" block. Sigh.)

I will only use it as a short term porting/debugging aid. However, I use
VC++ 2005, and it doesn't give me the line numbers for a link error.
Regards,
Erik Knudsen