Re: [boost] Fw: Is there interest for iterator based conversion library? attempt #2
Shunsuke Sogame wrote:
Your code looks similar to Boost.Serialization Data Flow. http://www.boost.org/libs/serialization/doc/dataflow.html
Yes, something is similar. As Dataflow as my library provide the set of basic transformation primitives and give possibility to compose them to create a complex compound converter. But there are several distinctions. 1 Create and instantiation of conversion entity in my library takes place in the same time. Dataflow at first create compound iterator type and then instantiate it. Such instantiation is simple and not clear. 2 My library provides as input as output conversion iterators, but Dataflow, it seems, provides only input iterator. Taking in mind "outputness" or "inputness" of iterator I distinguish transformation algorithms for concrete conversion. For output iterator it's one, for input iterator it's slightly (or not slightly) other. 3. Shifting operation is not clear at all in Dataflow.
But, we have now Boost.Range. Assume 'range_copy(rng,it)' just calls 'std::copy(boost::begin(rng),boost::end(rng),it)'.
range_copy(make_u32_to_u8_iterator_range(src), it);
There is no typedef's. You can look into <boost/regex/pending/unicode_iterator.hpp>, which shows such implementations.
It's not clear for me. range_copy is a good method, but make_XXX_to_YYY_iterator_range will be implemented using the same typedefs. And what is more how many make_ZZZ functions will be provided? I guess there are very many combinations of possible XXX and YYY.
Alexander A Potocki wrote:
Shunsuke Sogame wrote:
Your code looks similar to Boost.Serialization Data Flow. http://www.boost.org/libs/serialization/doc/dataflow.html
Yes, something is similar. As Dataflow as my library provide the set of basic transformation primitives and give possibility to compose them to create a complex compound converter.
But there are several distinctions.
1 Create and instantiation of conversion entity in my library takes place in the same time. Dataflow at first create compound iterator type and then instantiate it. Such instantiation is simple and not clear.
2 My library provides as input as output conversion iterators, but Dataflow, it seems, provides only input iterator. Taking in mind "outputness" or "inputness" of iterator I distinguish transformation algorithms for concrete conversion. For output iterator it's one, for input iterator it's slightly (or not slightly) other.
3. Shifting operation is not clear at all in Dataflow.
But, we have now Boost.Range. Assume 'range_copy(rng,it)' just calls 'std::copy(boost::begin(rng),boost::end(rng),it)'.
range_copy(make_u32_to_u8_iterator_range(src), it);
There is no typedef's. You can look into <boost/regex/pending/unicode_iterator.hpp>, which shows such implementations.
It's not clear for me. range_copy is a good method, but make_XXX_to_YYY_iterator_range will be implemented using the same typedefs. And what is more how many make_ZZZ functions will be provided? I guess there are very many combinations of possible XXX and YYY.
Sorry, I maybe overlooked what you made. Trotter already(almost?) seems to achieve what I meant. If I borrow the range-adaptors syntax from http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1871.html , Trotter might be written as: range_copy( utf16string|trotter_coded(cvt::utf16() >> cvt::utf8()), std::back_inserter(result) ); Actually I tried to write such a wrapper for trotter. (But I failed. I have to look into trotter more. :-) -- Shunsuke Sogame
participants (2)
-
Alexander A Potocki -
Shunsuke Sogame