$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [locale] Review: Tutorial
From: Gevorg Voskanyan (v_gevorg_at_[hidden])
Date: 2011-04-18 08:58:17
Artyom wrote:
> Gevorg Voskanyan wrote:
> > why "double now=time(0);" and not "time_t   now=time(0);" ?
> > 
> 
> No specific reason.
Looks kinda strange, not sure if it's appropriate to be kept that way in the 
tutorial. After all, nobody will ask "why time_t?", but some might ask "why 
double?".
> > "The source text is not copied."  Sometimes 'not' is highlighted, and  
>sometimes 
>
> >
> > 'is'. So  what does it try to say after all? That the provided  string 
>argument 
>
> 
> > must not die before the translated string is   fetched?
> 
> Already noted there is a small error.
> std::string is copied  no need to keep it, while "char const *" should not
> die - usual static  text.
Makes sense, but in addition to "is *not* copied" statements, a big warning 
about this needs to be inserted, and make it obvious that it applies to all 
those involved functions.
> >  And what date-time range does the ICU backend  support?
> > 
> 
> Actually time before BC and long after, virtually limited by
> range of  double.
Good, but needs to be mentioned in the doc.
> > or a "class  bigint" example which uses the Boost.Locale  number 
> > formatting info for its  I/O.
> > Bonus points if they  fallback to std facets if 
> > corresponding  Boost.Locale info is  missing from the  stream!
> 
> Actually it is not quite possible, at  least with ICU backend as
> it supports only double, int32 and int64 types, so  it wouldn't
> be possible to do it.
I'd consider it a severe limitation if that is really impossible. Can't I print 
my arbitrary big integers in the properly localized way? ICU obviously knows the 
rules for formatting numbers in the locales it supports, and uses that info to 
format double, int32, int64. Isn't there a way to query that necessary info from 
ICU to format numbers outside of it?
> It can be done somehow for non-ICU  backends that provide std::numpunct,
Are you saying here that a std::numpunct-like facet can't be implemented with 
the ICU backend?
> (it is not enough for ICU case as it  is too primitive to handle
> all required options)
Yes, I understand that std::numpunct interface is not good enough for all 
locales. What I would like to see in Boost.Locale is a facet much like numpunct 
but such that it is correct for all locales, and uses ICU to achieve that when 
that backend is enabled. Of course if that is possible at all?
> Thanks, Very good  points.
>    Artyom
Thanks,
Gevorg