Re: [boost] [Locale] Preview of 3rd version

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

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