This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
RE: libgetopt++ and setup and libstdc++
- From: "Gary R. Van Sickle" <g dot r dot vansickle at worldnet dot att dot net>
- To: "Cygwin-Apps" <cygwin-apps at cygwin dot com>
- Date: Sun, 28 Apr 2002 14:38:47 -0500
- Subject: RE: libgetopt++ and setup and libstdc++
> > There's a cute 'trick' here that gives you the best of both worlds:
> >
> > typedef basic_string< TCHAR > StringAW;
> >
> > Now the "StringAW" type is either wide or narrow depending on
> > build-time defines.
>
> Except that widechar != unicode. WCHAR is still an 0 terminated string,
> but Unicode strings are not 0 terminated.
Sure they are. A Unicode '\0' == 0x0000 (regardless of your byte order ;-)).
That said, basic_string<> doesn't actually store a '\0'; it stores the string
length, and only "nullifies" things when you do a ".c_str()" [Eckel, "Thinking
in C++", 2nd ed. Volume 2].
> (See the NT kernel defines for
> UNICODE_STRING to see how unicode strings are represented.).
>
Right, but we're not in Kernel space here (thank the three men I admire most,
the Father, Son, and the Holy Ghost!). Everything is different (and usually
wrong) in Kernel mode. The UNICODE Win32 API takes null-terminated UNICODE
strings as parameters.
Great, now I'm having flashbacks. That's that PWDMSD (Post-Windows-Driver-Model
Stress Disorder) for ya.
> Anyway, as we need more than the base string class offers, I see no
> reason not to have our own string class..
Oh, I completely agree. I'm just saying that we could probably base it on
basic_string< TCHAR > and be one step ahead of the future.
--
Gary R. Van Sickle
Brewer. Patriot.