Actually they have completely different function
names set aside for single-byte & multi-byte
support, then a "neutral" name #defined to
point to whichever one is appropriate according
to the settings. They do -not- have two different
libraries each implementing functions of the same
name but different capabilities. Both mbyte and
sbyte support is available simultaneously if you
explicitly use the appropriate function name. If
you use the "generic" name it the macro generates
the appropriate function name and the linker links
to the proper libary routine.
I apologize for being unclear in the earlier msg.
--
-Richard M. Hartman
[EMAIL PROTECTED]
186,000 mi./sec ... not just a good idea, it's the LAW!
> -----Original Message-----
> From: Florent Pillet [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 18, 1999 9:43 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Problem with StrChr()?
>
>
> > This is one place where MSoft got it right. They have
> > a macro (TCHAR) that expands into the proper basic type
> > depending upon whether you've set the option for single
> > byte or multibyte support. Different libraries are
> > linked in depending upon the setting.
>
> One thing MS _really_ got wrong is when you want to have both
> multi-byte and
> single-byte support at the same time. It's hell. Rather
> follow a clean model
> where the OS offers functions to manipulate both kinds of
> data depending on
> what you want, like this exists on the Mac OS. Linking
> against different
> libraries to produce builds that support multibyte is a very
> bad idea, IMHO.
>
> --
> Florent Pillet, Code Segment [EMAIL PROTECTED]
>
> BrainForest, outlines and action items for Palm OS handhelds
> -> Aportis Technologies Corp. http://www.aportis.com/
> PowerGlot, the premier localization tool for Mac OS software
> -> PowerGlot Software http://www.powerglot.com/
> Palm Buddy, MacOS active link companion for PalmOS handhelds
> -> ...and other tools... http://perso.wanadoo.fr/fpillet/
>
