Try to understand compiler error message: default member initializer required before the end of its enclosing...












10















I try next code with three compilers (msvc2017, gcc8.2, clang7.0) and msvc2017 works all the way, but gcc and clang not. I want to understand what is wrong with my code, and why compiler can't compile it.



#include <cassert>
#include <iostream>
#include <cstdlib>

class Downloader
{
public:

struct Hints
{
int32_t numOfMaxEasyHandles = 8;
//Hints(){} // <= if I uncomment this all works gcc+clang+msvc
//Hints() = default; // <= if I uncomment this neither clang no gcc works (msvc - works)
};

static Downloader *Create(const Hints &hints = Hints());
};

Downloader* Downloader::Create(const Hints &hints)
{
std::cout << hints.numOfMaxEasyHandles << std::endl;
return nullptr;
}

int main()
{
return 0;
}


You can play with this code yourself on https://wandbox.org/ and see error:



prog.cc:16:58: error: default member initializer for 'Downloader::Hints::numOfMaxEasyHandles' required before the end of its enclosing class
static Downloader *Create(const Hints &hints = Hints());
^
prog.cc:11:37: note: defined here
int32_t numOfMaxEasyHandles = 8;
^~~~


Why gcc and clang not compile this code even with uncomment Hints() = default?
My compile commands:




  1. $ g++ prog.cc -std=gnu++2a

  2. $ clang++ prog.cc -std=gnu++2a


But if I uncomment Hints(){} all three compilers works. Maybe it is compiler bug? Thanks in advance.










share|improve this question




















  • 3





    This seems to be related: stackoverflow.com/questions/43819314/… and this one: stackoverflow.com/questions/46866686/…

    – Serhii
    Nov 21 '18 at 9:36








  • 1





    seems clang still struggles from that bug !!

    – Blood-HaZaRd
    Nov 21 '18 at 10:24






  • 1





    @Serhii they look related but not exactly matching bugs, I found another bug report which seems to match pretty close to this case.

    – Shafik Yaghmour
    Nov 22 '18 at 4:26


















10















I try next code with three compilers (msvc2017, gcc8.2, clang7.0) and msvc2017 works all the way, but gcc and clang not. I want to understand what is wrong with my code, and why compiler can't compile it.



#include <cassert>
#include <iostream>
#include <cstdlib>

class Downloader
{
public:

struct Hints
{
int32_t numOfMaxEasyHandles = 8;
//Hints(){} // <= if I uncomment this all works gcc+clang+msvc
//Hints() = default; // <= if I uncomment this neither clang no gcc works (msvc - works)
};

static Downloader *Create(const Hints &hints = Hints());
};

Downloader* Downloader::Create(const Hints &hints)
{
std::cout << hints.numOfMaxEasyHandles << std::endl;
return nullptr;
}

int main()
{
return 0;
}


You can play with this code yourself on https://wandbox.org/ and see error:



prog.cc:16:58: error: default member initializer for 'Downloader::Hints::numOfMaxEasyHandles' required before the end of its enclosing class
static Downloader *Create(const Hints &hints = Hints());
^
prog.cc:11:37: note: defined here
int32_t numOfMaxEasyHandles = 8;
^~~~


Why gcc and clang not compile this code even with uncomment Hints() = default?
My compile commands:




  1. $ g++ prog.cc -std=gnu++2a

  2. $ clang++ prog.cc -std=gnu++2a


But if I uncomment Hints(){} all three compilers works. Maybe it is compiler bug? Thanks in advance.










share|improve this question




















  • 3





    This seems to be related: stackoverflow.com/questions/43819314/… and this one: stackoverflow.com/questions/46866686/…

    – Serhii
    Nov 21 '18 at 9:36








  • 1





    seems clang still struggles from that bug !!

    – Blood-HaZaRd
    Nov 21 '18 at 10:24






  • 1





    @Serhii they look related but not exactly matching bugs, I found another bug report which seems to match pretty close to this case.

    – Shafik Yaghmour
    Nov 22 '18 at 4:26
















10












10








10


0






I try next code with three compilers (msvc2017, gcc8.2, clang7.0) and msvc2017 works all the way, but gcc and clang not. I want to understand what is wrong with my code, and why compiler can't compile it.



#include <cassert>
#include <iostream>
#include <cstdlib>

class Downloader
{
public:

struct Hints
{
int32_t numOfMaxEasyHandles = 8;
//Hints(){} // <= if I uncomment this all works gcc+clang+msvc
//Hints() = default; // <= if I uncomment this neither clang no gcc works (msvc - works)
};

static Downloader *Create(const Hints &hints = Hints());
};

Downloader* Downloader::Create(const Hints &hints)
{
std::cout << hints.numOfMaxEasyHandles << std::endl;
return nullptr;
}

int main()
{
return 0;
}


You can play with this code yourself on https://wandbox.org/ and see error:



prog.cc:16:58: error: default member initializer for 'Downloader::Hints::numOfMaxEasyHandles' required before the end of its enclosing class
static Downloader *Create(const Hints &hints = Hints());
^
prog.cc:11:37: note: defined here
int32_t numOfMaxEasyHandles = 8;
^~~~


Why gcc and clang not compile this code even with uncomment Hints() = default?
My compile commands:




  1. $ g++ prog.cc -std=gnu++2a

  2. $ clang++ prog.cc -std=gnu++2a


But if I uncomment Hints(){} all three compilers works. Maybe it is compiler bug? Thanks in advance.










share|improve this question
















I try next code with three compilers (msvc2017, gcc8.2, clang7.0) and msvc2017 works all the way, but gcc and clang not. I want to understand what is wrong with my code, and why compiler can't compile it.



#include <cassert>
#include <iostream>
#include <cstdlib>

class Downloader
{
public:

struct Hints
{
int32_t numOfMaxEasyHandles = 8;
//Hints(){} // <= if I uncomment this all works gcc+clang+msvc
//Hints() = default; // <= if I uncomment this neither clang no gcc works (msvc - works)
};

static Downloader *Create(const Hints &hints = Hints());
};

Downloader* Downloader::Create(const Hints &hints)
{
std::cout << hints.numOfMaxEasyHandles << std::endl;
return nullptr;
}

int main()
{
return 0;
}


You can play with this code yourself on https://wandbox.org/ and see error:



prog.cc:16:58: error: default member initializer for 'Downloader::Hints::numOfMaxEasyHandles' required before the end of its enclosing class
static Downloader *Create(const Hints &hints = Hints());
^
prog.cc:11:37: note: defined here
int32_t numOfMaxEasyHandles = 8;
^~~~


Why gcc and clang not compile this code even with uncomment Hints() = default?
My compile commands:




  1. $ g++ prog.cc -std=gnu++2a

  2. $ clang++ prog.cc -std=gnu++2a


But if I uncomment Hints(){} all three compilers works. Maybe it is compiler bug? Thanks in advance.







c++ c++11 c++14 c++17






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 22 '18 at 4:26









Shafik Yaghmour

126k23324535




126k23324535










asked Nov 21 '18 at 9:32









leanid.chaikaleanid.chaika

91121320




91121320








  • 3





    This seems to be related: stackoverflow.com/questions/43819314/… and this one: stackoverflow.com/questions/46866686/…

    – Serhii
    Nov 21 '18 at 9:36








  • 1





    seems clang still struggles from that bug !!

    – Blood-HaZaRd
    Nov 21 '18 at 10:24






  • 1





    @Serhii they look related but not exactly matching bugs, I found another bug report which seems to match pretty close to this case.

    – Shafik Yaghmour
    Nov 22 '18 at 4:26
















  • 3





    This seems to be related: stackoverflow.com/questions/43819314/… and this one: stackoverflow.com/questions/46866686/…

    – Serhii
    Nov 21 '18 at 9:36








  • 1





    seems clang still struggles from that bug !!

    – Blood-HaZaRd
    Nov 21 '18 at 10:24






  • 1





    @Serhii they look related but not exactly matching bugs, I found another bug report which seems to match pretty close to this case.

    – Shafik Yaghmour
    Nov 22 '18 at 4:26










