In C++14 is it valid to use a double in the dimension of a new expression?











up vote
12
down vote

favorite












In C++14 given the following code:



void foo() {
double d = 5.0;
auto p1 = new int[d];
}


clang compiles this without diagnostic while gcc on the other hand produces the following diagnostic (see it live):



error: expression in new-declarator must have integral or enumeration type
7 | auto p1 = new int[d];
|


I specifically labeled this C++14 because in C++11 mode clang treats this as ill-formed and produces the following diagnostic (see it live):



error: array size expression must have integral or unscoped enumeration type, not 'double'
auto p1 = new int[d];
^ ~


Is clang correct? If so what changed in C++14 to allow this?










share|improve this question


















  • 1




    Out of curiosity, a double allows for fractional quantities, so how would you allocate 0.75 of an integer, such as int * p_array = new int [0.75];? Or take something like 0.33333333, which is kind of difficult to allocate.
    – Thomas Matthews
    1 hour ago












  • I expect it to use the binary value of it as an integer even when it's a double so 0.75 would be 0011111111101 as an integer it's 16360
    – tomer zeitune
    34 mins ago










  • @ThomasMatthews no this would end up being a float to integral conversion and would truncate the float
    – Shafik Yaghmour
    25 mins ago















up vote
12
down vote

favorite












In C++14 given the following code:



void foo() {
double d = 5.0;
auto p1 = new int[d];
}


clang compiles this without diagnostic while gcc on the other hand produces the following diagnostic (see it live):



error: expression in new-declarator must have integral or enumeration type
7 | auto p1 = new int[d];
|


I specifically labeled this C++14 because in C++11 mode clang treats this as ill-formed and produces the following diagnostic (see it live):



error: array size expression must have integral or unscoped enumeration type, not 'double'
auto p1 = new int[d];
^ ~


Is clang correct? If so what changed in C++14 to allow this?










share|improve this question


















  • 1




    Out of curiosity, a double allows for fractional quantities, so how would you allocate 0.75 of an integer, such as int * p_array = new int [0.75];? Or take something like 0.33333333, which is kind of difficult to allocate.
    – Thomas Matthews
    1 hour ago












  • I expect it to use the binary value of it as an integer even when it's a double so 0.75 would be 0011111111101 as an integer it's 16360
    – tomer zeitune
    34 mins ago










  • @ThomasMatthews no this would end up being a float to integral conversion and would truncate the float
    – Shafik Yaghmour
    25 mins ago













up vote
12
down vote

favorite









up vote
12
down vote

favorite











In C++14 given the following code:



void foo() {
double d = 5.0;
auto p1 = new int[d];
}


clang compiles this without diagnostic while gcc on the other hand produces the following diagnostic (see it live):



error: expression in new-declarator must have integral or enumeration type
7 | auto p1 = new int[d];
|


I specifically labeled this C++14 because in C++11 mode clang treats this as ill-formed and produces the following diagnostic (see it live):



error: array size expression must have integral or unscoped enumeration type, not 'double'
auto p1 = new int[d];
^ ~


Is clang correct? If so what changed in C++14 to allow this?










share|improve this question













In C++14 given the following code:



void foo() {
double d = 5.0;
auto p1 = new int[d];
}


clang compiles this without diagnostic while gcc on the other hand produces the following diagnostic (see it live):



error: expression in new-declarator must have integral or enumeration type
7 | auto p1 = new int[d];
|


I specifically labeled this C++14 because in C++11 mode clang treats this as ill-formed and produces the following diagnostic (see it live):



error: array size expression must have integral or unscoped enumeration type, not 'double'
auto p1 = new int[d];
^ ~


Is clang correct? If so what changed in C++14 to allow this?







c++ c++14 language-lawyer






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 2 hours ago









Shafik Yaghmour

124k23317524




124k23317524








  • 1




    Out of curiosity, a double allows for fractional quantities, so how would you allocate 0.75 of an integer, such as int * p_array = new int [0.75];? Or take something like 0.33333333, which is kind of difficult to allocate.
    – Thomas Matthews
    1 hour ago












  • I expect it to use the binary value of it as an integer even when it's a double so 0.75 would be 0011111111101 as an integer it's 16360
    – tomer zeitune
    34 mins ago










  • @ThomasMatthews no this would end up being a float to integral conversion and would truncate the float
    – Shafik Yaghmour
    25 mins ago














  • 1




    Out of curiosity, a double allows for fractional quantities, so how would you allocate 0.75 of an integer, such as int * p_array = new int [0.75];? Or take something like 0.33333333, which is kind of difficult to allocate.
    – Thomas Matthews
    1 hour ago












  • I expect it to use the binary value of it as an integer even when it's a double so 0.75 would be 0011111111101 as an integer it's 16360
    – tomer zeitune
    34 mins ago










  • @ThomasMatthews no this would end up being a float to integral conversion and would truncate the float
    – Shafik Yaghmour
    25 mins ago








1




1




Out of curiosity, a double allows for fractional quantities, so how would you allocate 0.75 of an integer, such as int * p_array = new int [0.75];? Or take something like 0.33333333, which is kind of difficult to allocate.
– Thomas Matthews
1 hour ago






Out of curiosity, a double allows for fractional quantities, so how would you allocate 0.75 of an integer, such as int * p_array = new int [0.75];? Or take something like 0.33333333, which is kind of difficult to allocate.
– Thomas Matthews
1 hour ago














I expect it to use the binary value of it as an integer even when it's a double so 0.75 would be 0011111111101 as an integer it's 16360
– tomer zeitune
34 mins ago




I expect it to use the binary value of it as an integer even when it's a double so 0.75 would be 0011111111101 as an integer it's 16360
– tomer zeitune
34 mins ago












@ThomasMatthews no this would end up being a float to integral conversion and would truncate the float
– Shafik Yaghmour
25 mins ago




@ThomasMatthews no this would end up being a float to integral conversion and would truncate the float
– Shafik Yaghmour
25 mins ago












1 Answer
1






active

oldest

votes

















up vote
17
down vote













clang is correct, the key wording in [expr.new]p6 changes from this in the C++11 draft:




Every constant-expression in a noptr-new-declarator shall be an integral constant expression ([expr.const]) and evaluate to a strictly positive value. The expression in a noptr-new-declarator shall be of integral type, unscoped enumeration type, or a class type for which a single non-explicit conversion function to integral or unscoped enumeration type exists ([class.conv]). If the expression is of class type, the expression is converted by calling that conversion function, and the result of the conversion is used in place of the original expression. …




to this in the C++14 draft:




Every constant-expression in a noptr-new-declarator shall be a converted constant expression ([expr.const]) of type std::size_t and shall evaluate to a strictly positive value. The expression in a noptr-new-declaratoris implicitly converted to std::size_t. …




So in C++14 the requirement for the expression noptr-new-declarator was weakened to not require an integral, unscoped enumeration or a class with a
single non-explicit conversion function to one of those types but just allow implicit conversions to size_t.



This change came from the proposal A Proposal to Tweak Certain C++ Contextual Conversions, v3.






