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