 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / CodeWarrior / October 2005How do you define a UniChar constant?
I was wondering since wchar_t is long and so is L"the string". How do we make a constant string in UniChar shorts? Denis 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... Boy, that's heavy... I am trying to make My CString unicoded so it'll be fully compatible with MFC CString.... Pfew! Thanks, Denis > As far as I know there is no convenient way. > [quoted text clipped - 8 lines] > a UTF-8 string, you can use various methods to get it to UniChar--NSString, > CFString, Text Encoding utilities, whatever... > 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. 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 > > 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. > Boy, that's heavy... > [quoted text clipped - 8 lines] > > > > 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). I am not sure I understand all of what you're trying to say. > > Boy, that's heavy... > > [quoted text clipped - 17 lines] > 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 > 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 [quoted text clipped - 3 lines] > 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. > > I am not sure I understand all of what you're trying to say. > [quoted text clipped - 20 lines] > 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 [quoted text clipped - 15 lines] > > 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 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 Does that mean that UniChar in CFDictionairies and CFPreferences... won't work. Is that what you mean? Denis > 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 [quoted text clipped - 11 lines] > > Larry > Does that mean that UniChar in CFDictionairies and > CFPreferences... won't work. > Is that what you mean? No, not at all. I don't even know why you'd ask that, in part because your question doesn't actually make sense. CFDictionairies don't store UniChars. Larry > 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. 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 > > 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. BTW; Do you know why that does not compile ? friend McString operator +(CFStringRef ParmStringRef1, CFStringRef ParmStringRef2); CW tells me it is illegal operator. Thanks > 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. I wonder... If I know how to combine them to make it a McString, why do the compiler have a problem with that ? > > 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. > I wonder... > If I know how to combine them to make it a McString, why do the compiler have a problem with that ? If compilers knew all that programmers know, programmers would be needless. > > I wonder... > > If I know how to combine them to make it a McString, why do the compiler have a problem with that ? > If compilers knew all that programmers know, programmers would be needless. Well, it's kind of my point don't you think? If programmers know better, why do the compiler enforce such a rule? Don't you think it is a flaw? Even if it is a Standard consortium one. I mean How does that help anybody ? > I mean How does that help anybody ? It kept *you* from overloading operator + on pointers. If you can't see how that was a good thing, then you need to think about it a bit more. Please, can you help me in this thinking? I am willing to understand. Why is it a good thing? or Why is it such a bad thing? Either way I can't figure out right now. Thanks in advance. Denis > > I mean How does that help anybody ? > > It kept *you* from overloading operator + on pointers. If you can't see how > that was a good thing, then you need to think about it a bit more. >Please, can you help me in this thinking? >I am willing to understand. [quoted text clipped - 12 lines] >> It kept *you* from overloading operator + on pointers. If you can't see how >> that was a good thing, then you need to think about it a bit more. Effective C++ : 55 Specific Ways to Improve Your Programs and Designs (3rd Edition) -- by Scott Meyers ISBN: 0321334876 Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library -- by Scott Meyers ISBN: 0201749629 The C++ Programming Language (Special 3rd Edition) -- by Bjarne Stroustrup ISBN: 0201700735 Thanks, I'll have a look... Although, in the book I have just states it, without given a reasonable reason. I did find an alternative though, with a macro that upgrade the insignificant CFStringRef to a class type... Kind regards, Denis > >Please, can you help me in this thinking? > >I am willing to understand. [quoted text clipped - 24 lines] > Stroustrup > ISBN: 0201700735 >Thanks, I'll have a look... > [quoted text clipped - 6 lines] >Kind regards, >Denis These books are absolutely indispensable for anyone writing C++. >> >Please, can you help me in this thinking? >> >I am willing to understand. [quoted text clipped - 25 lines] >> Stroustrup >> ISBN: 0201700735 > I did find an alternative though, with a macro that upgrade the > insignificant CFStringRef Insignificant? > to a class type... Ugh. Sounds like a hack, and one you're using to fix a problem you don't understand. That's not good programming in any book. A much better solution IMO would be to use your McString class throughout and define a + operator for that. Larry > > I did find an alternative though, with a macro that upgrade the > > insignificant CFStringRef > > Insignificant? I meant meaningless. > > to a class type... > > Ugh. Sounds like a hack, and one you're using to fix a problem you > don't understand. That's not good programming in any book. IMHO, it is as good programming as CFSTR(...) > A much better solution IMO would be to use your McString class > throughout and define a + operator for that. I whish I could understand what you've just said. Perhaps if you could put some code that illustrates it. Regards, Denis >>> insignificant CFStringRef > >> Insignificant? > > I meant meaningless. Hardly meaningless. Maybe you don't know what that word means. >> A much better solution IMO would be to use your McString class >> throughout and define a + operator for that. > > I whish I could understand what you've just said. > Perhaps if you could put some code that illustrates it. I make very minimal use of raw CFStringRefs. Instead, I use a class wrapper for CFStringRef and another for CFMutableStringRef that handle all the details and keep my code much cleaner than filling it up with endless calls to CFStringXxxx() APIs. With a good class wrapped around them CFStrings are great. You could have something like this, for example: TString operator + ( const TString &inLHS, const TString &inRHS ) { CFStringRef s = CFStringCreateWithFormat( kCFDefaultAllocator, NULL, CFSTR("%@%@"), (CFStringRef) inLHS, (CFStringRef) inRHS ); return TString( s, kAssumeOwnership ); } or this: TString operator + ( const TString &inFirst, const TString &inSecond ) { TString first( inFirst ); return TString( first += inSecond ); } Larry > >>> insignificant CFStringRef > > [quoted text clipped - 35 lines] > return TString( first += inSecond ); > } That, I have done (since day 1), but we still cannot use the form: { ... TString MyString; MyString = CFSTR("str1") + CFSTR("str2"); } OR If you have a CFStringRef comming from somewhere void InAFunction(CFStringRef CFStrFromSomewhere) { TString MyString; MyString = CFSTR("str1") + CFStrFromSomewhere; ... } This is what I meant, and this is where the macro commes to the rescue. But basically what I did not (still don't) understand is why the C++ compiler (any) is not capable of processing that. Regards, Denis > That, I have done (since day 1), but we still cannot use the form: > [quoted text clipped - 4 lines] > MyString = CFSTR("str1") + CFSTR("str2"); > } Isn't this just as well: TString MyString(CFSTR("str1"), CFSTR("str2")); or if you're opposed to extra convenience ctors: TString MyString(CFSTR("str1")); MyString += CFSTR("str2"); > OR > > If you have a CFStringRef comming from somewhere > void InAFunction(CFStringRef CFStrFromSomewhere) Change the signature of InAFunction to accept a TString instead of CFStringRef. You can still pass it a CFStringRef as long as TString provides a CFStringRef ctor. The larger idea is you write a single foundational/framework wrapper for each OS construct/api-set. Your client /application code (e.g. InAFunction above) then has no knowledge of these lower level beasts or how they are implemented. And you shouldn't be worrying so much about supporting CFSTR - when do you concatonate 2 const, ascii-only strings in your app? Looking at some of my code I'm only seeing CFSTR used for: xml keys nibs/resources names in my bundle CFCopyLocalizedStringFromTable calls > > That, I have done (since day 1), but we still cannot use the form: > > [quoted text clipped - 13 lines] > TString MyString(CFSTR("str1")); > MyString += CFSTR("str2"); This is what I do, except I'd have: TString myString("str1"); myString += "str2"; since my CFString class has constructors and operators to work with C-strings. > > OR > > [quoted text clipped - 4 lines] > CFStringRef. You can still pass it a CFStringRef as long as TString > provides a CFStringRef ctor. This I don't do unless I need functions or operators in TString. Otherwise I write functions to accept a CFStringRef. That way I can pass TStrings, CFStrings, and CFMutableStrings, all without invoking contructors and destructors. > The larger idea is you write a single foundational/framework wrapper > for each OS construct/api-set. Your client /application code (e.g. [quoted text clipped - 3 lines] > And you shouldn't be worrying so much about supporting CFSTR - when do > you concatonate 2 const, ascii-only strings in your app? Hard-code strings, never. I do build some CFPreferences keys by concantenating a hard-coded ASCII string and an ASCII string created at runtime. > Looking at > some of my code I'm only seeing CFSTR used for: > > xml keys > nibs/resources names in my bundle I don't even use them for this. All of my code that does this kind of stuff is tucked away in utility functions that take C-strings and create TStrings from them because I didn't want to be hassled with typing CFSTR("x") all the time when I could just use "x" instead. > CFCopyLocalizedStringFromTable calls Or for this. Same reason. I do have some CFSTRs in my application, but I avoid them if I can because I hate the extra typing. Larry |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.