Subject: Re: [boost] [Locale] Preview of 3rd version
From: Cory Nelson (phrosty_at_[hidden])
Date: 2010-09-11 16:14:57
On Sat, Sep 11, 2010 at 11:20 AM, Artyom <artyomtnk_at_[hidden]> 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
>> * 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.
> 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
> Â 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!
-- Cory Nelson http://int64.org
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk