Try to understand compiler error message: default member initializer required before the end of its enclosing...
up vote
9
down vote
favorite
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:
$ g++ prog.cc -std=gnu++2a$ 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
add a comment |
up vote
9
down vote
favorite
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:
$ g++ prog.cc -std=gnu++2a$ 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
3
This seems to be related: stackoverflow.com/questions/43819314/… and this one: stackoverflow.com/questions/46866686/…
– Serhii
Nov 21 at 9:36
1
seems clang still struggles from that bug !!
– Blood-HaZaRd
Nov 21 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 at 4:26
add a comment |
up vote
9
down vote
favorite
up vote
9
down vote
favorite
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:
$ g++ prog.cc -std=gnu++2a$ 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
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:
$ g++ prog.cc -std=gnu++2a$ 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
c++ c++11 c++14 c++17
edited Nov 22 at 4:26
Shafik Yaghmour
123k23311518
123k23311518
asked Nov 21 at 9:32
leanid.chaika
89421319
89421319
3
This seems to be related: stackoverflow.com/questions/43819314/… and this one: stackoverflow.com/questions/46866686/…
– Serhii
Nov 21 at 9:36
1
seems clang still struggles from that bug !!
– Blood-HaZaRd
Nov 21 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 at 4:26
add a comment |
3
This seems to be related: stackoverflow.com/questions/43819314/… and this one: stackoverflow.com/questions/46866686/…
– Serhii
Nov 21 at 9:36
1
seems clang still struggles from that bug !!
– Blood-HaZaRd
Nov 21 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 at 4:26
3
3
This seems to be related: stackoverflow.com/questions/43819314/… and this one: stackoverflow.com/questions/46866686/…
– Serhii
Nov 21 at 9:36
This seems to be related: stackoverflow.com/questions/43819314/… and this one: stackoverflow.com/questions/46866686/…
– Serhii
Nov 21 at 9:36
1
1
seems clang still struggles from that bug !!
– Blood-HaZaRd
Nov 21 at 10:24
seems clang still struggles from that bug !!
– Blood-HaZaRd
Nov 21 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 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 at 4:26
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
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.
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 at 12:37
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
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.
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 at 12:37
add a comment |
up vote
1
down vote
accepted
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.
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 at 12:37
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
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.
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.
edited Nov 23 at 2:28
answered Nov 22 at 4:26
Shafik Yaghmour
123k23311518
123k23311518
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 at 12:37
add a comment |
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 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 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 at 12:37
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
3
This seems to be related: stackoverflow.com/questions/43819314/… and this one: stackoverflow.com/questions/46866686/…
– Serhii
Nov 21 at 9:36
1
seems clang still struggles from that bug !!
– Blood-HaZaRd
Nov 21 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 at 4:26