How do you define a UniChar constant?

Boy, that's heavy...

I am trying to make My CString unicoded so it'll be fully compatible with MFC CString....
Pfew!

Thanks,
Denis


"Scott Ribe" <scott_ribe DeleteThis @killerbytes.com> wrote in message
news:BF671E79.332D1%scott_ribe@killerbytes.com...
> As far as I know there is no convenient way.
>
> UniChar string[] = { 't','h','i','s',' ','s','u','x','!' };
>
> Will work but is not something you would want to have to do very often. The
> more Mac-like way would be to put your unicode strings in a plist dictionary
> and use core foundation functions to read them in. Otherwise, it would
> probably to define unsigned char * constant strings using UTF-8 encoding,
> then you just define the constant mostly like a normal string, and have to
> know the escape sequences for anything other than 7-bit ASCII. Once you have
> a UTF-8 string, you can use various methods to get it to UniChar--NSString,
> CFString, Text Encoding utilities, whatever...
>
>
 >> Stay informed about: How do you define a UniChar constant? 

In article <1128389185.276028.TakeThisOut@www.vif.com>, < @> wrote:

> I am trying to make My CString unicoded so it'll be fully compatible with MFC
> CString....

Suggestion: Your OS X string class' primary data member should be a
CFStringRef rather than a unichar array.
 >> Stay informed about: How do you define a UniChar constant? 

I know I am using it already internally.

I already made the version for standard ASCII now I am looking forward for Unicode too.
The thing that I am trying to avoid is converting tones and I mean TONES of codes.
So it seems like a good idea to embed it.

Thanks


"Chris Baum" <cbaum981.TakeThisOut@atlantic.net> wrote in message
news:031020052050116189%cbaum981@atlantic.net...
> In article <1128389185.276028.TakeThisOut@www.vif.com>, < @> wrote:
>
> > I am trying to make My CString unicoded so it'll be fully compatible with MFC
> > CString....
>
> Suggestion: Your OS X string class' primary data member should be a
> CFStringRef rather than a unichar array.
 >> Stay informed about: How do you define a UniChar constant? 

In article <1128389185.276028.RemoveThis@www.vif.com>,
"Denis @ TheOffice" <denisco.RemoveThis@ica.net> wrote:

> Boy, that's heavy...
>
> I am trying to make My CString unicoded so it'll be fully compatible with MFC
> CString....
> Pfew!
>
> Thanks,
> Denis
>
>
> "Scott Ribe" <scott_ribe.RemoveThis@killerbytes.com> wrote in message
> news:BF671E79.332D1%scott_ribe@killerbytes.com...
> > As far as I know there is no convenient way.
> >
> > UniChar string[] = { 't','h','i','s',' ','s','u','x','!' };
> >

Have you considered that if you have lots of embedded unicode constant
strings, you're probably doing something wrong?

Consider:

1) C-Strings not visible to the user (such as internal keys & other
label or debugging), might as well just remain in ASCII - no portability
issue (not to mention various other advantages of simple ASCII)

2) Unicode strings are needed instead of simple ASCII string to support
various international characters not available in ASCII

3) If you need international characters for localization, you probably
should have an external file with these strings (one for each language,
for example - Mac OS X provides .strings files for exactly such
purposes).


So combine all these points, and where would you have a whole lot of
embedded unicode constant strings? (And this doesn't even factor in the
potential mess you get with character encoding differences between your
editor and what the c-compiler expects if you are trying to type in
unicode characters outside of ascii).
 >> Stay informed about: How do you define a UniChar constant? 

I am not sure I understand all of what you're trying to say.

"glenn andreas" <gandreas.DeleteThis@no.reply> wrote in message
news:gandreas-189444.08555304102005@ip-lcc.supernews.net...
> In article <1128389185.276028.DeleteThis@www.vif.com>,
> "Denis @ TheOffice" <denisco.DeleteThis@ica.net> wrote:
>
> > Boy, that's heavy...
> >
> > I am trying to make My CString unicoded so it'll be fully compatible with MFC
> > CString....
> > Pfew!
> >
> > Thanks,
> > Denis
> >
> >
> > "Scott Ribe" <scott_ribe.DeleteThis@killerbytes.com> wrote in message
> > news:BF671E79.332D1%scott_ribe@killerbytes.com...
> > > As far as I know there is no convenient way.
> > >
> > > UniChar string[] = { 't','h','i','s',' ','s','u','x','!' };
> > >
>
> Have you considered that if you have lots of embedded unicode constant
> strings, you're probably doing something wrong?
>
> Consider:
>
> 1) C-Strings not visible to the user (such as internal keys & other
> label or debugging), might as well just remain in ASCII - no portability
> issue (not to mention various other advantages of simple ASCII)
>
Well, what about file and pathnames?
Eventhough they are not always visible by user.
What about error messages that are based on logic.

