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;
r=sql<< "SELECT slug,title FROM pages WHERE lang=?" << locale_name;
r >> slug >> t;
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk