• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Xcode's STL problem, works fine in MW
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Xcode's STL problem, works fine in MW


  • Subject: Re: Xcode's STL problem, works fine in MW
  • From: Chris Espinosa <email@hidden>
  • Date: Sat, 19 Feb 2005 16:32:04 -0800

On Feb 19, 2005, at 2:20 PM, Marshall Clow wrote:

I'm moving a project from MW to Xcode and that project uses STL for unicode strings. It builds fine in MW but there seems to be problem with STL since it does not seem to instantiate the following methods (I'm getting a link error):
std::char_traits<unsigned short>::copy(unsigned short*, unsigned short const*, unsigned long)
std::char_traits<unsigned short>::move(unsigned short*, unsigned short const*, unsigned long)
std::char_traits<unsigned short>::length(unsigned short const*)
Would it mean that I have to define them on my own?
Yes.
This is an interesting problem, full of twists and turns.
Consider:
1) Both compilers define and implement std::char_traits < char > and std::char_traits < wchar_t >
2) In XCode wchar_t ==> 32 bits, while in CodeWarrior wchar_t ==> 16 bits
But wait!
3) Codewarrior has a char_traits implementation which is entirely template-based,
so it can be instantiated for any integral type.
4) GCC does not have a completely template-based implementation of char_traits. In fact, I found a posting on a GCC mailing list (link lost) by one of the gcc maintainers that stated that it was, in fact, impossible to make a compliant, fully templated implementation of std::char_traits.
So, if you are doing something like:
typedef std::basic_string < unsigned short> unistr ;
and you want it to work on gcc/xcode, you have to define those missing functions.
Fortunately, they are pretty simple to code up.
P.S. There are lots of reasons not to use basic_string to hold Unicode strings, all of which boil down to the fact that "one entry in the string != one Unicode character". This causes problems when searching, inserting, deleting, and comparing these strings.

And I have to mention that basic_string<unsigned short> was in fact implemented in the headers for gcc3.1, got dropped in 3.3, and has been restored in 4.0. So if you define your own, be prepared to #ifdef it out for non-gcc-3.3 versions, e.g.


#if defined(__GNUC__) && __GNUC__ == 3 &&  __GNUC_MINOR__ == 3
    // define the things missing in gcc3.3 here
#endif

And, as Marshall said, unsigned short is not really a useful container for Unicode strings, as the operators are ignorant of Unicode conventions (like combining forms, byte order markers, etc.). Investigate CFString.

Chris

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Xcode's STL problem, works fine in MW (From: Marshall Clow <email@hidden>)

  • Prev by Date: Re: calling isnan
  • Next by Date: Re: Differences between Cocoa and Cocoa-Java Projects/Targets
  • Previous by thread: Re: Xcode's STL problem, works fine in MW
  • Next by thread: Something is not getting cleaned...
  • Index(es):
    • Date
    • Thread