3




3





This seems to be related: stackoverflow.com/questions/43819314/… and this one: stackoverflow.com/questions/46866686/…

– Serhii
Nov 21 '18 at 9:36







This seems to be related: stackoverflow.com/questions/43819314/… and this one: stackoverflow.com/questions/46866686/…

– Serhii
Nov 21 '18 at 9:36






1




1





seems clang still struggles from that bug !!

– Blood-HaZaRd
Nov 21 '18 at 10:24





seems clang still struggles from that bug !!

– Blood-HaZaRd
Nov 21 '18 at 10:24




1




1





@Serhii they look related but not exactly matching bugs, I found another bug report which seems to match pretty close to this case.

– Shafik Yaghmour
Nov 22 '18 at 4:26







@Serhii they look related but not exactly matching bugs, I found another bug report which seems to match pretty close to this case.

– Shafik Yaghmour
Nov 22 '18 at 4:26














1 Answer
1






active

oldest

votes


















1














This is a clang and gcc bug, we have a clang bug report for this: default member initializer for 'm' needed within definition of enclosing class for default argument of function which has the following example:



#include <limits>
class A
{
public:
class B
{
public:
explicit B() = default;
~B() = default;

private:
double m = std::numeric_limits<double>::max();
};

void f(double d, const B &b = B{}) {}
};

int main()
{
A a{};
a.f(0.);
}


which produces the following similar diagnostic:



t.cpp(15,34):  error: default member initializer for 'm' needed within definition of enclosing class 'A' outside of member functions
void f(double d, const B &b = B{}) {}
^
t.cpp(12,20): note: default member initializer declared here
double m = std::numeric_limits<double>::max();
^


Richard Smith indicates this is a bug:




Regarding comment#0: if we want to fix this once-and-for-all, we should use the same technique we use for delayed template parsing: teach Sema to call back into the parser to parse the delayed regions on-demand. Then we would only reject the cases where there's an actual dependency cycle.




Although does not explain why in details.






