Re: [boost] [c++TR2] N3334, Proposing array_ref<T> and string_ref

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
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_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
> 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