Should this code fail to compile in C++17?What is a smart pointer and when should I use one?When should static_cast, dynamic_cast, const_cast and reinterpret_cast be used?How can I profile C++ code running on Linux?Why should I use a pointer rather than the object itself?Compiling an application for use in highly radioactive environmentsWhat are the new features in C++17?clang 3.9, auto_ptr and boostC++17 code not compiling on Travis with Clang-6.0C++17: explicit conversion function vs explicit constructor + implicit conversions - have the rules changed?C++17 - Binding rvalue reference to non-const lvalue ref

What does War Machine's "Canopy! Canopy!" line mean in "Avengers: Endgame"?

What does it mean by "d-ism of Leibniz" and "dotage of Newton" in simple English?

Scala list with same adjacent values

Are grass strips more dangerous than tarmac?

Is there an evolutionary advantage to having two heads?

How can I offer a test ride while selling a bike?

What is the most important characteristic of New Weird as a genre?

How did the Zip Chip and RocketChip accelerators work for the Apple II?

How do I get a list of only the files (not the directories) from a package?

Cryptography and patents

Does Peach's float negate shorthop knockback multipliers?

Pros and cons of writing a book review?

California: "For quality assurance, this phone call is being recorded"

What is the right way to float a home lab?

What is a natural deduction proof from ~(A↔B) to ~(A→B)?

Make a formula to get the highest score

Is it possible to kill all life on Earth?

Can you keep a readied action even through incapacitation?

Is there a rule that prohibits us from using 2 possessives in a row?

Explain Ant-Man's "not it" scene from Avengers: Endgame

Why does my electric oven present the option of 40A and 50A breakers?

How to properly maintain eye contact with people that have distinctive facial features?

How to write a vulnerable moment without it seeming cliche or mushy?

Looking after a wayward brother in mother's will



Should this code fail to compile in C++17?


What is a smart pointer and when should I use one?When should static_cast, dynamic_cast, const_cast and reinterpret_cast be used?How can I profile C++ code running on Linux?Why should I use a pointer rather than the object itself?Compiling an application for use in highly radioactive environmentsWhat are the new features in C++17?clang 3.9, auto_ptr and boostC++17 code not compiling on Travis with Clang-6.0C++17: explicit conversion function vs explicit constructor + implicit conversions - have the rules changed?C++17 - Binding rvalue reference to non-const lvalue ref






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








15















I was updating a project to use C++17 and found a few instances where code that followed this pattern was causing a compile error on recent versions of clang:



#include <boost/variant.hpp>

struct vis : public boost::static_visitor<void>

 void operator()(int) const 
;

int main()

 boost::variant<int> v = 0;
 boost::apply_visitor(vis, v);



Using clang v8.0 in C++17 mode, this fails with the following error:



<source>:11:30: error: temporary of type 'boost::static_visitor<void>' has protected destructor
 boost::apply_visitor(vis, v);
 ^
/opt/compiler-explorer/libs/boost_1_64_0/boost/variant/static_visitor.hpp:53:5: note: declared protected here
 ~static_visitor() = default;


However, it compiles cleanly in C++14 mode. I found that if I change the brace initialization vis to parentheses vis(), then it compiles correctly in both modes. Every version of gcc that I've tried allows both variants in C++17 mode.



Is this a correct change in behavior from C++14 to C++17, or is this a clang bug? If it is correct, why is it now invalid in C++17 (or maybe it always was, but clang just allows it in earlier standard revisions)?






c++ clang c++17 boost-variant







share|improve this question
























  • It seem you use aggregate initialization instead of default constructor :-/ Changing to vis() compiles.

    – Jarod42
    8 hours ago







  • 1





    Boost fixed this in 1.70. It's also discussed here.

    – interjay
    8 hours ago


















15















I was updating a project to use C++17 and found a few instances where code that followed this pattern was causing a compile error on recent versions of clang:



#include <boost/variant.hpp>

struct vis : public boost::static_visitor<void>

 void operator()(int) const 
;

int main()

 boost::variant<int> v = 0;
 boost::apply_visitor(vis, v);



Using clang v8.0 in C++17 mode, this fails with the following error:



<source>:11:30: error: temporary of type 'boost::static_visitor<void>' has protected destructor
 boost::apply_visitor(vis, v);
 ^
/opt/compiler-explorer/libs/boost_1_64_0/boost/variant/static_visitor.hpp:53:5: note: declared protected here
 ~static_visitor() = default;


However, it compiles cleanly in C++14 mode. I found that if I change the brace initialization vis to parentheses vis(), then it compiles correctly in both modes. Every version of gcc that I've tried allows both variants in C++17 mode.



Is this a correct change in behavior from C++14 to C++17, or is this a clang bug? If it is correct, why is it now invalid in C++17 (or maybe it always was, but clang just allows it in earlier standard revisions)?






c++ clang c++17 boost-variant







share|improve this question
























  • It seem you use aggregate initialization instead of default constructor :-/ Changing to vis() compiles.

    – Jarod42
    8 hours ago







  • 1





    Boost fixed this in 1.70. It's also discussed here.

    – interjay
    8 hours ago














15












15








15


1






I was updating a project to use C++17 and found a few instances where code that followed this pattern was causing a compile error on recent versions of clang:



#include <boost/variant.hpp>

struct vis : public boost::static_visitor<void>

 void operator()(int) const 
;

int main()

 boost::variant<int> v = 0;
 boost::apply_visitor(vis, v);



Using clang v8.0 in C++17 mode, this fails with the following error:



<source>:11:30: error: temporary of type 'boost::static_visitor<void>' has protected destructor
 boost::apply_visitor(vis, v);
 ^
/opt/compiler-explorer/libs/boost_1_64_0/boost/variant/static_visitor.hpp:53:5: note: declared protected here
 ~static_visitor() = default;


However, it compiles cleanly in C++14 mode. I found that if I change the brace initialization vis to parentheses vis(), then it compiles correctly in both modes. Every version of gcc that I've tried allows both variants in C++17 mode.



Is this a correct change in behavior from C++14 to C++17, or is this a clang bug? If it is correct, why is it now invalid in C++17 (or maybe it always was, but clang just allows it in earlier standard revisions)?






c++ clang c++17 boost-variant







share|improve this question
















I was updating a project to use C++17 and found a few instances where code that followed this pattern was causing a compile error on recent versions of clang:



#include <boost/variant.hpp>

struct vis : public boost::static_visitor<void>

 void operator()(int) const 
;

int main()

 boost::variant<int> v = 0;
 boost::apply_visitor(vis, v);



Using clang v8.0 in C++17 mode, this fails with the following error:



<source>:11:30: error: temporary of type 'boost::static_visitor<void>' has protected destructor
 boost::apply_visitor(vis, v);
 ^
/opt/compiler-explorer/libs/boost_1_64_0/boost/variant/static_visitor.hpp:53:5: note: declared protected here
 ~static_visitor() = default;


However, it compiles cleanly in C++14 mode. I found that if I change the brace initialization vis to parentheses vis(), then it compiles correctly in both modes. Every version of gcc that I've tried allows both variants in C++17 mode.



Is this a correct change in behavior from C++14 to C++17, or is this a clang bug? If it is correct, why is it now invalid in C++17 (or maybe it always was, but clang just allows it in earlier standard revisions)?






c++ clang c++17 boost-variant




c++ clang c++17 boost-variant






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 8 hours ago









Barry

191k21345630




191k21345630










asked 8 hours ago









Jason RJason R

6,18223359




6,18223359












  • It seem you use aggregate initialization instead of default constructor :-/ Changing to vis() compiles.

    – Jarod42
    8 hours ago







  • 1





    Boost fixed this in 1.70. It's also discussed here.

    – interjay
    8 hours ago


















  • It seem you use aggregate initialization instead of default constructor :-/ Changing to vis() compiles.

    – Jarod42
    8 hours ago







  • 1





    Boost fixed this in 1.70. It's also discussed here.

    – interjay
    8 hours ago

















It seem you use aggregate initialization instead of default constructor :-/ Changing to vis() compiles.

– Jarod42
8 hours ago






It seem you use aggregate initialization instead of default constructor :-/ Changing to vis() compiles.

– Jarod42
8 hours ago





1




1





Boost fixed this in 1.70. It's also discussed here.

– interjay
8 hours ago






Boost fixed this in 1.70. It's also discussed here.

– interjay
8 hours ago













1 Answer
1






active

oldest

votes


















19














clang is correct here. Here's a reduced example:



struct B 
protected:
 B() 
;

struct D : B ;

auto d = D;


In C++14, D is not an aggregate because it has a base class, so D is "normal" (non-aggregate) initialization which invokes D's default constructor, which in turn invokes B's default constructor. This is fine, because D has access to B's default constructor.



In C++17, the definition of aggregate was widened - base classes are now allowed (as long as they're non-virtual). D is now an aggregate, which means that D is aggregate initialization. And in aggregate-initialization, this means that we (the caller) are initializing all the subobjects - including the base class subobject. But we do not have access to B's constructor (it is protected), so we cannot invoke it, so it is ill-formed.



Fear not, the fix is easy. Use parentheses:



auto d = D();


This goes back to invoking D's default constructor as before.






share|improve this answer























  • Perfect, that's what I was looking for: the widened definition of aggregate is the culprit.

    – Jason R
    8 hours 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',
autoActivateHeartbeat: false,
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%2f56367480%2fshould-this-code-fail-to-compile-in-c17%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









19














clang is correct here. Here's a reduced example:



struct B 
protected:
 B() 
;

struct D : B ;

auto d = D;


In C++14, D is not an aggregate because it has a base class, so D is "normal" (non-aggregate) initialization which invokes D's default constructor, which in turn invokes B's default constructor. This is fine, because D has access to B's default constructor.



In C++17, the definition of aggregate was widened - base classes are now allowed (as long as they're non-virtual). D is now an aggregate, which means that D is aggregate initialization. And in aggregate-initialization, this means that we (the caller) are initializing all the subobjects - including the base class subobject. But we do not have access to B's constructor (it is protected), so we cannot invoke it, so it is ill-formed.



Fear not, the fix is easy. Use parentheses:



auto d = D();


This goes back to invoking D's default constructor as before.






share|improve this answer























  • Perfect, that's what I was looking for: the widened definition of aggregate is the culprit.

    – Jason R
    8 hours ago















19














clang is correct here. Here's a reduced example:



struct B 
protected:
 B() 
;

struct D : B ;

auto d = D;


In C++14, D is not an aggregate because it has a base class, so D is "normal" (non-aggregate) initialization which invokes D's default constructor, which in turn invokes B's default constructor. This is fine, because D has access to B's default constructor.



In C++17, the definition of aggregate was widened - base classes are now allowed (as long as they're non-virtual). D is now an aggregate, which means that D is aggregate initialization. And in aggregate-initialization, this means that we (the caller) are initializing all the subobjects - including the base class subobject. But we do not have access to B's constructor (it is protected), so we cannot invoke it, so it is ill-formed.



Fear not, the fix is easy. Use parentheses:



auto d = D();


This goes back to invoking D's default constructor as before.






share|improve this answer























  • Perfect, that's what I was looking for: the widened definition of aggregate is the culprit.

    – Jason R
    8 hours ago













19












19








19







clang is correct here. Here's a reduced example:



struct B 
protected:
 B() 
;

struct D : B ;

auto d = D;


In C++14, D is not an aggregate because it has a base class, so D is "normal" (non-aggregate) initialization which invokes D's default constructor, which in turn invokes B's default constructor. This is fine, because D has access to B's default constructor.



In C++17, the definition of aggregate was widened - base classes are now allowed (as long as they're non-virtual). D is now an aggregate, which means that D is aggregate initialization. And in aggregate-initialization, this means that we (the caller) are initializing all the subobjects - including the base class subobject. But we do not have access to B's constructor (it is protected), so we cannot invoke it, so it is ill-formed.



Fear not, the fix is easy. Use parentheses:



auto d = D();


This goes back to invoking D's default constructor as before.






share|improve this answer













clang is correct here. Here's a reduced example:



struct B 
protected:
 B() 
;

struct D : B ;

auto d = D;


In C++14, D is not an aggregate because it has a base class, so D is "normal" (non-aggregate) initialization which invokes D's default constructor, which in turn invokes B's default constructor. This is fine, because D has access to B's default constructor.



In C++17, the definition of aggregate was widened - base classes are now allowed (as long as they're non-virtual). D is now an aggregate, which means that D is aggregate initialization. And in aggregate-initialization, this means that we (the caller) are initializing all the subobjects - including the base class subobject. But we do not have access to B's constructor (it is protected), so we cannot invoke it, so it is ill-formed.



Fear not, the fix is easy. Use parentheses:



auto d = D();


This goes back to invoking D's default constructor as before.







share|improve this answer












share|improve this answer



share|improve this answer










answered 8 hours ago









BarryBarry

191k21345630




191k21345630












  • Perfect, that's what I was looking for: the widened definition of aggregate is the culprit.

    – Jason R
    8 hours ago

















  • Perfect, that's what I was looking for: the widened definition of aggregate is the culprit.

    – Jason R
    8 hours ago
















Perfect, that's what I was looking for: the widened definition of aggregate is the culprit.

– Jason R
8 hours ago





Perfect, that's what I was looking for: the widened definition of aggregate is the culprit.

– Jason R
8 hours 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.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f56367480%2fshould-this-code-fail-to-compile-in-c17%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

Invision Community Contents History See also References External links Navigation menuProprietaryinvisioncommunity.comIPS Community ForumsIPS Community Forumsthis blog entry"License Changes, IP.Board 3.4, and the Future""Interview -- Matt Mecham of Ibforums""CEO Invision Power Board, Matt Mecham Is a Liar, Thief!"IPB License Explanation 1.3, 1.3.1, 2.0, and 2.1ArchivedSecurity Fixes, Updates And Enhancements For IPB 1.3.1Archived"New Demo Accounts - Invision Power Services"the original"New Default Skin"the original"Invision Power Board 3.0.0 and Applications Released"the original"Archived copy"the original"Perpetual licenses being done away with""Release Notes - Invision Power Services""Introducing: IPS Community Suite 4!"Invision Community Release Notes

Image
Internet forum softwarePHP software Internet communityPHPMySQLdatabase management systemInternet forumCharles WarnerMatt MechamJarvis Entertainment GroupIkonboardInvisionFreeAjaxIPS Community ForumsIPS Community Forumsthis blog entry Invision Community From Wikipedia, the free encyclopedia Jump to navigation Jump to search Invision Community Developer(s) Invision Power Services Stable release 4.4.6 / August 19, 2019 ; 34 days ago  ( 2019-08-19 ) Platform PHP / MySQL Type Forum software License Proprietary Website invisioncommunity.com Invision Community (previously known as IPS Community Suite ) is primarily an Internet community software produced by Invision Power Services, Inc. It is written in PHP and uses MySQL as a database management system. Invision Power Services sell applications that each can be bought and installed separately in addition to the Suite, the most widely known being the Internet forum software Invision Power Board. Invisi
Read more

Canceling a color specificationRandomly assigning color to Graphics3D objects?Default color for Filling in Mathematica 9Coloring specific elements of sets with a prime modified order in an array plotHow to pick a color differing significantly from the colors already in a given color list?Detection of the text colorColor numbers based on their valueCan color schemes for use with ColorData include opacity specification?My dynamic color schemes

Image
Would it be easier to colonise a living world or a dead world? Postal services in Italy - Poste Italiane vs. Friendpost vs. GPS What is /dev/null and why can't I use hx on it? Why are engines with carburetors hard to start in cold weather? How to make a gift without seeming creepy? Without exposing his identity, did Roy help his parents with money so that they can afford to stay in their home? Does the Creighton Method of Natural Family Planning have a failure rate of 3.2% or less? How do I break the broom in Untitled Goose Game? Had there been instances of national states banning harmful imports before the mid-19th C Opium Wars? D&D Monsters and Copyright Is sleeping on the groud in cold weather better than on an air mattress? Transiting through Switzerland by coach with lots of cash quadratic equations on 2 by 2 matrices Always Lubricate Skewers? I pay for a service, but I miss the broadcast Iron-age tools, is there a way to extract heavy metals
Read more

Ласкавець круглолистий Зміст Опис | Поширення | Галерея | Примітки | Посилання | Навігаційне меню58171138361-22960890446Bupleurum rotundifoliumEuro+Med PlantbasePlants of the World Online — Kew ScienceGermplasm Resources Information Network (GRIN)Ласкавецькн. VI : Літери Ком — Левиправивши або дописавши її

Image
ЛаскавецьФлора УкраїниФлора ЄвропиФлора АфрикиФлора АзіїРослини, описані 1753 ОкружковіОднорічнатрав'яниста рослинаАфриціЄвропіАзіїУкраїні Ласкавець круглолистий Матеріал з Вікіпедії — вільної енциклопедії. Перейти до навігації Перейти до пошуку ? Ласкавець круглолистий Біологічна класифікація Домен: Ядерні (Eukaryota) Царство: Зелені рослини (Viridiplantae) Відділ: Вищі рослини (Streptophyta) — Судинні (Tracheophyta) — Покритонасінні (Angiospermae) — Евдикоти (Eudicots) — Айстериди (Asterids) Порядок: Аралієцвіті (Apiales) Родина: Окружкові (Apiaceae) Підродина: Селерові (Apioideae) Триба: Bupleureae Рід: Ласкавець ( Bupleurum ) Вид: Ласкавець круглолистий Біноміальна назва Bupleurum rotundifolium L., 1753 Посилання Вікісховище: Bupleurum rotundifolium Віківиди: Bupleurum rotundifolium EOL: 581711 IPNI: 38361-2 ITIS: 29608 NCBI: 90446 Ласкавець круглолистий [1] [1] [2] ( Bupleurum rotundifolium ) — вид рослин родини Окружкові (Apiaceae)
Read more