> 2) Unicode strings are needed instead of simple ASCII string to support
> various international characters not available in ASCII
>
Most functions either wants Pascal string "yeuk" or Unicode.
I am trying to simplify all that by making a class that would handle those disconvergence.
And yet keep the code portable back in Windows.

> 3) If you need international characters for localization, you probably
> should have an external file with these strings (one for each language,
> for example - Mac OS X provides .strings files for exactly such
> purposes).
>
I know and I will do in a next stage.

> So combine all these points, and where would you have a whole lot of
> embedded unicode constant strings? (And this doesn't even factor in the
> potential mess you get with character encoding differences between your
> editor and what the c-compiler expects if you are trying to type in
> unicode characters outside of ascii).

I believe there will still be some...
The idea of a class handling all that is to prevent the mess in a first place.


Thanks,
Denis
 >> Stay informed about: How do you define a UniChar constant? 

Denis @ TheOffice wrote:
> I am trying to make My CString unicoded so it'll be fully compatible with MFC CString....
You can make a constructor with a CFStringRef parameter and define _T
macro as #define _T(str) CFSTR(str)
Surely, it will not work for strings with explicit 'L' prefix.
 >> Stay informed about: How do you define a UniChar constant? 

Thanks,

It is a good idea.
I think It's either that or a conversion in constructors/comparators/concatenators/
I'll probably end up do them all to be on the save side.

The only bugler left at this point is to split the differences between LoadString from res which
Windows is an int.
Perhaps if I make another macro that makes CFSTR act as a res int under the Mac.

Regards,
Denis


"Alexander Dymerets" <sashad RemoveThis @productengine.com> wrote in message
news:dhugrl$i2q$1@toster.te.net.ua...
> Denis @ TheOffice wrote:
> > I am trying to make My CString unicoded so it'll be fully compatible with MFC CString....
> You can make a constructor with a CFStringRef parameter and define _T
> macro as #define _T(str) CFSTR(str)
> Surely, it will not work for strings with explicit 'L' prefix.
 >> Stay informed about: How do you define a UniChar constant? 

BTW;

Do you know why that does not compile ?


friend McString operator +(CFStringRef ParmStringRef1, CFStringRef ParmStringRef2);

CW tells me it is illegal operator.

Thanks
 >> Stay informed about: How do you define a UniChar constant? 

In article <1128442209.52547.TakeThisOut@www.vif.com>,
"Denis @ TheOffice" <denisco.TakeThisOut@ica.net> wrote:

> I am not sure I understand all of what you're trying to say.
>

That there are strategies (and valid reasons) to not have unicode
constants in your source code in the first place.

> > 1) C-Strings not visible to the user (such as internal keys & other
> > label or debugging), might as well just remain in ASCII - no portability
> > issue (not to mention various other advantages of simple ASCII)
> >
> Well, what about file and pathnames?
> Eventhough they are not always visible by user.

Things like relative paths (for objects inside your bundle) are all
under your control, and aren't user visible (and thus don't need to be
localized, and therefore don't need to be unicode).

External paths shouldn't be hard coded anyway - there are a wide variety
of routines available to get the paths for things such as the location
of user preferences, etc...


> What about error messages that are based on logic.

If they are to be user visible, they should be localizable. Hardcoded
!= localizable.

>
> > 2) Unicode strings are needed instead of simple ASCII string to support
> > various international characters not available in ASCII
> >
> Most functions either wants Pascal string "yeuk" or Unicode.
> I am trying to simplify all that by making a class that would handle those
> disconvergence.
> And yet keep the code portable back in Windows.

