From: Angel Tsankov on
Hallo!

Which of the following definitions of tcerr is preferrable and why?

1)
// header file
namespace {
::std::wostream& tcerr = ::std::wcerr;
}

2)
// header file
extern ::std::wostream& tcerr;

// source file
::std::wostream& tcerr = ::std::wcerr;


From: Alf P. Steinbach on
* Angel Tsankov:
>
> Which of the following definitions of tcerr is preferrable and why?
>
> 1)
> // header file
> namespace {
> ::std::wostream& tcerr = ::std::wcerr;
> }

Don't use anonymous namespaces in header files. There's only one global level
anonymous namespace in each compilation unit. The above sneaks in an identifier
in the anonymous namespace of the each implementation file that uses this
header, and in that anon namespace there might well be something called tcerr.

Also it's a good idea to not use "T" functionality at all, and a really bad idea
to use it (more to write, more possible bugs, less portable and non-standard).

So the above is wrongheaded on 2 different counts.


> 2)
> // header file
> extern ::std::wostream& tcerr;
>
> // source file
> ::std::wostream& tcerr = ::std::wcerr;

This one would be slightly less unpreferable than the first.

But do you really want your Unicode messages to be translated to some single
byte charset that you don't control (most probably Windows ANSI Western)?

I'd think not.

It's just silly.

For internal diagnostic messages and logging, go for English only, a well known
single byte charset, and deal with e.g. Unicode filenames (if you must)
explicitly, instead of relying on some unspecified lossy translation.


Cheers, & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
From: Angel Tsankov on
>> Which of the following definitions of tcerr is preferrable and why?
>>
>> 1)
>> // header file
>> namespace {
>> ::std::wostream& tcerr = ::std::wcerr;
>> }
>
> Don't use anonymous namespaces in header files. There's only one global
> level anonymous namespace in each compilation unit. The above sneaks in
> an identifier in the anonymous namespace of the each implementation file
> that uses this header, and in that anon namespace there might well be
> something called tcerr.

Ooops, you're right! In fact, I meant to write smth like this:

namespace tstd {
namespace {
::std::wostream& tcerr = ::std::wcerr;
}
}

> Also it's a good idea to not use "T" functionality at all, and a really
> bad idea to use it (more to write, more possible bugs, less portable and
> non-standard).
>
> So the above is wrongheaded on 2 different counts.
>
>
>> 2)
>> // header file
>> extern ::std::wostream& tcerr;
>>
>> // source file
>> ::std::wostream& tcerr = ::std::wcerr;
>
> This one would be slightly less unpreferable than the first.
>
> But do you really want your Unicode messages to be translated to some
> single byte charset that you don't control (most probably Windows ANSI
> Western)?
>
> I'd think not.
>
> It's just silly.
>
> For internal diagnostic messages and logging, go for English only, a well
> known single byte charset, and deal with e.g. Unicode filenames (if you
> must) explicitly, instead of relying on some unspecified lossy
> translation.

In fact, I'd go for English only, but I'd like to be able to switch easily
between ANSI and UNICODE builds, possibly without changing the source code,
e.g.:

tstd::tstring NameOfInputFile(_T(...));
HANDLE HandleToInputFile = CreateFile(NameOfInputFile.c_str(), ...);

> Cheers, & hth.,
>
> - Alf
>
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is it such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?