Subject: Re: [boost] [c++TR2] N3334, Proposing array_ref<T> and string_ref
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2012-01-31 13:57:26
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
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,
>::type = 0);
// use &*begin(x), (end(x) - begin(x)) to initialize.
On Mon, Jan 30, 2012 at 16:20, Beman Dawes <bdawes_at_[hidden]> wrote:
> On Sat, Jan 28, 2012 at 8:12 PM, Mathias Gaunard
> <mathias.gaunard_at_[hidden]> 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
> > 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
> > matter, necessarily causes the [caller] to copy the data into a
> > 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,
> > 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?
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk