From: Ulrich Eckhardt on
Rayne wrote:
> On Feb 9, 10:14 am, Rayne <lancer6...(a)yahoo.com> wrote:
>> Just to add, I've tried CA2T, and I still get the same errors.
>
> After including <atlbase.h> and USES_CONVERSION, I get the following
> errors for the 2 lines
> user = CA2T(cuser);
> packet = CA2CT(cpacket);
>
> error C2440: 'type cast': cannot convert from 'const u_char *' to
> 'ATL::CA2WEX<>'
> error C2440: 'type cast': cannot convert from 'u-char *' to
> 'ATL::CA2WEX<>'

Stop guessing. Look up the documentation at msdn.microsoft.com, it
explicitly tells you what header to include and what libs to link with. It
also tells you how to use it etc.

Uli

--
C++ FAQ: http://parashift.com/c++-faq-lite

Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
From: Ulrich Eckhardt on
Rayne wrote:
> I'm really confused by this unicode vs multi-byte thing.
>
> Say I'm compiling my program in Unicode (but ultimately, I want a
> solution that is independent of the character set used).
>
> 1) Will all 'char' be interpreted as wide characters?

No. The datatypes '[[un]signed] char' and 'wchar_t' never change their
actual type. What does change is what 'TCHAR' etc resolves to and
accordingly all APIs using it.

> 2) If I have a simple printf statement, i.e. printf("Hello World\n");
> with no character strings, can I just leave it be without using
> _tprintf and _T("...")?

Yes.

> If the printf statement includes a character string, then I should use
> _tprintf and _T("..."), i.e. _tprintf("Hello %s\n", name); ?

No, not necessarily. Take a look at '%hs' and '%ls' placeholders. Note that
printf() has limited functionality, using wprintf() would be a more
versatile alternative. However, then you can also drop the whole
TCHAR-thing completely, which IMHO is not just an alternative but should be
the goal, unless you have to support win9x.

> 3) If I have a text file (saved in the default format, i.e. without
> changing the default character set used) that I want to read into a
> buffer, can I still use char instead of TCHAR?

Yes. However: You could read the bytes in a text file, but without knowing
the encoding you can not interpret it. The 'default character set' you
mention is not universally fixed, but depends on the OS setup.

Actually, using TCHAR for files is a Damn Bad Idea(tm). The problem, just
like with network protocols, is that you don't know the actual encoding. It
might be the configured multibyte encoding or it could end up as
little-endian UTF-16, depending on the program it was written with. Without
knowing the encoding, you can not reliably parse such a file. You as a
programmer should decide the encoding as part of your design. Even if you
just say ASCII (which excludes any chars >= 127) that is fine, too. If you
need further Unicode features, I'd suggest you switch to UTF-8, which is
the the most common variant.

Uli

--
C++ FAQ: http://parashift.com/c++-faq-lite

Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
From: Giovanni Dicanio on
"Rayne" <lancer6238(a)yahoo.com> ha scritto nel messaggio
news:44287d08-acdf-4d35-8a7d-d66974be5a42(a)s36g2000prh.googlegroups.com...

> I'm trying to use the A2T macro for my pcap_loop callback function
> "got_packet".

We suggested against A2T macro.
Consider using CA2T.


> So I have
>
> void got_packet(u_char *cuser, const struct pcap_pkthdr *header, const
> u_char *cpacket)
> {
> _TUCHAR *user, *packet;
> user = A2T(cuser);
> packet = A2T(cpacket);

Please use TCHAR instead of _TUCHAR (this is the first time I read this kind
of type).
Moreover, I have no idea what u_char is.

Assuming that you have 'const char * cuser', 'const char * cpacket', you can
write code like this:

CA2T user( cuser );
CA2T packet( cpacket );

Now, you can use 'user' and 'packet' wherever a 'const TCHAR *' (i.e.
LPCTSTR) is required.


> error C3861: 'A2T': identifier not found, even with argument-dependent
> lookup
[...]
> Is there some compiler setting or header files I should include?

In the page whose link was posted above in this thread:

http://msdn.microsoft.com/en-us/library/87zae4a3(VS.80).aspx

you can read at the bottom:

> Requirements
> Header file: AtlBase.h, AtlConv.h (declared in AtlConv.h)

So, you just need to #include <AtlBase.h> and <AtlConv.h> (a good place to
do that is "StdAfx.h" precompiled header).

HTH,
Giovanni


From: Ulrich Eckhardt on
Rayne wrote:
> 2) If I have a simple printf statement, i.e. printf("Hello World\n");
> with no character strings, can I just leave it be without using
> _tprintf and _T("...")? If the printf statement includes a character
> string, then I should use _tprintf and _T("..."), i.e. _tprintf("Hello
> %s\n", name); ?

I forgot one thing in my post: Do not mix printf() and wprintf(). Since
_tprintf() resolves to wprintf() or printf() depending on whether _UNICODE
is #defined, that in effect means that you also shouldn't mix any of the
three with the others.

Uli

--
C++ FAQ: http://parashift.com/c++-faq-lite

Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
From: Giovanni Dicanio on
"Rayne" <lancer6238(a)yahoo.com> ha scritto nel messaggio
news:2b311af8-036e-4f5c-89a7-990a9292e30d(a)f17g2000prh.googlegroups.com...

> I'm really confused by this unicode vs multi-byte thing.

You are right. It can be kind of confusing when you start.


As a side note, I would like to suggest you a couple of links on
CodeProject:

"The Complete Guide to C++ Strings, Part I - Win32 Character Encodings"
http://www.codeproject.com/KB/string/cppstringguide1.aspx

"StdioFile-derived class for multibyte and Unicode reading and writing"
http://www.codeproject.com/KB/files/stdiofileex.aspx


Giovanni