share|improve this answer


























  • I decide to add this bug to gcc too: gcc.gnu.org/bugzilla/show_bug.cgi?id=88165 (can't find match, so add new one)

    – leanid.chaika
    Nov 23 '18 at 12:37











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%2f53408962%2ftry-to-understand-compiler-error-message-default-member-initializer-required-be%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









1














This is a clang and gcc bug, we have a clang bug report for this: default member initializer for 'm' needed within definition of enclosing class for default argument of function which has the following example:



#include <limits>
class A
{
public:
class B
{
public:
explicit B() = default;
~B() = default;

private:
double m = std::numeric_limits<double>::max();
};

void f(double d, const B &b = B{}) {}
};

int main()
{
A a{};
a.f(0.);
}


which produces the following similar diagnostic:



t.cpp(15,34):  error: default member initializer for 'm' needed within definition of enclosing class 'A' outside of member functions
void f(double d, const B &b = B{}) {}
^
t.cpp(12,20): note: default member initializer declared here
double m = std::numeric_limits<double>::max();
^


Richard Smith indicates this is a bug:




Regarding comment#0: if we want to fix this once-and-for-all, we should use the same technique we use for delayed template parsing: teach Sema to call back into the parser to parse the delayed regions on-demand. Then we would only reject the cases where there's an actual dependency cycle.




Although does not explain why in details.






share|improve this answer


























  • I decide to add this bug to gcc too: gcc.gnu.org/bugzilla/show_bug.cgi?id=88165 (can't find match, so add new one)

    – leanid.chaika
    Nov 23 '18 at 12:37
















1














This is a clang and gcc bug, we have a clang bug report for this: default member initializer for 'm' needed within definition of enclosing class for default argument of function which has the following example:



#include <limits>
class A
{
public:
class B
{
public:
explicit B() = default;
~B() = default;

private:
double m = std::numeric_limits<double>::max();
};

void f(double d, const B &b = B{}) {}
};

int main()
{
A a{};
a.f(0.);
}


which produces the following similar diagnostic:



t.cpp(15,34):  error: default member initializer for 'm' needed within definition of enclosing class 'A' outside of member functions
void f(double d, const B &b = B{}) {}
^
t.cpp(12,20): note: default member initializer declared here
double m = std::numeric_limits<double>::max();
^


Richard Smith indicates this is a bug:




Regarding comment#0: if we want to fix this once-and-for-all, we should use the same technique we use for delayed template parsing: teach Sema to call back into the parser to parse the delayed regions on-demand. Then we would only reject the cases where there's an actual dependency cycle.




Although does not explain why in details.






share|improve this answer


























  • I decide to add this bug to gcc too: gcc.gnu.org/bugzilla/show_bug.cgi?id=88165 (can't find match, so add new one)

    – leanid.chaika
    Nov 23 '18 at 12:37














1












1








1







This is a clang and gcc bug, we have a clang bug report for this: default member initializer for 'm' needed within definition of enclosing class for default argument of function which has the following example:



#include <limits>
class A
{
public:
class B
{
public:
explicit B() = default;
~B() = default;

private:
double m = std::numeric_limits<double>::max();
};

void f(double d, const B &b = B{}) {}
};

int main()
{
A a{};
a.f(0.);
}


which produces the following similar diagnostic:



t.cpp(15,34):  error: default member initializer for 'm' needed within definition of enclosing class 'A' outside of member functions
void f(double d, const B &b = B{}) {}
^
t.cpp(12,20): note: default member initializer declared here
double m = std::numeric_limits<double>::max();
^


Richard Smith indicates this is a bug:




Regarding comment#0: if we want to fix this once-and-for-all, we should use the same technique we use for delayed template parsing: teach Sema to call back into the parser to parse the delayed regions on-demand. Then we would only reject the cases where there's an actual dependency cycle.




Although does not explain why in details.






share|improve this answer















This is a clang and gcc bug, we have a clang bug report for this: default member initializer for 'm' needed within definition of enclosing class for default argument of function which has the following example:



#include <limits>
class A
{
public:
class B
{
public:
explicit B() = default;
~B() = default;

private:
double m = std::numeric_limits<double>::max();
};

void f(double d, const B &b = B{}) {}
};

int main()
{
A a{};
a.f(0.);
}


which produces the following similar diagnostic:



t.cpp(15,34):  error: default member initializer for 'm' needed within definition of enclosing class 'A' outside of member functions
void f(double d, const B &b = B{}) {}
^
t.cpp(12,20): note: default member initializer declared here
double m = std::numeric_limits<double>::max();
^


Richard Smith indicates this is a bug:




Regarding comment#0: if we want to fix this once-and-for-all, we should use the same technique we use for delayed template parsing: teach Sema to call back into the parser to parse the delayed regions on-demand. Then we would only reject the cases where there's an actual dependency cycle.




Although does not explain why in details.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 23 '18 at 2:28

























answered Nov 22 '18 at 4:26









Shafik YaghmourShafik Yaghmour

126k23324535




126k23324535













  • I decide to add this bug to gcc too: gcc.gnu.org/bugzilla/show_bug.cgi?id=88165 (can't find match, so add new one)

    – leanid.chaika
    Nov 23 '18 at 12:37



















  • I decide to add this bug to gcc too: gcc.gnu.org/bugzilla/show_bug.cgi?id=88165 (can't find match, so add new one)

    – leanid.chaika
    Nov 23 '18 at 12:37

















I decide to add this bug to gcc too: gcc.gnu.org/bugzilla/show_bug.cgi?id=88165 (can't find match, so add new one)

– leanid.chaika
Nov 23 '18 at 12:37





I decide to add this bug to gcc too: gcc.gnu.org/bugzilla/show_bug.cgi?id=88165 (can't find match, so add new one)

– leanid.chaika
Nov 23 '18 at 12:37


















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%2f53408962%2ftry-to-understand-compiler-error-message-default-member-initializer-required-be%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

If I really need a card on my start hand, how many mulligans make sense? [duplicate]

Alcedinidae

Can an atomic nucleus contain both particles and antiparticles? [duplicate]