Basically all OS X routines that want Pascal strings have been
depricated (and you shouldn't be using them), and have been replaced by
things taking CFStrings, which can be easily created from ASCII
constants:

CFSTR("SomeKeyValue")

And if the string "SomeKeyValue" requires non-ascii characters,
something is probably wrong.

What sort of functions are you seeing that require "unicode"?


Take a look at all the system headers, and find how many places unicode
constants need to explicitly be declared as unicode - about the only
ones I can find are those that are used for declaring thing like the
special characters generated by hitting various function keys.
 >> Stay informed about: How do you define a UniChar constant? 

"glenn andreas" <gandreas.DeleteThis@no.reply> wrote in message
news:gandreas-E60D15.15104904102005@ip-lcc.supernews.net...
> In article <1128442209.52547.DeleteThis@www.vif.com>,
> "Denis @ TheOffice" <denisco.DeleteThis@ica.net> wrote:
>
> > I am not sure I understand all of what you're trying to say.
> >
>
> That there are strategies (and valid reasons) to not have unicode
> constants in your source code in the first place.
>
> > > 1) C-Strings not visible to the user (such as internal keys & other
> > > label or debugging), might as well just remain in ASCII - no portability
> > > issue (not to mention various other advantages of simple ASCII)
> > >
> > Well, what about file and pathnames?
> > Eventhough they are not always visible by user.
>
> Things like relative paths (for objects inside your bundle) are all
> under your control, and aren't user visible (and thus don't need to be
> localized, and therefore don't need to be unicode).
>
> External paths shouldn't be hard coded anyway - there are a wide variety
> of routines available to get the paths for things such as the location
> of user preferences, etc...
>
>
> > What about error messages that are based on logic.
>
> If they are to be user visible, they should be localizable. Hardcoded
> != localizable.
>
There will be as soon as I have a good strategy that works with both Windows and Mac.

> >
> > > 2) Unicode strings are needed instead of simple ASCII string to support
> > > various international characters not available in ASCII
> > >
> > Most functions either wants Pascal string "yeuk" or Unicode.
> > I am trying to simplify all that by making a class that would handle those
> > disconvergence.
> > And yet keep the code portable back in Windows.
>
> Basically all OS X routines that want Pascal strings have been
> depricated (and you shouldn't be using them), and have been replaced by
> things taking CFStrings, which can be easily created from ASCII
> constants:
>
> CFSTR("SomeKeyValue")
>
> And if the string "SomeKeyValue" requires non-ascii characters,
> something is probably wrong.
>
> What sort of functions are you seeing that require "unicode"?
>
Well, "FSCreateFileUnicode"

Others are functionS that work the same way in Mac and Windows.
Example I have develop a class that works on registry under windows
And on CFPreferences under Mac. It;s absolutelly transparent.

LONG CRegKey::Read (PCTSTR pszKey, double &Data)

That give the edge of not having to rewrite codes that already works.
It also diminish the requirements of having tones of #ifdef _MAC...

>
> Take a look at all the system headers, and find how many places unicode
> constants need to explicitly be declared as unicode - about the only
> ones I can find are those that are used for declaring thing like the
> special characters generated by hitting various function keys.

I don't think I have that much time to spare;-)

Regards,
Denis
 >> Stay informed about: How do you define a UniChar constant? 

What Glenn is trying to say is that in a typical Mac application, the
only strings you should hard code into your application are those which
are for internal use only, such as keys for CFDictionairies or entries
in CFPreferences. Any strings that need Unicode should be in your
Localizable.strings file. If you have non-ASCII strings that don't need
to be localized in different languages, they can either just be
replicated in each language's Localizable.strings file, or you can put
them all in a custom .strings file that lives in your Resources folder.
If you only need a few of these, then you can resort to:

UniChar kString[] = { characters listed here };

It's not pretty, but it works.

Larry
 >> Stay informed about: How do you define a UniChar constant? 

Does that mean that UniChar in CFDictionairies and CFPreferences...
won't work.

Is that what you mean?

Denis

<larry.DeleteThis@skytag.com> wrote in message news:1128473692.241839.152690@g44g2000cwa.googlegroups.com...
> What Glenn is trying to say is that in a typical Mac application, the
> only strings you should hard code into your application are those which
> are for internal use only, such as keys for CFDictionairies or entries
> in CFPreferences. Any strings that need Unicode should be in your
> Localizable.strings file. If you have non-ASCII strings that don't need
> to be localized in different languages, they can either just be
> replicated in each language's Localizable.strings file, or you can put
> them all in a custom .strings file that lives in your Resources folder.
> If you only need a few of these, then you can resort to:
>
> UniChar kString[] = { characters listed here };
>
> It's not pretty, but it works.
>
> Larry
>
 >> Stay informed about: How do you define a UniChar constant? 

Denis @ TheOffice wrote:
> friend McString operator +(CFStringRef ParmStringRef1, CFStringRef ParmStringRef2);
>
> CW tells me it is illegal operator.
CFStringRef is a pointer to an opaque structure. So you are trying to
create a + operator for 2 pointers.
 >> Stay informed about: How do you define a UniChar constant?