share|improve this answer

















  • 2




    I am dubious about the usefulness of allowing double to be used as the size of an array... it seems more likely to let bugs pass silently than anything else :(
    – Matthieu M.
    37 mins ago






  • 2




    @MatthieuM. I agree, I believe it is a defect and that the intent was really to say contextually implicitly converted. I am filing a defect report on this hopefully today but who knows maybe I am wrong :-(
    – Shafik Yaghmour
    28 mins ago













Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53745158%2fin-c14-is-it-valid-to-use-a-double-in-the-dimension-of-a-new-expression%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
17
down vote













clang is correct, the key wording in [expr.new]p6 changes from this in the C++11 draft:




Every constant-expression in a noptr-new-declarator shall be an integral constant expression ([expr.const]) and evaluate to a strictly positive value. The expression in a noptr-new-declarator shall be of integral type, unscoped enumeration type, or a class type for which a single non-explicit conversion function to integral or unscoped enumeration type exists ([class.conv]). If the expression is of class type, the expression is converted by calling that conversion function, and the result of the conversion is used in place of the original expression. …




to this in the C++14 draft:




Every constant-expression in a noptr-new-declarator shall be a converted constant expression ([expr.const]) of type std::size_t and shall evaluate to a strictly positive value. The expression in a noptr-new-declaratoris implicitly converted to std::size_t. …




So in C++14 the requirement for the expression noptr-new-declarator was weakened to not require an integral, unscoped enumeration or a class with a
single non-explicit conversion function to one of those types but just allow implicit conversions to size_t.



This change came from the proposal A Proposal to Tweak Certain C++ Contextual Conversions, v3.






share|improve this answer

















  • 2




    I am dubious about the usefulness of allowing double to be used as the size of an array... it seems more likely to let bugs pass silently than anything else :(
    – Matthieu M.
    37 mins ago






  • 2




    @MatthieuM. I agree, I believe it is a defect and that the intent was really to say contextually implicitly converted. I am filing a defect report on this hopefully today but who knows maybe I am wrong :-(
    – Shafik Yaghmour
    28 mins ago

















up vote
17
down vote













clang is correct, the key wording in [expr.new]p6 changes from this in the C++11 draft:




Every constant-expression in a noptr-new-declarator shall be an integral constant expression ([expr.const]) and evaluate to a strictly positive value. The expression in a noptr-new-declarator shall be of integral type, unscoped enumeration type, or a class type for which a single non-explicit conversion function to integral or unscoped enumeration type exists ([class.conv]). If the expression is of class type, the expression is converted by calling that conversion function, and the result of the conversion is used in place of the original expression. …




to this in the C++14 draft:




Every constant-expression in a noptr-new-declarator shall be a converted constant expression ([expr.const]) of type std::size_t and shall evaluate to a strictly positive value. The expression in a noptr-new-declaratoris implicitly converted to std::size_t. …




So in C++14 the requirement for the expression noptr-new-declarator was weakened to not require an integral, unscoped enumeration or a class with a
single non-explicit conversion function to one of those types but just allow implicit conversions to size_t.



This change came from the proposal A Proposal to Tweak Certain C++ Contextual Conversions, v3.






share|improve this answer

















  • 2




    I am dubious about the usefulness of allowing double to be used as the size of an array... it seems more likely to let bugs pass silently than anything else :(
    – Matthieu M.
    37 mins ago






  • 2




    @MatthieuM. I agree, I believe it is a defect and that the intent was really to say contextually implicitly converted. I am filing a defect report on this hopefully today but who knows maybe I am wrong :-(
    – Shafik Yaghmour
    28 mins ago















up vote
17
down vote










up vote
17
down vote









clang is correct, the key wording in [expr.new]p6 changes from this in the C++11 draft:




Every constant-expression in a noptr-new-declarator shall be an integral constant expression ([expr.const]) and evaluate to a strictly positive value. The expression in a noptr-new-declarator shall be of integral type, unscoped enumeration type, or a class type for which a single non-explicit conversion function to integral or unscoped enumeration type exists ([class.conv]). If the expression is of class type, the expression is converted by calling that conversion function, and the result of the conversion is used in place of the original expression. …




to this in the C++14 draft:




Every constant-expression in a noptr-new-declarator shall be a converted constant expression ([expr.const]) of type std::size_t and shall evaluate to a strictly positive value. The expression in a noptr-new-declaratoris implicitly converted to std::size_t. …




So in C++14 the requirement for the expression noptr-new-declarator was weakened to not require an integral, unscoped enumeration or a class with a
single non-explicit conversion function to one of those types but just allow implicit conversions to size_t.



This change came from the proposal A Proposal to Tweak Certain C++ Contextual Conversions, v3.






share|improve this answer












clang is correct, the key wording in [expr.new]p6 changes from this in the C++11 draft:




Every constant-expression in a noptr-new-declarator shall be an integral constant expression ([expr.const]) and evaluate to a strictly positive value. The expression in a noptr-new-declarator shall be of integral type, unscoped enumeration type, or a class type for which a single non-explicit conversion function to integral or unscoped enumeration type exists ([class.conv]). If the expression is of class type, the expression is converted by calling that conversion function, and the result of the conversion is used in place of the original expression. …




to this in the C++14 draft:




Every constant-expression in a noptr-new-declarator shall be a converted constant expression ([expr.const]) of type std::size_t and shall evaluate to a strictly positive value. The expression in a noptr-new-declaratoris implicitly converted to std::size_t. …




So in C++14 the requirement for the expression noptr-new-declarator was weakened to not require an integral, unscoped enumeration or a class with a
single non-explicit conversion function to one of those types but just allow implicit conversions to size_t.



This change came from the proposal A Proposal to Tweak Certain C++ Contextual Conversions, v3.







share|improve this answer












share|improve this answer



share|improve this answer










answered 2 hours ago









Shafik Yaghmour

124k23317524




124k23317524








  • 2




    I am dubious about the usefulness of allowing double to be used as the size of an array... it seems more likely to let bugs pass silently than anything else :(
    – Matthieu M.
    37 mins ago






  • 2




    @MatthieuM. I agree, I believe it is a defect and that the intent was really to say contextually implicitly converted. I am filing a defect report on this hopefully today but who knows maybe I am wrong :-(
    – Shafik Yaghmour
    28 mins ago
















  • 2




    I am dubious about the usefulness of allowing double to be used as the size of an array... it seems more likely to let bugs pass silently than anything else :(
    – Matthieu M.
    37 mins ago






  • 2




    @MatthieuM. I agree, I believe it is a defect and that the intent was really to say contextually implicitly converted. I am filing a defect report on this hopefully today but who knows maybe I am wrong :-(
    – Shafik Yaghmour
    28 mins ago










2




2




I am dubious about the usefulness of allowing double to be used as the size of an array... it seems more likely to let bugs pass silently than anything else :(
– Matthieu M.
37 mins ago




I am dubious about the usefulness of allowing double to be used as the size of an array... it seems more likely to let bugs pass silently than anything else :(
– Matthieu M.
37 mins ago




2




2




@MatthieuM. I agree, I believe it is a defect and that the intent was really to say contextually implicitly converted. I am filing a defect report on this hopefully today but who knows maybe I am wrong :-(
– Shafik Yaghmour
28 mins ago






@MatthieuM. I agree, I believe it is a defect and that the intent was really to say contextually implicitly converted. I am filing a defect report on this hopefully today but who knows maybe I am wrong :-(
– Shafik Yaghmour
28 mins ago




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53745158%2fin-c14-is-it-valid-to-use-a-double-in-the-dimension-of-a-new-expression%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

Mangá

Eduardo VII do Reino Unido