4 ms·

I think there are some good, sound principles here; I've dealt with some to one extent or another, and I couldn't find anything to disagree with. I worked on a

I think there are some good, sound principles here; I've dealt with some to one extent or another, and I couldn't find anything to disagree with. I worked on a port of a large Java application to C++ on a different platform, and we went back and forth for a while trying to choose between utf-8 and utf-16 as a standard character encoding. We ultimately settled on utf-8, even though the Java code had used utf-16 (because it's Java's native encoding); I'm not surprised to read here that utf-8 is the way to go. Utf-16 is at odds with the expectations of every C and C++ standard library function and the language itself, which would have been a source of annoyances that would never end. It's very, very hard to make any generalization about programming, and so I suspect that in his confident pronouncement that cross platform should never add more than a small amount of time to a project, there is something he's ignoring. The application they sell is for backup, and so it would probably be close to ideal for making cross-platform. I think he underestimates how complex GUI code can get when dealing with requirements less trivial than a backup application. He also basically ignored Macintosh and ObjectiveC. I don't recall what the state of Macintosh was at the time this piece was written, but I'm pretty sure ObjectiveC was the standard language on Mac then as it is now. I think there are sage principles here, though.

kosinus 12y ago
ObjC and C go extremely well together, more so than C++ and C. You just have to make sure platform specific stuff that is in ObjC and GUI stuff is separate, which he advocates for any way, if I understood correctly.
- mtdewcmu 12y ago
  I think you are right about separating the ObjC. C++ and ObjC don't play so well together, either, so if your primary language was C++, I think you'd need a plan around how to deal with ObjC.
  - pjmlp 12y ago
    Ever heard of Objective-C++? It is also supported by Objective-C compilers.
    - mtdewcmu 12y ago
      The problem is that C++ and ObjectiveC have overlapping purposes. The issue isn't that it's impossible to use them together. The issue is that you will have to have a strategy for dealing with conflicts before they occur.
      - pjmlp 12y ago
        That is true. Actually such considerations should be part of any mixed language project, specially in the presence of portable code.
  - tylerneylon 12y ago
    gcc and clang can handle mixed Objective-C and C++ in a single source file (some call it Objective-C++). The only tricky part is linking since C++ and ObjC++ use a different symbol name convention than C/ObjC; but you can still link between them by using extern "C" declarations in the right places.
mikeash 12y ago
UTF-16 is a sad encoding and there's essentially no reason to ever use it except when interfacing with something that insists on it. UCS-2 made a lot of sense back in the day when Unicode was supposed to be 16-bit and you'd just have one 16-bit "char" for each Unicode code point. Bliss! Then Unicode breached the BMP and this didn't work anymore. UTF-16 is just a way to let all that old code that assumes 16-bit Unicode to keep working. You get all the disadvantages of UTF-8 (no 1:1 correspondence between code units and code points) and none of the advantages (widespread compatibility with non-Unicode-aware tools, mostly-reliable discrimination between actual text and random binary data that might look like text). One can kind of make a case for UTF-32 in some cases, but UTF-16 is almost never the right choice unless there is literally no other.
- cpeterso 12y ago
  btw, the wchar_t typedef is 16 bits for MSVC, but 32 bits for gcc (even for MinG on Windows!). UTF-16 is the worst of all worlds.
  - brianwski 12y ago
    Original author here.... This is why we do not use wchar_t as a cross platform type. We like "char *" with NULL terminated Utf8 strings, which works really well on all platforms. Unfortunately on Windows, some of the core API still take Utf16 (2 bytes per char). Since it is a Windows call it must be in an #ifdef anyway, and so IMMEDIATELY BEFORE calling into the Windows call at the last possible moment we convert the string from Utf8 to Utf16. It sounds like a pain, but after you have wrapped all your OS specific calls (like File I/O) you're calling the higher level anyway, and it was completely worth it.
- mtdewcmu 12y ago
  That helps put some things in perspective. Unicode is not a well-understood topic among programmers, I've noticed (at least in the US), and for something so important it's surprisingly difficult to find information. The distinction between UCS-2 and UTF-16 must have made sense at one time, but it makes no sense anymore, and it's not necessarily easy to track down the explanation for why there are two 16-bit formats. Thanks.
