C++ Logo


Advanced search

Re: container constructors for containers

From: Tony V E <tvaneerd_at_[hidden]>
Date: Fri, 6 Sep 2019 13:57:06 -0400
On Fri, Sep 6, 2019 at 1:06 PM Lyberta via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> Eduard Antonyan via Std-Discussion:
> > Every single time I've used the InputIterator constructors of various
> > containers (e.g. vector or set), it's been to convert an existing
> container
> > from one type to another (e.g. set to a vector). As such my code could've
> > been simpler and more concise if the constructors simply took a container
> > as an argument and did the begin/end internally.
> >
> > Any reasons to not have such constructors? These are trivial to write and
> > I'm happy to provide the code, but perhaps I'm missing something.
> >
> > Thanks.
> >
> >
> Yes, every function that takes a pair of iterators should have an
> overload that takes std::ranges::input_range (or similar). This should
> be easy to add in C++23.
"should be easy"
hahaha, are you new here? :-)

Given the number of constructors and overloads already in place, it might
not be too easy. In fact, it never is.
The first example that comes to mind is:

std::set<int> s = ...;
std::vector v {s}; // is this a vector of ints, or a vector of sets???

That's using CTAD, but I suspect someone can come up with other examples
that either break existing code, or will look inconsistent with new code.

You could somehow disambiguate, however:

std::vector v(std::something(s));
std::vector v(std::something, s);

where 'something' is some specific type that vector recognizes (ie somewhat
similar to how new is specialized for std::nothrow)

Be seeing you,

Received on 2019-09-06 12:59:27