Topic: Can we bind and deduce array references to/from unknown sized arrays in C++0x?
Author: "Johannes Schaub (litb)" <schaub-johannes@web.de>
Date: Mon, 10 May 2010 14:03:27 CST Raw View
Faisal Vali wrote:
> I have a few questions about list-initialization concerning arrays and
> references to arrays. If anyone could clarify these for me (with
> references to the FCD) I would surely appreciate it.
>
> I've been told(*) that the FCD is quite clear about the following
> code:
>
> const int (&arr)[3] = {1,2,3}; // Invalid
> int (&&arr)[3] = {1,2,3}; // Invalid
> int arr[]{1,2,3,4}; // Valid
>
> But Given:
>
> typedef int UI[];
>
> template<class T, int N>
> void deduce(const T(&a)[N]);
>
> Are the following valid in C++0x?
>
> 1) int arr[3] = int[] {1, 2, 3 };
> (gcc 4.5 says above is syntactically invalid)
>
Not valid. "int[]" is not a simple-type-specifier nor a typename-specifier.
> 2) int arr[3] = (int[]) {1, 2, 3 };
> (gcc 4.5 says above is valid)
>
Not valid. The "(int[]){1, 2, 3}" is a C99 compound literal yielding an
lvalue of type "int[3]", but which cant initialize an array.
> 3) int arr[3] = UI{1,2,3};
> (gcc 4.5 says above is valid)
>
Invalid. While the construct "UI{1,2,3}" curiously is valid according to
5.2.3/3 and yields a prvalue of type "int[3]", the initialization of the
array using it is not, according to 8.5/16bullet5.
> 4) const int (&arr)[3] = UI{1,2,3};
> (gcc 4.5 says above is valid)
>
Type of "UI{1,2,3}" is int[3] and is a prvalue according to 5.2.3/3. It's
then valid according to 8.5.3/5bullet2subbullet3.
> 5) int (&&arr)[3] = UI{1,2,3};
> (gcc 4.5 says above is valid)
>
Same matter as 4).
> 6) deduce(UI{2,3,4,5,6,7});
> (gcc 4.5 says above is valid - and deduces T and N appropriately).
>
Valid. T and N are deduced properly. The deduced A is more cv-qualified than
A, but that difference can be bridged by argument deduction according to
14.8.2.1/4.
> Is gcc 4.5 right in rejecting fragment (1) and accepting fragments
> (2,3,4,5,6)?
>
See attached comments :)
> Is the FCD pretty clear about all of this?
>
I find it pretty clear about these numbers, but i find it confusing about
"UI{1, 2, 3}" being a "temporary". 12.2 only talks about temporary class
type objects, so what are temporary arrays? Will "4)" lengthen the lifetime
of the array? Apart from that it seems to be clear.
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Mon, 10 May 2010 14:06:18 CST Raw View
On 10 May, 00:14, Faisal Vali <fais...@gmail.com> wrote:
> I have a few questions about list-initialization concerning arrays and
> references to arrays. If anyone could clarify these for me (with
> references to the FCD) I would surely appreciate it.
>
> I've been told(*) that the FCD is quite clear about the following
> code:
>
> const int (&arr)[3] = {1,2,3}; // Invalid
> int (&&arr)[3] = {1,2,3}; // Invalid
> int arr[]{1,2,3,4}; // Valid
I believe that the explanation provided by Anthony Williams is totally
incorrect. First, the initializer for a reference may be an expression
that designates a function or a pure value (for example, integer
literal or enumerator) though they are not objects. Second, the
wording of the following bullets in 8.5/16
-- If the initializer is a braced-init-list, the object is list-
initialized (8.5.4).
-- If the destination type is a reference type, see 8.5.3.
must be changed to
-- If the initializer is a braced-init-list, the object *or reference*
is list-initialized (8.5.4).
-- *Otherwise* if the destination type is a reference type, see 8.5.3.
since 8.5.4 partially describes reference initialization.
Finally, the initialization of a reference to array with a non-empty
braced-init-list is ill-formed according to 8.5.4/3; note, however,
that the following initializations should be considered well-formed:
int &&ref = {};
// well-formed
int (&&ref_to_arr)[1] = {};
// well-formed
> But Given:
>
> typedef int UI[];
>
> template<class T, int N>
> void deduce(const T(&a)[N]);
>
> Are the following valid in C++0x?
>
> 1) int arr[3] = int[] {1, 2, 3 };
> (gcc 4.5 says above is syntactically invalid)
It is really syntactically incorrect. int[] is not a simple-type-
specifier (7.1.6.2) nor a typename-specifier (14.6), so int[] {1, 2,
3 } is not a correct explicit type conversion (5.2.3).
> 2) int arr[3] = (int[]) {1, 2, 3 };
> (gcc 4.5 says above is valid)
It is syntactically incorrect. {1, 2, 3 } is not a cast-expression.
> 3) int arr[3] = UI{1,2,3};
> (gcc 4.5 says above is valid)
It is semantically incorrect. See 8.5/16 (with respect to arr):
The semantics of initializers are as follows. [...]
-- If the initializer is a braced-init-list, the object is list-
initialized (8.5.4). [irrelevant case: UI{1,2,3} is not a braced-init-
list]
-- If the destination type is a reference type, see 8.5.3. [irrelevant
case]
-- If the destination type is an array of characters, an array of
char16_t, an array of char32_t, or an array of wchar_t, and the
initializer is a string literal, see 8.5.2. [irrelevant case]
-- If the initializer is (), the object is value-initialized.
[irrelevant case]
-- Otherwise, if the destination type is an array, the program is ill-
formed. [this bullet is appropriate]
> 4) const int (&arr)[3] = UI{1,2,3};
> (gcc 4.5 says above is valid)
UI{1,2,3} is an explicit type conversion (5.2.3). According to
5.2.3/3,
[...] a simple-type-specifier or typename-specifier followed by a
braced-init-list creates a temporary object of the specified type
[...]
In our case the specified type is an array of unknown bound. An object
of such a type cannot be created. It is unclear whether 8.5.1/4 is
relevant here. I think, the wording in the specification should be
improved.
It is also unclear whether an array of const-qualified type is const-
qualified - see core issue 1059:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1059
The answer for this question affects the well-formedness of the lvalue
reference initialization by rvalue.
> 5) int (&&arr)[3] = UI{1,2,3};
> (gcc 4.5 says above is valid)
See above.
> 6) deduce(UI{2,3,4,5,6,7});
> (gcc 4.5 says above is valid - and deduces T and N appropriately).
See above.
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Faisal Vali <faisalv@gmail.com>
Date: Sun, 9 May 2010 14:14:06 CST Raw View
I have a few questions about list-initialization concerning arrays and
references to arrays. If anyone could clarify these for me (with
references to the FCD) I would surely appreciate it.
I've been told(*) that the FCD is quite clear about the following
code:
const int (&arr)[3] = {1,2,3}; // Invalid
int (&&arr)[3] = {1,2,3}; // Invalid
int arr[]{1,2,3,4}; // Valid
But Given:
typedef int UI[];
template<class T, int N>
void deduce(const T(&a)[N]);
Are the following valid in C++0x?
1) int arr[3] = int[] {1, 2, 3 };
(gcc 4.5 says above is syntactically invalid)
2) int arr[3] = (int[]) {1, 2, 3 };
(gcc 4.5 says above is valid)
3) int arr[3] = UI{1,2,3};
(gcc 4.5 says above is valid)
4) const int (&arr)[3] = UI{1,2,3};
(gcc 4.5 says above is valid)
5) int (&&arr)[3] = UI{1,2,3};
(gcc 4.5 says above is valid)
6) deduce(UI{2,3,4,5,6,7});
(gcc 4.5 says above is valid - and deduces T and N appropriately).
Is gcc 4.5 right in rejecting fragment (1) and accepting fragments
(2,3,4,5,6)?
Is the FCD pretty clear about all of this?
Thanks in advance for any help you can provide.
regards,
Faisal Vali
Radiation Oncology
Loyola
*http://www.justsoftwaresolutions.co.uk/cplusplus/c++0x-now-at-fcd.html
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]