If I have an array
foo a[10000];
I can either let it be initialized with the default constructor, or
choose aggregate initialization and specify initializers for each element.
Since the trend is not to require default constructors (or move/copy
assignment operators), we should have a way to initialize arrays using
user-defined constructors.
We might allow something like
foo a[10000] = std::by_element(some_iterator);
The user supplied an input iterator, whose operator* returns a tuple,
and that tuple is used to to feed the constructor. For example
int a[10000] =
std::by_element(boost::make_transform_iterator(boost::make_counting_iterator(0),
[] (int x) { return std::tuple(x); }));
will initialize the array to the sequence 0..9999. We might relax the
constraints to allow non-tuples, in which case the result of operator*
is def to a single-argument constructor of the array element type:
std::array<foo, N> xform(std::array<bar, N> a) {
return std::array<foo, N>(std::by_element(a));
}
calls foo::foo(bar&).
Currently, we can solve the problem with std::aligned_storage and
placement new, but that's quite an ugly workaround.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/64e29521-ac56-f324-7140-23e824f418d8%40scylladb.com.
El dom., 8 de abril de 2018 13:48, Avi Kivity <a...@scylladb.com> escribió:
If I have an array
foo a[10000];
I can either let it be initialized with the default constructor, or
choose aggregate initialization and specify initializers for each element.
Long ago in a galaxy far far away...
If I have an array
foo a[10000];
I can either let it be initialized with the default constructor, or
choose aggregate initialization and specify initializers for each element.
Since the trend is not to require default constructors (or move/copy
assignment operators),
. And we really would rather people use that than language arrays.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b1e90895-1e46-41d0-a81d-f680aaf1e5e8%40isocpp.org.
El dom., 8 de abril de 2018 14:32, Nicol Bolas <jmck...@gmail.com> escribió:
On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:If I have an array
foo a[10000];
I can either let it be initialized with the default constructor, or
choose aggregate initialization and specify initializers for each element.
Since the trend is not to require default constructors (or move/copy
assignment operators),
Wait, there's a trend towards that? I certainly don't see it in the standard library. `variant` in particular practically bends over backwards to allow default construction.
The trend is to avoiding uninitialization. If `foo` had a proper default constructor, then none of the elements in that array will go uninitialized. And you can avoid leaving things uninitialized even if `foo` has trivial default construction by doing `foo a[10000] = {};`.
The idea of initializing an array by repeatedly calling some function is not without merit. The problem is that it doesn't work for `std::array`Why fixing that would be a problem? E.g. a special class&& receiving something like a lambda or std::function as constructor argument for being itself an argumeny for std::array ctor. By special I mean a specific std class, such as nothrow_t.auto i=0u;std::array<X, Y> arr(std::constructor_arg ([&i] (return ++i;)));
Well, I hope it makes it into the language one day. It's not a huge problem, but it's a wart, and your proposal fixes it very neatly.
On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:If I have an array
foo a[10000];
I can either let it be initialized with the default constructor, or
choose aggregate initialization and specify initializers for each element.
Since the trend is not to require default constructors (or move/copy
assignment operators),
Wait, there's a trend towards that? I certainly don't see it in the standard library. `variant` in particular practically bends over backwards to allow default construction.
The trend is to avoiding uninitialization. If `foo` had a proper default constructor, then none of the elements in that array will go uninitialized. And you can avoid leaving things uninitialized even if `foo` has trivial default construction by doing `foo a[10000] = {};`.
Minor problems in a library implementation:
- I think it will be hard to make it constexpr, and such a low-level facility should support constexpr
- it still requires move construction, which may not be possible for classes whose constructors capture 'this' (for example, in a lambda that gets registered somewhere).
Il giorno lunedì 9 aprile 2018 15:23:44 UTC+2, Avi Kivity ha scritto:Minor problems in a library implementation:
- I think it will be hard to make it constexpr, and such a low-level facility should support constexpr
I agree that having it constexpr would be useful. I'm not convinced it would be hard to get, what makes you so sure?
- it still requires move construction, which may not be possible for classes whose constructors capture 'this' (for example, in a lambda that gets registered somewhere).
I don't see where it would require a move construction. Could you please elaborate? (Notice that I assume we can have both guaranteed NRVO and guaranteed copy elision. Without either of them, the approach loses most of its appeal.)
A.
PS: I forgot to mention that we could also have a variant using uninitialized_move_n instead of uninitialized_copy_n.
On 2018-04-09 16:45, Alberto Barbati wrote:
Il giorno lunedì 9 aprile 2018 15:23:44 UTC+2, Avi Kivity ha scritto:Minor problems in a library implementation:
- I think it will be hard to make it constexpr, and such a low-level facility should support constexpr
I agree that having it constexpr would be useful. I'm not convinced it would be hard to get, what makes you so sure?
I'm not sure at all. I'm just not optimistic that all the union+placement new stuff would be constexpr.
On 2018-04-08 20:32, Nicol Bolas wrote:
On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:If I have an array
foo a[10000];
I can either let it be initialized with the default constructor, or
choose aggregate initialization and specify initializers for each element.
Since the trend is not to require default constructors (or move/copy
assignment operators),
Wait, there's a trend towards that? I certainly don't see it in the standard library. `variant` in particular practically bends over backwards to allow default construction.
The trend is towards not requiring default constructors in user types.
So I see plenty of evidence that DefaultConstructible remains a common expectation for user types.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ea8f7a49-fb18-488c-99ca-2e1fdffccd64%40isocpp.org.
On 9 April 2018 at 16:00, Nicol Bolas <jmck...@gmail.com> wrote:
On Monday, April 9, 2018 at 9:25:23 AM UTC-4, Avi Kivity wrote:
On 2018-04-08 20:32, Nicol Bolas wrote:
On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:If I have an array
foo a[10000];
I can either let it be initialized with the default constructor, or
choose aggregate initialization and specify initializers for each element.
Since the trend is not to require default constructors (or move/copy
assignment operators),
Wait, there's a trend towards that? I certainly don't see it in the standard library. `variant` in particular practically bends over backwards to allow default construction.
The trend is towards not requiring default constructors in user types.
Can you point to some evidence for this trend? Because I don't see a great increase in the number of types without default constructors in C++. Indeed, the range concepts use Semiregular everywhere, and Semiregular, requires DefaultConstructible.
FWIW 1 data point here.
In my code, types are only ever default-constructible if they are useful if constructed as such. If I'm deserialising non-default-constructible objects or storing them in arrays I use generator functions. I don't tolerate redundant constructions. It's bad form, invites inefficiency, and invites bugs.
On Monday, April 9, 2018 at 11:56:49 AM UTC-4, Avi Kivity wrote:On 2018-04-09 18:53, Richard Hodges wrote:
On 9 April 2018 at 16:00, Nicol Bolas <jmck...@gmail.com> wrote:
On Monday, April 9, 2018 at 9:25:23 AM UTC-4, Avi Kivity wrote:
On 2018-04-08 20:32, Nicol Bolas wrote:
On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:If I have an array
foo a[10000];
I can either let it be initialized with the default constructor, or
choose aggregate initialization and specify initializers for each element.
Since the trend is not to require default constructors (or move/copy
assignment operators),
Wait, there's a trend towards that? I certainly don't see it in the standard library. `variant` in particular practically bends over backwards to allow default construction.
The trend is towards not requiring default constructors in user types.
Can you point to some evidence for this trend? Because I don't see a great increase in the number of types without default constructors in C++. Indeed, the range concepts use Semiregular everywhere, and Semiregular, requires DefaultConstructible.
FWIW 1 data point here.
In my code, types are only ever default-constructible if they are useful if constructed as such. If I'm deserialising non-default-constructible objects or storing them in arrays I use generator functions. I don't tolerate redundant constructions. It's bad form, invites inefficiency, and invites bugs.
Ditto here. If I'm forced to add a default constructor, I'm extremely annoyed. Sometimes I refuse and use an std::optional instead.
That's all fine, but that doesn't change the fact that, as far as the standard is concerned, default constructors are frequently expected to be available, and this expectation is being encoded into increasingly large parts of the standard library. This is the opposite of "the trend is not to require default constructors". It may be a personal trend among some programmers, but it is not a general C++ trend, and certainly not a trend for the C++ standard library.
You cannot write an iterator that is not default constructible, for example. Even though no sane implementation of an algorithm will bother to use it, it must be there as part of the concept constraint.
I don't think the "avoid default construction/tors" is a good motivation for the proposal. A better one is to avoid unnecessary work.
We already have the annoyance of having `vector` value-initialize types, thus frequently provoking multiple initializations if you're just going to copy into the array. Having ways to avoid potentially-expensive default initialization that will quickly be overwritten by the actual data would be a good thing.