Feedback on the paper: 1. I support the additions especially since I encountered similar concepts implemented independently in multiple places, including myself. It seems like a natural compromise between separate compilation and generality. 2. Instead of adding a bunch of implicit constructors and implicit conversion operators to each container with contiguous storage one can proceed as follows. a) std::contiguous_iterator_tag can be added to the standard (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html for example). It would be a great addition by its own since generic code can optimize appropriately when ContiguousIterators to is_trivially_copyable<value_type> are used. b) Add *one* implicit constructor to array_ref: template<class R> array_ref(const R& x, typename enable_if< is_base_of< contiguous_iterator_tag, typename iterator_traits< decltype(begin(x)) >::iterator_category >::value, int >::type = 0); // use &*begin(x), (end(x) - begin(x)) to initialize. On Mon, Jan 30, 2012 at 16:20, Beman Dawes <bdawes@acm.org> wrote:
On Sat, Jan 28, 2012 at 8:12 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 01/28/2012 05:46 PM, Beman Dawes wrote:
Beman.github.com/string-interoperability/interop_white_paper.html describes Boost components intended to ease string interoperability in general and Unicode string interoperability in particular.
These proposals are the Boost version of the TR2 proposals made in N3336, Adapting Standard Library Strings and I/O to a Unicode World. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3336.html.
I'm very interested in hearing comments about either the Boost or the TR2 proposal. Are these useful additions? Is there a better way to achieve the same easy interoperability goals?
I think you should consider the points being made in N3334.
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3334.html
While this proposal isn't from Boost, it impacts interests of Boost developers enough that I think it is worth discussing here as a separate topic.
Mathias continues:
While that proposal is in my opinion not good enough, it raises an important issue that is often present with std::string-based or similar designs.
A function that takes a std::string, or a boost::filesystem::path for that matter, necessarily causes the [caller] to copy the data into a heap-allocated buffer, even if there is no need to.
Some std library string implementations avoid the heap allocation for small strings, but still there is an unnecessary copy happening even in those implementations. Your point is well taken and I've often worried about it with boost::filesystem::path.
Use of the range concept would solve that issue, but then that requires making the function a template. A type-erased range would be possible, but that has significant performance overhead. a string_ref or path_ref is maybe the lesser evil.
One of my blink reactions is that array_ref<T> and basic_string_ref<charT, traits> are range generators and I was a bit surprised to see the implementation was a pointer and length rather than two pointers. Or better yet, two iterators or an explicit range component. With iterators, a basic_string_ref could do encoding conversions on-the-fly without need of temporary strings. But I have no idea if that is workable or actually is better.
What do other Boosters think?
--Beman
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Yakov