On Sat, Sep 11, 2010 at 11:20 AM, Artyom <artyomtnk@yahoo.com> wrote:
* an ActiveX component for the web, where you have significantly restricted permissions and probably fall under the above case, but with more restrictions;
1. ActiveX should die... but this is other story ;-) 2. You would anyway probably would not be able to use ICU in ActiveX, but probably this case I can agree that file system may be a strong restriction.
A similar example is Google Chrome. Because it sandboxes processes, they needed to write a custom virtual filesystem for SQLite that routes file opening to another process.
* a game or other application where your resources are baked into virtual filesystem images for efficiency and organizational purposes;
I've mentioned that efficiency is not an issue
Presumptuous.
* a video game console, where you may have a filesystem to work with, or non-standard interfaces to work with one;
You would not even have ICU on such platform not talking about any reasonable localization support from C++ or even C library.
So boost.locale would be quite useless. So I don't really buy this.
Again, presumptuous.
But somebody would complain that you need to open a file for this... and I have **very good** reasons to use FILE * and not fstream.
1. Windows - wide path:
a) need to support UTF-8 paths (so need to convert them to utf-16 and then call _wfopen) b) I can't use std::ifstream as it does not support wide paths and I don't want add dependency on other boost library c) I need to support both ANSI and Wide API under windows but I want to keep one type of path and not eject wide strings where I don't need them.
I'm not sure about other implementations, but VC++ supports wide paths in fstream since 2008.
2. Memory mapping
I expect at some point to load dictionaries for UTF-8 charsets via memory mapping, so it would not waste memory for each loaded dictionary by each application.
Maybe add another function<pair<shared_ptr<char const>,size_t>> then.
Actually one of the most widely deployed localization library - gettext has much harder and stricter restrictions, and yet Boost.Locale implements all gettext gives and much more.
I hadn't seen too much complains about possibility to load dictionaries from gettext developers (unlike other issues)
Most libraries are not held to the same standard that Boost libraries are.
If it is so important I can add this. But believe me, I wish it would be the biggest issue in localization area - how to load dictionaries from virtual and non-standard file system :-)
I think anyone who's dealt with l10n wishes this! Thank you. -- Cory Nelson http://int64.org