brianwski 12y ago
Author here (late to the discussion): > He also basically ignored Macintosh and ObjectiveC At Backblaze (my company) we write all lower level common libraries in 'C' and C++ so like a cross platform HashTable, and file I/O functions. It turns out ObjectiveC on the Macintosh is a PERFECT SUPERSET of 'C' and C++ so luckily all the Objective C code can call into our OpenSSL for encryption and can call into our base libraries for File I/O.

kosinus 12y ago

ObjC and C go extremely well together, more so than C++ and C. You just have to make sure platform specific stuff that is in ObjC and GUI stuff is separate, which he advocates for any way, if I understood correctly.

mtdewcmu 12y ago
I think you are right about separating the ObjC. C++ and ObjC don't play so well together, either, so if your primary language was C++, I think you'd need a plan around how to deal with ObjC.
- pjmlp 12y ago
  Ever heard of Objective-C++? It is also supported by Objective-C compilers.
  - mtdewcmu 12y ago
    The problem is that C++ and ObjectiveC have overlapping purposes. The issue isn't that it's impossible to use them together. The issue is that you will have to have a strategy for dealing with conflicts before they occur.
    - pjmlp 12y ago
      That is true. Actually such considerations should be part of any mixed language project, specially in the presence of portable code.
- tylerneylon 12y ago
  gcc and clang can handle mixed Objective-C and C++ in a single source file (some call it Objective-C++). The only tricky part is linking since C++ and ObjC++ use a different symbol name convention than C/ObjC; but you can still link between them by using extern "C" declarations in the right places.

mikeash 12y ago

UTF-16 is a sad encoding and there's essentially no reason to ever use it except when interfacing with something that insists on it. UCS-2 made a lot of sense back in the day when Unicode was supposed to be 16-bit and you'd just have one 16-bit "char" for each Unicode code point. Bliss! Then Unicode breached the BMP and this didn't work anymore. UTF-16 is just a way to let all that old code that assumes 16-bit Unicode to keep working. You get all the disadvantages of UTF-8 (no 1:1 correspondence between code units and code points) and none of the advantages (widespread compatibility with non-Unicode-aware tools, mostly-reliable discrimination between actual text and random binary data that might look like text). One can kind of make a case for UTF-32 in some cases, but UTF-16 is almost never the right choice unless there is literally no other.

cpeterso 12y ago
btw, the wchar_t typedef is 16 bits for MSVC, but 32 bits for gcc (even for MinG on Windows!). UTF-16 is the worst of all worlds.
- brianwski 12y ago
  Original author here.... This is why we do not use wchar_t as a cross platform type. We like "char *" with NULL terminated Utf8 strings, which works really well on all platforms. Unfortunately on Windows, some of the core API still take Utf16 (2 bytes per char). Since it is a Windows call it must be in an #ifdef anyway, and so IMMEDIATELY BEFORE calling into the Windows call at the last possible moment we convert the string from Utf8 to Utf16. It sounds like a pain, but after you have wrapped all your OS specific calls (like File I/O) you're calling the higher level anyway, and it was completely worth it.
mtdewcmu 12y ago
That helps put some things in perspective. Unicode is not a well-understood topic among programmers, I've noticed (at least in the US), and for something so important it's surprisingly difficult to find information. The distinction between UCS-2 and UTF-16 must have made sense at one time, but it makes no sense anymore, and it's not necessarily easy to track down the explanation for why there are two 16-bit formats. Thanks.

brianwski 12y ago

Author here (late to the discussion): > He also basically ignored Macintosh and ObjectiveC At Backblaze (my company) we write all lower level common libraries in 'C' and C++ so like a cross platform HashTable, and file I/O functions. It turns out ObjectiveC on the Macintosh is a PERFECT SUPERSET of 'C' and C++ so luckily all the Objective C code can call into our OpenSSL for encryption and can call into our base libraries for File I/O.