Re: [boost] [locale] Review

Subject: Re: [boost] [locale] Review
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-04-21 14:06:57

> >> Inlining gives  very good performance benefits.
> > 
> > Some people (performance freaks  would disagree with you)
> > see Linux kernel coding style.
> > 
> >  But this is other story.
> 
> High-performance computing is my job, but  whatever.
> 

Mine too :-)

> > However  token_iterator designed to create tokens.
> > 
> > Note, if token  iterator was returning a range
> > you wouldn't be able to call
> > 
> >     std::string s = *it;
> 
> Is that a problem? Why would  you want to do such
> a thing in the first place? You already have the
> data, why  copy it?

Why? Because that what 99% of 
programmers would actually do
if they want specific token.

> > I see, but sometimes I don't really agree that
> >  the interface you suggest simplifies things,
> > sometimes it may but not  always.
> > 
> > But this is my point of view.
> 
> I don't see how  that kind of simplification
> can be subject to points or view.
> 
> Not  requiring users to convert to your format
> is simpler than requiring them to do  so, it's a fact.
> 
> If I wanted to use your library, it would be ironic
> if  the first thing I had to do is write a wrapper
> around it. I thought it was a  library that aimed
> at being a wrapper of ICU with a nice C++  interface.
> 

It really depends on your use pattern.

See a small sample when I use collation in
my real application to display index of topics:

    //
    // note std::locale has
    // bool operator()(std::string const &,std::string const &) const
    //
    typedef std::multimap<std::string,std::string,std::locale> mapping_type;
    mapping_type mapping(context().locale());

    cppdb::result r;
    cppdb::session sql(conn);
    r=sql<< "SELECT slug,title FROM pages WHERE lang=?" << locale_name;

    while(r.next()) {
        std::string slug,t;
        r >> slug >> t;
        mapping.insert(std::pair<std::string,std::string>(t,slug));
    }

How easy and simple, isn't it?

How would it look like with ranges API?

> 
> 
> > You assume that "whatever" facet is stateful, and  it is not
> > it is const and stateless, unless I provide some  specific
> > state as additional parameter.
> 
> No, I assumed it was  stateless.
> 

Your sample just took some two generic template pointers
that can't be passed to virtual functions that know
anything about them unless you use any_iterator
or something like that.

So at lease how it was written it was wrong.

> Your algorithm seems wrong.
> If the output buffer is too  small, simply don't process
> the data that would require a larger  buffer.

If you know that would it size be?

> 
> Or you could design the code so that the output buffer is always
> statically guaranteed to be big enough.
> 

What is the guarantee? Do you have specific suggestions for
Case handling where the charset is changed in runtime, locale
is changed in runtime and so on?

> And don't copy the whole input  range to a contiguous
> buffer (that would need to be heap-allocated),
> copy it in  bits to an automatic buffer.
>

Some operations require to have entire text and not
small part of it, you had written some Unicode
algorithms, you know it.

Now add a charset know in the run time to make it
even more fun.
 
> 
> > But this is really "Dikumware STL"  problem because other
> > normal libraries do it in big chunks as they  should.
> 
> If your library requires on codecvt facets to be 
> efficient and  the most popular implementation isn't,
> then it becomes your library's  problem.
>

No, it does not requires, but if current implementation
is already bad, how can I do it better?

Artyom